簡介：拿什么拯救你，flutter內存

作者：閑魚技術——靖書

背景

我們閑魚使用的圖片方案是自研的外接紋理方案：

• Android側創建SurfaceTexture，通過FlutterJNI注冊到Flutter engine里，最后返回texture id給Flutter應用層，應用層使用Texture Widget和textue id去顯示圖片紋理。
• 紋理數據則是在Android側，通過OpenGL將圖片紋理寫入到SurfaceTexture，然后通過Flutter engine里的共享內存，將紋理數據傳入到應用層，最終交給Skia渲染。

這里面存在的問題：
Flutter應用層的紋理數據沒有緩存，每次都需要重新將Bitmap數據渲染成紋理，再交給Flutter應用層使用。Native圖片加載會內存緩存，Flutter自身提供的圖片庫也存在緩存，這2個緩存相互隔離，占用很大的內存空間。而且Flutter圖片緩存基本都是存放的本地資源圖，而我們Flutter頁面上大部分其實都是網絡下載的外接紋理圖片，導致緩存資源利用率很低。

分析

針對上述的3個問題，我們先拋開技術實現，假設下要解決這3個問題，最理想的一個解決方案是什么：

• 紋理沒有緩存，那我們在應用層增加一個紋理的內存緩存就解決了。
• 當上層的應用層已經緩存紋理，那Native側的Bitmap的內存緩存也可以被去掉，只保留圖片資源的磁盤緩存。
• 整個App的內存緩存，只有紋理緩存，Flutter的ImageCache緩存，為了避免內存資源的浪費，將這2個緩存合成一個

所以最理想的解決方案：
整個App內只存在一個內存緩存，并且它既能緩存紋理，也能緩存Flutter的Image Widget加載的圖片數據。

解決方案

ImageCache是官方提供的，我們沒辦法去掉，而且閑魚App里也有一些地方使用Image Widget。現在解決方案就變成：
將紋理數據也放到ImageCache里緩存。使用紋理時，先從imageCache里取。

我們先看下現有的Flutter圖片加載邏輯，以及圖片是如何緩存的

從圖中可以看到，Flutter的圖片加載，都會調用ImageCache.putIfAbsent方法，通過該方法取緩存，沒命中緩存則會使用傳入有的loader方法，去構造對應的ImageStreamCompleter，由ImageStreamCompleter去完成圖片加載的邏輯。

當命中緩存時，putIfAbsent方法會直接返回ImageStreamCompleter，該對象里持有了imageInfo，ImageWidget直接拿imageInfo的ui.Image去渲染。

方案一：擴展ImageCache，緩存紋理

ImageCache對外提供取緩存方法就一個putIfAbsent

一開始我們想的是按照該方法參數，構建對應的key，loader，以及ImageStreamCompleter，然后也使用putIfAbsent方法去取緩存。

嘗試過后發現不行，如下圖所示，當圖片下載解碼成功后，會回調這個listener方法，在該方法中，會將圖片存放進ImageCache的緩存隊列

這個listener回調有2個參數，ImageInfo里面存放著圖片數據ui.Image。

我們應用層根本沒辦法去構造 ui.Image，因為該類是Flutter engine底層完成圖片解碼之后set到應用層的。應用層根本沒辦法去主動set值。這樣就導致在listener里，無法計算出imageSize的值，自然也沒辦法存到緩存里。

方案二：自定義ImageCache

因為ImageCache的緩存隊列是私有的，只有putIfAbsent方法可以往里面存數據。那我們只有另外一條路，從ImageCache的源碼入手，去自定義imageCache，然后對其進行功能擴展。

將ImageCache替換成我們自定義的

因為Flutter提供的ImageCache沒辦法修改代碼，所以我們直接把ImageCache的源碼copy出來一份，繼承ImageCache，然后將PaintingBinding的imageCache替換成自定義的。

如圖所示：Flutter的PaintingBinding有暴露出createImageCache的方法，我們繼承WidgetsFlutterBinding，重寫該方法返回我們自己的ImageCache， 另外在這里還可以針對ImageCache的各種緩存大小做設置。

對ImageCache進行功能擴展

為了盡可能不修改ImageCache的代碼，我們直接定義了新的緩存紋理的方法，對齊了putIfAbsent方法的邏輯，核心代碼邏輯如下：

該方法主要是參考putIfAbsent的邏輯來實現的，為了將紋理也緩存進ImageCache，主要做了以下幾個關鍵擴展：

TextureCacheKey是唯一標識紋理的key，該key是主要是根據寬高，url來判斷是否是同一個紋理的。

TextureImageStreamCompleter 則是紋理的管理類，該類繼承ImageStreamCompleter，內部持有紋理數據和下載成功的回調。當命中緩存時，返回該對象給應用層，并從中拿到紋理id交給Texture Widget渲染

當沒有命中緩存時，會調用傳入的loader方法構造TextureImageStreamCompleter，并且會執行紋理的加載邏輯。同時會構造一個listener回調，注冊進TextureImageStreamCompleter。

當紋理加載成功時，會執行listener方法回調，該方法里主要是計算紋理大小，將它放入緩存隊列里，檢查緩存大小是否超過最大值，超過則淘汰之前最久未使用的紋理。

這里要注意的一個點
因為普通的圖片是dart對象，會被Dart VM自動回收，但是我們的紋理對象真實的數據是在Engine的共享內存里，所以這里需要手動的管理紋理的釋放，我們對紋理對了引用計數，只有當沒有widget持有紋理時，引用計數為0時，才會真正的釋放。

同理，上層Texture Widget 在dispose時，也會調用下ImageCache提供的接口，看下當前使用的紋理是否被緩存或者正在被使用。只有否的時候才會真正的釋放紋理

效果

我們采用搜索結果頁作為測試頁面，該頁面存在很多寶貝大圖，以及各種重復的標簽小圖。使用華為榮耀20來測試優化前后的物理內存占用。

操作步驟是：打開app，進入搜索結果頁，搜索相同的關鍵字后進入搜索結果頁，然后靜默10s后滑動瀏覽100條數據，最后停止操作。期間每秒采樣一次物理內存，一共持續100s，得出如下的數據

藍色曲線是優化前的內存占用，橘黃色曲線是優化后，進入時可以看到占用的內存基本一致。滑動時內存占用下降是因為出發了GC回收App的內存導致的。總體上看，優化后總的內存占用比優化前要少，因為GC導致的毛刺也比優化前要少。

展望

上述的方案雖然實現了一個App內一個內存緩存，并且將紋理和Flutter圖片都存進去了，節省了內存空間，提高了內存使用率，但還是侵入了ImageCache源碼，后續flutter engine的升級和代碼維護，需要有額外的工作。

此外因為Flutter側加載原生圖片，都走的putIfAbsent方法，并且因為加載原生圖片都走的原圖加載，我們app內時不時存在著這種情況，一張圖片可能會占用好幾M的內存，所以我們直接在putIfAbsent加上了大圖監控的方法，當發現加載的圖片大小超過2M時，會進行數據上報，包括圖片的url，圖片使用信息，圖片大小等。通過該方式，我們發現了好幾例圖片使用不當的情況：直接使用Image.network加載原圖，或者是Image.asset加載一張很大的本地資源。

原文鏈接：https://developer.aliyun.com/article/776520?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的一个方案提升Flutter内存利用率（干货）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。