[[399257]]

一、Flutter頁面性能優化的挑戰

淘寶特價版是集團內應用Flutter技術場景比較多，且用戶量一億人以上的應用了。目前我們首頁、詳情、店鋪、我的，看看短視頻，及評價，設置等二級頁面都在用Flutter技術搭建。

我們發現使用Flutter經常會遇到性能問題。因為Flutter嚴格意義上僅是一種“UI渲染框架”，它通過異步來來實現子線程渲染UI，并且通過Skia保證兩端“渲染的一致性”。但子線程執行并渲染，且動態庫打包這些策略并非“一片通吃”，會導致損耗頁面打開性能及可交互時長的增加。試想，app啟動時動態庫加載的dynamic binding(影響啟動時長)，頁面啟動時主線程啟動了頁面，但ui渲染卻需要等待Flutter的子線程執行并渲染，低端機上頁面會短暫白屏(頁面未渲染影響可交互時長，雖然fps欺騙性的提高了)。

Flutter有性能瓶頸，但重度使用Flutter研發的我們是如何做到性能優化的?本篇會就基礎鏈路各Flutter頁面的優化策略，分享我們的實踐!

二、模塊級混合——首頁的優化實踐

首頁最開始是全部采用Flutter+DXFlutter(面向Flutter的UI動態化框架)實現，業務實現一切ok，但發版的時候測試同學發現首頁的啟動性能突然比上個版本跌了1s。這個問題是必然的，因為Flutter是動態庫要延遲加載和綁定，同時DXFlutter大量的模板邏輯也會極大消耗性能。

問題很難解，當時我們就是否繼續全部Flutter，但優化引擎和DXFlutter，還是回退為Native實現產生了分歧。如果回退Native，則首頁及搜索的分類tab技術方案都要切回native，成本巨大。最終，我們根據特價版的現狀及經驗，拍板采用：app啟動時首頁推薦等采用Native實現，但搜索實現的其他tab分類繼續采用Flutter，如此不會對搜索業務研發模式產生影響，又能避免Flutter帶來啟動性能的損耗。

但是該方案會遇到一個技術挑戰：我們使用的Flutter混合棧FlutterBoost僅支持頁面級混合，還不支持頁面內模塊級混合。因為Flutter是單window的設計策略，如果模塊級混合必然會遇到Flutter頁面生命周期的管理及渲染窗口尺寸的一致性問題。

前一個問題是因Flutter是單引擎引起的。當模塊切換的時候，新模塊顯示需要連接引擎重新觸發渲染，否則頁面會空白或不可交互。這個在FlutterBoost中早就做了。

后一個問題是單window，Flutter頁面上彈框Native頁面都會導致頁面布局問題。

但模塊級混合明顯是技術可行的，我們在AliFlutter正物、來一等同學的參與下，很快就開發出了可以容納Native、Flutter甚至其他類型如WebView的模塊級混合容器。如下圖：

我們通過一個FlutterWrapperVC，基于FlutterBoost解決單引擎渲染問題，根據模塊可見性切換FlutterEngine和虛擬機，保證當前可見的模塊能正常渲染，并執行底層的Flutter代碼；然后通過Window大小強制修正解決了單window問題，解決布局問題。最后我們也考慮到了模塊復用性，將這個能力組件化，并封裝到這里：LTaoUIKit。

pod LTaoUIKit '0.0.3.89' 

基于這個方案之后，這么改造后，首頁的啟動實踐至少提升1s。更重要的是首頁的研發就如圍棋里建了兩眼，活出了一片。后面推薦頁基于native dxcontainer實現后，就直接可以復用之前淘寶等成熟app的優化經驗。

后面我們優化RT，DX模板打底，圖標本地化，圖片壓縮多管其下，首頁啟動性能穩穩提升。

同事后面對首頁的啟動鏈路做了分步治理，并做了較為體系化的治理建設：

三、數據預取與FFI——純Flutter頁面的優化實踐

上面探討模塊混合Flutter頁性能優化，本節則講整個頁面均是Flutter實現的優化策略，這應該也是大部分Flutter開發者常遇到的。通過這種方式，以特價版詳情頁為例，我們在之前的優化結果上又再優化了100多ms，以下是具體數據：

• Android(vivo y67): 80～100ms
• iOS(iPhone6): 120~200ms

首先，Flutter頁面會遇到哪些性能瓶頸?從Flutter機制看，他其實是個能較好解決“多端一致問題”的“UI渲染框架”，雖然提供了通過bridge訪問native，但Flutter bridge性能極差，涉及到了線程切換，字符編碼等問題(后面會講)。所以，我們使用Flutter應該避免直接通過Flutter來解決IO等資源訪問的工作，而且這些工作應盡量放在native側。

顯然app一張頁面的啟動，往往涉及到請求服務端準備渲染數據。同時，從路由跳轉，到通過Engine初始化Native的VC或者activity到Engine構造Rasterrizer還涉及Engine層面的線程等待。這些時間其實可以做不少事情，我們可以將服務端數據請求放在這個階段，這就是我們希望做的“數據預取”。

其實“數據預取”在淘寶上已經大規模用了，但在Flutter頁面上所顯示的優越性則會更強，因為Flutter頁的多線程切換太多了，很容易就掉入channel bridge的陷阱。如我們詳情頁最開始也用了數據預取，但數據預取調用是從Flutter發起的，性能似乎有提升，但并不那么明顯。為什么?以下是從Flutter發起一個mtop請求的流程圖，可以從其中一窺究竟：

上圖UI線程是指Flutter的ui線程，并非系統主線程。請求從“開始”處開始，兜兜轉轉，要經歷2次線程切換等待，多次的數據encode和decode，造成的性能損耗還是蠻多的，分析如下：

• 首先，一旦某個情形下設備cpu緊張，則Flutter的請求/數據返回會遲遲無法送達到native或者Flutter。
• 其次，當數據量大的情形下，數據encode和decode也會耗費更多時間。
• 最后，頁面打開經常遇到Engine和Native之間誰先啟動的問題。比如VC啟動了，這個時候并不能馬上就給Flutter發送message，因為Flutter Engine可能還沒有準備好，此時message丟失，雙方都不知道。這個問題在FlutterBoost中遇到不少。

我們最終通過以下策略來解決：

• 數據預取在Native側發起，在頁面路由構造Native VC/Activity時，就馬上發起mtop等請求。
• mtop返回的數據優先不通過channel bridge返回給Flutter層，而是通過ffi機制供Flutter直接讀取。
• 上面native側必須暫存數據，但為避免長久引用造成資源泄漏，采用LRU策略緩存數據(iOS不能用NSCache，猜猜為什么)。
• 考慮到有些頁面數據可以持久化存儲，供下次使用，我們構造了多級緩存策略。
• 將上面能力全部組件化，以供其他業務復用。

詳細的設計如下：

首先，基于ffi和native側數據預取，優化后的數據請求鏈路如下：

右上角之所以還有channel bridge是為解決Native請求返回慢于Flutter頁面渲染的情形下的數據刷新。

其次，我們構建了多級緩存策略和緩存失效及復用策略，以支持部分頁面數據的持久化復用提升首屏渲染性能：

以緩存復用策略為例，我們支持以下策略：

• 激進型：第二次請求直接使用上一次緩存數據，不再馬上刷新數據，待緩存自然過期后刷新。該策略適用于頁面數據不常變的情形。
• 正常型：第二次請求可使用上一次緩存，但仍需請求并馬上刷新數據。該策略比較普適，適合數據變化不頻繁的情形。
• 保守型：第二次請求不可使用上一次緩存，需請求最新數據。適合強實時性的頁面數據渲染。

最后，我們將這些能力做了封裝，比如iOS側，我們以單獨的SDK集成：

pod LTPrefetch '1.0.1.19' 

目前基礎鏈路如詳情，我的，店鋪，mini詳情等都采用了這個方案進行優化，啟動實踐均有了不錯的提升。

四、其他優化實踐

其他還有很多優化實踐。有些是淘系已經實踐過的，有些是特價版根據Flutter的特點有所改動的。這里不詳細說了，僅就我們使用過的列個列表：

• 詳情從首頁借圖。
• 資源壓縮及本地預置：如首頁dx模板預置，Json壓縮及預置，圖片壓縮及預置。
• 數據提前異步加載。如我的頁面數據，其實在用戶登陸的時候就會異步加載并緩存下來，然后通過上面的緩存更新策略來更新。
• 優化服務端RT，精簡協議。

其他。

五、最后

其實我們的優化策略更多在上層應用上做了優化，UC那邊在Flutter Engine層面做了優化，后期可以考慮使用他們引擎，相信頁面打開性能會更上一層樓。

同時上面的ffi及數據預取也可以做的更激進一些。如通過Dart2Native的方式，完全實現Json數據的encode和decode本地實現，容器訪問的本地實現，估計還能提升至少50ms的時間。