Flutter瘦身大做戰

背景

閒魚技術團隊於2018年上半年率先引入了Flutter技術實現客戶端開發，到目前爲止成功改造並上線了複雜的商品詳情和發佈業務。隨着改造業務的增多，安裝包體積急劇上增。安裝包體積決定了用戶等待下載的時間和可能會耗費的流量，如何控制安裝包體積，減少flutter產物的大小成爲當務之急。本文從閒魚客戶端項目實踐角度給出了一些通用的包大小檢測以及優化方案，但願爲對Flutter感興趣的團隊提供參考。

閒魚客戶端採用的Flutter和Native混合開發的模式，下面咱們以ios端爲例分析項目中flutter產物的大小（ipa包瘦身需求更爲急切）。

ios工程對Flutter有以下依賴：

• Flutter.framework : Flutter庫和引擎
• App.framework:dart業務源碼相關文件
• Flutter Plugin：編譯出來的各類plugin的framework
• flutter_assets：Flutter依賴的靜態資源，如字體，圖片等

第一次引入flutter版本改造詳情頁後，ipa包大小增長近20M，其中包括flutter引擎代碼+被改造業務代碼，繼續發佈頁flutter改造後，ipa增長4M+。進一步分析解壓ipa文件後發現Flutter.framework穩定保持在20M+的大小, 增長新的flutter業務——發佈頁以後，App.framework增幅近10M!

Flutter.framework是Flutter庫和引擎的代碼，咱們能作的優化空間有限，先把目標放在dart業務相關的文件App.framework上。

Flutter產物大小分析

執行以下命令編譯出一個release模式下的App.framework，並使用print-snapshot-sizes參數打印出產物具體大小

flutter build aot --release --extra-gen-snapshot-options=--print-snapshot-sizes

結果以下：

Building AOT snapshot in release mode (android-arm-release)...      
VMIsolate(CodeSize): 4660
Isolate(CodeSize): 2585632
ReadOnlyData(CodeSize): 2693576
Instructions(CodeSize): 8064816
Total(CodeSize): 13348684
Built to build/aot/.

Instructions：表明AOT編譯後生成的二進制代碼大小

ReadOnlyData：表明生成二進制代碼的元數據（例如PcDescriptor， StackMap，CodeSourceMap等）和字符串大小

VMIsolate/Isolate：表明剩下的對象的大小總和（例如代碼中定義的常量和虛擬機特定元數據）

具體到業務層，想要分析各個業務模塊所佔用的大小該怎麼辦呢？

1. 執行以下命令編譯出一個arm64架構的App.framework,並將它的包組成結構放到指定目錄build/aot.json文件中

   flutter --suppress-analytics build aot --output-dir=build/aot --target-platform=ios --target=lib/main.dart --release --ios-arch=arm64 --extra-gen-snapshot-options="--dwarf_stack_traces,--print-snapshot-sizes,--print_instructions_sizes_to=build/aot.json"

2. 使用dart命令將上一步生成的aot.json文件轉化成結構可視化的網頁

   dart ./bin/run_binary_size_analysis.dart  build/aot.json path_to_webpage_dir

run_binary_size_analysis.dart是dart提供的一個分析工具，在flutter引擎源碼中路徑以下:

1. 打開生成文件夾中的index.html便可分析具體業務所佔用的大小，右上角的Large Symbols和Large Files按鈕能夠直接定位體積佔比從大到小的方法/文件。

舉個例子，上面的分析顯示PItemInfoInternal.fromJson方法佔用了大量體積，跟蹤發現這個方法主要的操做是將Map數據轉化成對象

PItemInfoInternal.fromJson(Map<dynamic, dynamic> map) {
        id = map['id'] as String;
        attributes = map['attributes'] as String;
        title = map['title'] as String;
        ......
}

由此咱們能夠推斷這種類型轉換的操做會致使編譯生成一些體積很大的代碼。

優化措施

1. 減小顯示類型轉換操做

按照上述分析發現顯示的類型轉換 as String/Bool/Int 這類操做會致使App.framework體積顯著增長，主要是它會增長類型檢查以及拋出異常的處理邏輯:

if (x.classId < A && x.classId > B) throw "x is not subtype of String";

經過提取靜態公用方法的方式能夠成功減小400k+體積。

1. 經過編譯參數 --dwarf_stack_trace和--obfuscate減少生成代碼的體積

dwarf_stack_trace表示在生成的動態庫文件中，不使用堆棧跟蹤符號

obfuscate表示混淆，經過減小變量名/方法名的方式減少代碼體積

//編譯release包並打印size
flutter build aot --release --extra-gen-snapshot-options=--print-snapshot-sizes
//--dwarf_stack_traces， -->減小6.2%大小
flutter build aot --release --extra-gen-snapshot-options="--dwarf_stack_traces,--print-snapshot-sizes"
//--obsfuscation， -->減小2.5%大小
flutter build aot --release --extra-gen-snapshot-options="--dwarf_stack_traces,--print-snapshot-sizes,--obfuscate"

//總大小減小8.7%

1. 經過修改ios打包腳本xcode_backend.sh，刪除dSYM符號表信息文件，App.framework成功減少20%的大小。dSYM 是保存 16 進制函數地址映射信息的中轉文件，包含咱們調試的 symbols，用來分析 crash report 文件，解析出正確的錯誤函數信息。

使用xcrun命令將dSYM從framework中剝離出來，能夠大大減少App.framework的體積。

RunCommand xcrun dsymutil -o "${build_dir}/aot/App.dSYM" "${app_framework}/App"
RunCommand xcrun strip -x -S "${derived_dir}/App.framework/App"

1. 減小flutter和native資源重複形成的體積增大

利用橋接的方式，flutter直接使用Platform端資源文件，避免由於資源文件重複致使的包大小增長問題。

主要方式是經過BasicMessageChannel在Flutter和Platform端傳遞信息。Flutter端將資源名AssetName傳遞給Platform端，Platform端接收到AssetName後，根據name定位到資源文件，並將該文件以二進制數據格式，經過BasicMessageChannel傳遞迴Flutter端。

總結

引入Flutter帶來的安裝包體積問題會給不少技術團隊帶來困擾。經過以上措施，Flutter產物App.framework的大小減小30%+，閒魚技術團隊後續也會考慮採起下載並懶加載等方式減小資源佔用的體積；繼續代碼生成中的各類對比，排查避免較大產物的寫法，同時也會和Google一塊兒進一步尋找優化空間。

參考

• https://github.com/flutter/flutter
• https://github.com/flutter/engine
• https://github.com/flutter/flutter/issues/21813
• https://github.com/flutter/flutter/issues/20671

雲服務器99元拼團購！拉新還可贏現金紅包！300萬等你瓜分！
立刻一鍵開團贏紅包： http://click.aliyun.com/m/100...

---

本文做者：閒魚技術-三蒞

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。