您好,登錄后才能下訂單哦!
本文小編為大家詳細介紹“Flutter瘦身怎么實現”,內容詳細,步驟清晰,細節處理妥當,希望這篇“Flutter瘦身怎么實現”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來學習新知識吧。
下面我們以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上。
執行如下命令編譯出一個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">
減少flutter和native資源重復造成的體積增大
利用橋接的方式,flutter直接使用Platform端資源文件,避免因為資源文件重復導致的包大小增加問題。
主要方式是通過BasicMessageChannel在Flutter和Platform端傳遞信息。Flutter端將資源名AssetName傳遞給Platform端,Platform端接收到AssetName后,根據name定位到資源文件,并將該文件以二進制數據格式,通過BasicMessageChannel傳遞回Flutter端。
讀到這里,這篇“Flutter瘦身怎么實現”文章已經介紹完畢,想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會,如果想了解更多相關內容的文章,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。