作者：閒魚技術-三蒞
背景
閒魚技術團隊於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：代表剩下的物件的大小總和（例如程式碼中定義的常量和虛擬機器特定後設資料）
具體到業務層，想要分析各個業務模組所佔用的大小該怎麼辦呢？
-
執行如下命令編譯出一個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" 複製程式碼 -
使用dart命令將上一步生成的aot.json檔案轉化成結構視覺化的網頁
dart ./bin/run_binary_size_analysis.dart build/aot.json path_to_webpage_dir 複製程式碼run_binary_size_analysis.dart是dart提供的一個分析工具，在flutter引擎原始碼中路徑如下:
-
開啟生成資料夾中的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;
......
}
複製程式碼由此我們可以推斷這種型別轉換的操作會導致編譯生成一些體積很大的程式碼。
優化措施
-
減少顯示型別轉換操作
按照上述分析發現顯示的型別轉換
as String/Bool/Int這類操作會導致App.framework體積顯著增加，主要是它會增加型別檢查以及丟擲異常的處理邏輯:if (x.classId < A && x.classId > B) throw "x is not subtype of String"; 複製程式碼通過提取靜態公用方法的方式可以成功減少400k+體積。
-
通過編譯引數
--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%
複製程式碼-
通過修改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"
複製程式碼-
減少flutter和native資源重複造成的體積增大
利用橋接的方式，flutter直接使用Platform端資原始檔，避免因為資原始檔重複導致的包大小增加問題。
主要方式是通過BasicMessageChannel在Flutter和Platform端傳遞資訊。Flutter端將資源名AssetName傳遞給Platform端，Platform端接收到AssetName後，根據name定位到資原始檔，並將該檔案以二進位制資料格式，通過BasicMessageChannel傳遞迴Flutter端。
總結
引入Flutter帶來的安裝包體積問題會給很多技術團隊帶來困擾。通過以上措施，Flutter產物App.framework的大小減少30%+，閒魚技術團隊後續也會考慮採取下載並懶載入等方式減少資源佔用的體積；繼續程式碼生成中的各種對比，排查避免較大產物的寫法，同時也會和Google一起進一步尋找優化空間。
閒魚期待你的加入
歡迎加入閒魚，一起探索Flutter更多可能。 簡歷投遞：guicai.gxy@alibaba-inc.com