閒魚Flutter圖片框架架構演進（超詳細）

簡介：flutter圖片內存大？加載慢？本地資源利用率低？看這篇就夠了

做者：閒魚技術-意境

1.那些年

圖片對一個端側研發來講是一老生常談的話題了。閒魚做爲業界在Flutter技術方向上最先一批投入的團隊。從使用Flutter之初，圖片就是咱們核心關注和重點優化的功能。圖片算是閒魚業務場景下最爲重要的內容表現形式之一。圖片展現體驗的好壞會對閒魚用戶的使用體驗產生巨大影響。大家是否也曾遇到過：

• 圖片加載內存佔用過多？
• 使用flutter之後本地資源重複，利用率不高？
• 混合方案下Flutter原生圖片加載效率不高？

針對上述問題，從初版Flutter業務上線開始，閒魚對圖片框架的優化就從未中止。從開始的原生優化，到後面黑科技的外接紋理；從內存佔用，到包大小；文本會逐一介紹。但願其中的優化思路和手段，能給你們帶去一些啓發。

2. 原生模式

從技術層面看圖片加載，其實簡單來講，追求的是無非是加載的效率的最大化—用盡量小的資源成本，儘量快地加載儘量多的圖片。

閒魚圖片的第一個版本其實基本上是純原生的方案。若是你不想魔改不少底層的邏輯，原生方案確定是最簡單和經濟的方案。原生方案的功能模塊以下：

若是你啥都沒作直接上了，那麼你可能會發現效果並無達到你預期的那麼美好。那麼若是從原生的方案入手，咱們有哪些具體的優化手段呢？

2.1. 設置圖片緩存

沒錯猜對了，是緩存。對於圖片加載，最能想到的方案就是使用緩存。首先原生Image的組件是支持自定義圖片緩存的，具體的實現類是ImageCache。ImageCache的設置維度是兩個方向： 1.緩存圖片的張數。經過maximumSize設置。默認是1000張。2. 緩存空間的大小。 經過maximumSizeBytes 來設置。默認值100M。相比張數的限制，其實大小的設置方式更加符合咱們的最終的預期。

經過合理設置ImageCache的大小，能充分利用緩存機制加速圖片加載。不只如此，閒魚在這個點上還作了額外兩個重要優化：

1. 低端手機適配

在上線之後，咱們陸續收到線上輿情的反饋，發現所有機型設置同一個緩存大小的作法並不是最優。特別是大緩存設置在低端機器上面，不只會出現體驗變差，甚至還會影響穩定性。基於實際狀況，咱們實現了一個能從Native側獲取機器基礎信息的Flutter 插件。經過獲取的信息，咱們根據不一樣手機的配置設置不一樣的緩存策略。在低端機器上面適當下降圖片緩存的大小，同時在高端手機上將其適當放大。這樣能在不一樣配置的手機上獲取最優的緩存性能。

1. 磁盤緩存

熟悉APP開發的同窗都知道，成熟的圖片加載框架通常都有多級緩存。除了常見的內存緩存，通常都會配置一個文件緩存。從加載效率上來講，是經過空間換時間，提高加載速度。從穩定性來講，這又不會過度佔用寶貴的內存資源，出現OOM。可是惋惜的是，Flutter自帶的圖片加載框架並無獨立的磁盤緩存。因此咱們在原生方案的基礎上擴展了磁盤緩存能力。

在具體的架構實現上，咱們並無徹底本身擼一個磁盤緩存。咱們的策略仍是複用現有能力。首先咱們將Native圖片加載框架的磁盤緩存的功能經過接口暴露出來。而後經過橋接的方式，將Native 磁盤緩存能力嫁接到Flutter層。Flutter側進行圖片加載的時候，若是內存沒有命中，就去磁盤緩存中進行二次搜索。若是都沒有命中才會走網絡請求。

經過增長磁盤緩存，Flutter圖片加載效率進一步提高。

2.2. 設置CDN優化

CDN 優化是另外一個很是重要圖片優化手段。CDN優化的效率提高主要是：最小化傳輸圖片的大小。常見策略包括：

1. 根據顯示大小裁剪

簡單來講，你要加載圖片的真實尺寸，可能會大於你實際展現窗口的大小。那麼你就不必加載完整大圖，你只須要加載一個能覆蓋窗口大小的圖片便可。經過這種方式，裁剪掉不須要的部分，就能最小化傳輸圖片的大小。從端側角度來講，一來能夠提高加載速度，二來能夠下降內存佔用。

1. 適當壓縮圖片大小

這裏主要是根據實際狀況增長圖片壓縮的比例。在不影響顯示效果的狀況下，經過壓縮進一步下降圖片的大小。

1. 圖片格式

建議優先使用webp這樣格式，圖片資源相對小。Flutter原生支持webp（包括動圖）。這裏特別強調一下webp動圖不只大小要比gif小不少，並且還對透明效果有更好的支持。webp動圖是gif方案比較理想的一種替代方案。

基於上述緣由，閒魚圖片框架在Flutter側實現了一套CDN尺寸匹配的算法。經過該算法，請求圖片會根據實際顯示的大小，自動匹配到最合適的尺寸上並適當壓縮。若是圖片格式容許，圖片儘量轉化成webp格式下發。這樣cdn圖片的傳輸就能儘量高效。

2.3. 其餘優化

除了上面的策略，Flutter還有一些其餘的手段能夠優化圖片的性能。

1. 圖片預加載

若是你想在展現的圖片的儘量的快，官方也提供了一套預加載的機制:precacheImage。precacheImage能預先將圖片加載到內存，真正使用的時候就能秒出了。

1. Element複用優化

其實這個算是一個Flutter通用的優化方案。複寫didWidgetUpdate方案，經過比較先後兩次widget中針對圖片的描述是否一致，來決定是否從新渲染Element。這樣能避免同一個圖片，沒必要要的反覆渲染。

1. 長列表優化

通常狀況下，Listview是flutter最爲常見的滾動容器。在Listview中的性能好壞，直接影響最終的用戶體驗。

Flutter的Listview跟Native的實現思路並不相同。其最大的特色是有一個viewPort的概念。超出viewPort的部分會被強制回收掉。

基於上述的原理，咱們有兩點建議：

1. cell拆分

儘可能避免大型的cell出現，這樣能大幅下降cell頻繁建立過程當中的性能損耗。其實這裏影響的不只僅是圖片加載過程。文字，視頻等其餘組件也都應該避免cell過於複雜致使的性能問題。

1. 合理使用緩衝區

ListView能夠經過設置cacheExtent 來設置預先加載的內容大小。經過預先加載能夠提高view渲染的速度。可是這個值須要合理設置，並不是越大越好。由於預加載緩存越大，對頁面總體內存的壓力就越大。

2.4. 方案的不足

這裏須要客觀指出：若是是一個純Flutter APP，原生方案是完善，夠用的。可是若是從混合APP的角度來講，有以下兩個缺陷：

1. 沒法複用Native圖片加載能力

毫無疑問，原生的圖片方案是徹底獨立的圖片加載方案。對於一個混合APP來講，原生方案和Native的圖片框架相互獨立，能力沒法複用。例如CDN裁剪&壓縮等能力須要重複建設。特別是Native一些獨特的圖片解碼能力，Flutter就很難使用。這會形成APP範圍內的圖片格式的支持不統一。

2. 內存性能不足

從整個APP的視角來講，採用原生圖片方案的狀況下，其實咱們維護了兩個大的緩存池：一個是Native的圖片緩存，一個是Flutter側的圖片緩存。兩個緩存沒法互通，這無疑是一個巨大的浪費。特別是對內存的峯值內存性能產生了很是大的壓力。

3. 打通Native

通過多輪優化，基於原生的方案已經得到了很是大的性能提高。可是整個APP的內存水位線依然比較高（特別是Ios端）。現實的壓力迫使咱們繼續對圖片框架進行更深度的優化。基於上述原生方案缺點的分析，咱們有了一個大膽的想法：可否徹底複用Native的圖片加載能力？

3.1. 外接紋理

怎樣打通Flutter和Native的圖片能力？咱們想到了外接紋理。外接紋理並不是是Flutter自有的技術，他是音視頻領域經常使用的一種性能優化手段。

這個階段咱們基於shared-Context的方案實現了Flutter和Native的紋理外接。經過該方案，Flutter能夠經過共享紋理的方式，拿到Native圖片庫加載好的圖片並展現。爲了實現這個紋理共享的通道，咱們對engine層作了深度定製。細節過程以下：

該方案不只打通了Native和Flutter的圖片架構，整個過程圖片加載的性能也獲得了優化。想要了解細節的同窗能夠繼續閱讀這篇文章：萬萬沒想到——Flutter外接紋理。

外接紋理是閒魚圖片方案的一次大跨越。經過該技術，咱們不只實現圖片方案的本地能力複用，並且還能實現視頻能力的紋理外接。這避免了大量重複的建設，提高了整個APP的性能。

3.2. 多頁面內存優化

這個優化策略是真真被逼出來的。在對線上數據分析之後，咱們發現Flutter頁面棧有一個很是有意思的特色：

多頁面棧狀況下，底層的頁面不會被釋放。即使是在內存很是緊張的狀況下，也不會執行回收。這樣就會致使一個問題：隨着頁面的增多，內存消耗會線性增加。這裏佔比最高的就是圖片資源的佔比了。

是否是能夠在頁面處於頁面棧底層的時候直接回收掉該頁面內的圖片呢？

在這個想法的驅動下，咱們對圖片架構進行了新一輪的優化。整個圖片框架中的圖片都會監聽頁面棧的變化。當方發現本身已經處於非棧頂的時候，就自動回收掉對應的圖片紋理釋放資源。這種方案能使圖片佔用的內存大小不會隨着頁面數的變多呈現持續線性增加。原理以下：

須要注意的是：這個階段頁面判斷位置實際上是須要頁面棧（具體來講就是混合棧）提供額外的接口來實現的。系統之間的耦合相對較高。

3.3. 意外收穫包大小

打通Native和Flutter側圖片框架之後，咱們發現了一個意外收穫: Native和Flutter能夠共用本地圖片資源了。也就是說，咱們再也不須要將相同的圖片資源在Flutter和Native側各保留一份了。這樣能大幅提高本地資源的複用率，從而下降總體的包大小。基於這個方案，咱們實現了一套資源管理的功能，腳本能自動同步不一樣端的本地圖片資源。經過這樣提高本地資源利用率，下降包大小。

3.4. 其餘優化

1. PlaceHolder強化

原生的Image是沒有PlaceHolder功能的。若是想用原生方案的話，須要使用FadeInImage。針對閒魚的場景咱們有不少定製，因此咱們本身實現了一套PlaceHolder的機制。

從核心功能上來講，咱們引入了加載狀態的概念分爲： 1. 未初始化 2. 加載中 3. 加載完成 等。針對不一樣的狀態，能夠細粒度的控制PlaceHolder的展現邏輯。

3.5. 總體架構

3.6. 方案的不足

1. 畢竟改了engine

隨着閒魚業務的不斷推動，engine的升級的成本是咱們必需要考慮的事情。可否不改engine實現一樣的功能是咱們核心的述求。（PS: 我認可咱們是貪心的）

1. 通道性能還有優化空間

外接紋理的方案須要經過橋的方式跟native的能力作通訊。這裏包括圖片請求的傳遞和圖片加載各類狀態的同步。特別是在listview快速滑動的時候，經過橋發送的數據量仍是可觀的。當前方案每一個圖片加載時都會單獨進行橋的調用。在圖片數量比較多的狀況下，這顯然會是一個瓶頸。

1. 耦合過多

在實現圖片回收方案的時候，目前方案須要棧提供是否在棧底層的接口。這裏就產生方案耦合，很難抽象出一個獨立乾淨的圖片加載方案。

4. Clean&Efficient

時間來到了2020年，隨着對Flutter基礎能力理解的逐步深刻，咱們實現了一個總體方案更優的圖片框架。

4.1. 無侵入外接紋理

外接紋理能夠不用修改engine麼？答案是確定的。

其實Flutter是提供了官方的外接紋理方案的。

並且Native操做的texture和Flutter側顯示的texture在底層是同一對象，並沒有產生額外的數據copy。這樣就保證了紋理共享的足夠高效。那爲何閒魚以前會單獨基於shared-Context本身實現一套呢？1.12版本以前，官方Ios的外接紋理方案有性能問題。每次渲染的過程當中（無論紋理是否有更新）都會頻繁獲取CVPixelBuffer，形成沒必要要的性能損耗（過程有加鎖損耗）。該問題已經在1.12版本中修復(官方commit地址)，這樣官方方案也足夠知足需求。在這樣的背景下，咱們從新啓用官方方案來實現外接紋理功能。

4.2. 獨立的內存優化

以前提到過，老版本的基於頁面棧的圖片資源回收須要強依賴棧功能的接口。一方面產生了沒必要要的依賴，更重要的是，總體方案沒法獨立成通用方案。爲了解決這個問題，咱們對Flutter底層進行了深刻的研究。咱們發現Flutter的layer層能夠穩定感知到頁面棧的變化。

而後每一個頁面經過context獲取的router對象做爲標識對一個頁面中的全部的圖片對象進行從新組織。全部獲取到同一個router對象的標識成同一個頁面。這樣就能以頁面爲單位對全部的圖片進行管理。總體上經過LRU的算法來模擬虛擬頁面棧結構。這樣就能對棧底頁面的圖片資源實現回收了。

4.3. 其餘優化

1. 通道的高度複用

首先咱們以一幀爲單位對這一幀中的圖片請求進行聚合，而後在一次通道請求中傳遞給Native的圖片加載框架。這樣能避免頻繁的橋調用。特別在快速滾動等場景下優化效果尤其明顯。

2. 高效的紋理複用

使用外接紋理進行圖片加載之後，咱們發現複用紋理能夠進一步提高性能。舉一個簡單的場景。咱們知道電商場景中，商品展現常常會有標籤，打底圖這樣的圖片。這類圖片每每在不一樣的商品上會出現大量重複。這時候，能夠將已經渲染好的紋理，直接複用給不一樣的顯示組件。這樣能進一步優化GPU內存的佔用，避免重複建立。爲了精確對紋理進行管理，咱們引入了引用計數的算法來管理紋理的複用。經過這些方案，咱們實現了紋理跨頁面高效複用。

此外，咱們將紋理和請求的映射關係移動到了Flutter側。這樣能在最短路徑上完成紋理的複用，進一步減小了橋的通訊的壓力。

4.5. 總體架構

5. 優化效果

因爲最新的版本目前還在灰度，具體數據後續會寫文跟你們詳細介紹。下屬數據主要以方案二爲主。

• 內存優化

  • 經過打通Native，相比於首次上線版本，在顯示效果不變的狀況下，Ios的abort率下降25%，用戶體驗明顯提高。
  • 多頁面棧內存優化

多頁面棧的內存優化，在多頁面場景下對內存優化做用明顯。咱們作了一個極限試驗效果以下：(**測試環境**，非閒魚APP)

​ 可見多頁面棧的優化，能夠將多Flutter頁面的內存佔用控制得更好。

• 包大小減小

經過接入外接紋理，本地資源獲得了更好的複用，包大小下降1M。早期閒魚接入Flutter，會以改造現有頁面爲切入點。資源重複狀況比較嚴重，可是隨着閒魚Flutter 新業務愈來愈多。Flutter和Native的重複資源愈來愈少。外接紋理對包大小的影響已經逐步變弱。

6. 總結

本文介紹了閒魚在Flutter圖片框架方向上所作的持續優化。介紹了閒魚不一樣時期，典型的圖片技術方案的細節。但願能夠給到讀者一些啓發。這是一場沒有盡頭的旅行，咱們對閒魚圖片的優化還會持續。特別是咱們最新的方案，受限篇幅，本文只是作了初步介紹。更多技術細節，包括測試數據，咱們隨後還會專門寫文繼續給你們作介紹。方案完善之後，咱們也會逐步開源。

更多相關內容：點擊這裏​