Categories
程式開發

Flutter包大小治理上的探索與實踐


Flutter作為一種全新的響應式、跨平台、高性能的移動開發框架,在性能、穩定性和多端體驗一致上都有著較好的表現,自開源以來,已經受到越來越多開發者的喜愛。
但是,Flutter的引入往往帶來包體積的增大,給很多研發團隊帶來了很大的困擾。美團外賣前端團隊對Flutter的包大小問題進行了調研和實踐,設計並實現了一套基於動態下發的包大小優化方案,希望對從事Flutter開發相關的同學能夠帶來一些啟發或者幫助。

一、背景

隨著Flutter框架的不斷發展和完善,業內越來越多的團隊開始嘗試並落地Flutter技術。不過在實踐過程中我們發現,Flutter的接入會給現有的應用帶來比較明顯的包體積增加。不論是在Android還是在iOS平台上,僅僅是接入一個Flutter Demo頁面,包體積至少要增加5M,這對於那些包大小敏感的應用來說其實是很難接受的。

對於包大小問題,Flutter官方也在持續跟進優化:

除了Flutter SDK內部或Dart實現的優化,我們是否還有進一步優化的空間呢?答案是肯定的。為了幫助業務方更好的接入和落地Flutter技術,MTFlutter團隊對Flutter的包大小問題進行了調研和實踐,設計並實現了一套基於動態下發的包大小優化方案,瘦身效果也非常可觀。這里分享給大家,希望對大家能有所幫助或者啟發。

二、Flutter包大小問題分析

在Flutter官方的優化文檔中,提到了減少應用尺寸的方法:在V1.16.2及以上使用—split-debug-info選項(可以分離出debug info);移除無用資源,減少從庫中帶入的資源,控制適配的屏幕尺寸,壓縮圖片文件。這些措施比較直接並容易理解,但為了探索進一步瘦身空間並讓大家更好的理解技術方案,我們先從了解Flutter的產物構成開始,然後再一步步分析有哪些可行的方案。

2.1 Flutter產物介紹

我們首先以官方的Demo為例,介紹一下Flutter的產物構成及各部分佔比。不同Flutter版本以及打包模式下,產物有所不同,本文均以Flutter 1.9 Release模式下的產物為準。

2.1.1 iOS側Flutter產物

Flutter包大小治理上的探索與實踐 1

圖1 Flutter iOS 產物組成示意圖

iOS側的Flutter產物主要由四部分組成(info.plist 比較小,對包體積的影響可忽略,這裡不作為重點介紹),表格1中列出了各部分的詳細信息。

Flutter包大小治理上的探索與實踐 2

表1 Flutter產物組成

2.1.2 Android側Flutter產物

Flutter包大小治理上的探索與實踐 3

圖2 Flutter Android 產物組成示意圖

Android側的Flutter產物總共5.16MB,由四部分組成,表格2中列出了各部分的詳細信息。

Flutter包大小治理上的探索與實踐 4

表2 Flutter Android產物組成

2.1.3 各部分產物的變化趨勢

無論是Android還是iOS,Flutter的產物大體可以分為三部分:

  1. Flutter引擎,該部分大小固定不變,但初始佔比較高。
  2. Flutter業務與框架,該部分大小隨著Flutter業務代碼的增多而逐漸增加。它是這樣的一個曲線:初始增長速度極快,隨著代碼增多,增長速度逐漸減緩,最終趨近線性增長。原因是Flutter有一個Tree Shaking機制,從Main方法開始,逐級引用,最終沒有被引用的代碼,比如類和函數都會被裁剪掉。一開始引入Flutter之後隨便寫一個業務,就會大量用到Flutter/Dart SDK代碼,這樣初期Flutter包體積極速增加,但是過了一個臨界點,用戶包體積的增加就基本取決於Flutter業務代碼增量,不會增長得太快。
  3. Flutter資源,該部分初始佔比較小,後期增長主要取決於用到的本地圖片資源的多少,增長趨勢與資源多少成正比。

下圖3展示了Flutter各資源變化的趨勢:

Flutter包大小治理上的探索與實踐 5

圖3 Flutter各資源大小變化的趨勢圖

2.2 不同優化思路分析

上面我們對Flutter產物進行了分析,接下來看一下官方提供的優化思路如何應用於Flutter產物,以及對應的困難與收益如何。

1. 刪減法

Flutter引擎中包括了Dart、skia、boringssl、icu、libpng等多個模塊,其中Dart和skia是必須的,其他模塊如果用不到倒是可以考慮裁掉,能夠帶來幾百k的瘦身收益。業務方可以根據業務訴求自定義裁剪。

Flutter業務產物,因為Flutter的Tree Shaking機制,該部分產物從代碼的角度已​​經是精簡過的,要想繼續精簡只能從業務的角度去分析。

Flutter資源中佔比較多的一般是圖片,對於圖片可以根據業務場景,適當降低圖片分辨率,或者考慮替換為網絡圖片。

2. 壓縮法

因為無論是Android還是iOS,安裝包本身已經是壓縮包了,對Flutter產物再次壓縮的收益很低,所以該方法並不適用。

3. 動態下發

對於靜態資源,理論上是Android和iOS都可以做到動態下發。而對於代碼邏輯部分的編譯產物,在Android平台支持可執行產物的動態加載,iOS平台則不允許執行動態下發的機器指令。

經過上面的分析可以發現,除了刪減、壓縮,對所有業務適用、可行且收益明顯的進一步優化空間重點在於動態下發了。能夠動態下發的部分越多,包大小的收益越大。因此我們決定從動態下發入手來設計一套Flutter包大小優化方案。

三、基於動態下發的Flutter包大小優化方案

我們在Android和iOS上實現的包大小優化方案有所不同,區別在於Android側可以做到so和Flutter資源的全部動態下發,而iOS側由於系統限制無法動態下發可執行產物,所以需要對產物的組成和其加載邏輯進行分析,將其中非必須和動態鏈接庫一起加載的部分進行動態下發、運行時加載。

當將產物動態下發後,還需要對引擎的初始化流程做修改,這樣才能保證產物的正常加載。由於兩端技術棧的不同,在很多具體實現上都採用了不同的方式,下面就分別來介紹下兩端的方案。

3.1 iOS側方案

在iOS平台上,由於系統的限制無法實現在運行時加載並運行可執行文件,而在上文產物介紹中可以看到,佔比較高的App及Flutter這兩個均是可執行文件,理論上是不能進行動態下發的,實際上對於Flutter可執行文件我們能做的確實不多,但對於App這個可執行文件,其內部組成的四個模塊並不是在鏈接時都必須存在的,可以考慮部分移出,進而來實現包體積的縮減。

因此,在該部分我們首先介紹Flutter產物的生成和加載的流程,通過對流程細節的分析來挖掘出產物可以被拆分出動態下發的部分,然後基於實現原理來設計實現工程化的方案。

3.1.1 實現原理簡析

為了實現App的拆分,我們需要了解下App.framework是怎樣生成以及各部分資源時如何加載的。如下圖4所示,Dart代碼會使用gen_snapshot工具來編譯成.S文件,然後通過xcrun工具來進行彙編和鏈接最終生成App.framework。其中gen_snapshot是Dart編譯器,採用了Tree Shaking等技術,用於生成彙編形式的機器代碼。

Flutter包大小治理上的探索與實踐 6

圖4 App.framework生成流程示意圖

產物加載流程:

Flutter包大小治理上的探索與實踐 7

圖5 Flutter產物加載流程圖

如上圖5所示,Flutter engine在初始化時會從根據FlutterDartProject 的settings中配置資源路徑來加載可執行文件(App)、flutter_assets等資源,具體settings的相關配置如下:

// settings
{
...
  // snapshot 文件地址或内存地址
  std::string vm_snapshot_data_path;  
  MappingCallback vm_snapshot_data;
  std::string vm_snapshot_instr_path;  
  MappingCallback vm_snapshot_instr;

  std::string isolate_snapshot_data_path;  
  MappingCallback isolate_snapshot_data;
  std::string isolate_snapshot_instr_path;  
  MappingCallback isolate_snapshot_instr;

  // library 模式下的lib文件路径
  std::string application_library_path;
  // icudlt.dat 文件路径
  std::string icu_data_path;
  // flutter_assets 资源文件夹路径
  std::string assets_path;
  // 
...
}

以加載vm_snapshot_data為例,它的加載邏輯如下:

加載vm_snapshot_data

std::unique_ptr ResolveVMData(const Settings& settings) {
  // 从 settings.vm_snapshot_data 中取
  if (settings.vm_snapshot_data) {
    ...
  }

  // 从 settings.vm_snapshot_data_path 中取
  if (settings.vm_snapshot_data_path.size() > 0) {
    ...
  }
  // 从 settings.application_library_path 中取
  if (settings.application_library_path.size() > 0) {
    ...
  }

  auto loaded_process = fml::NativeLibrary::CreateForCurrentProcess();
  // 根据 kVMDataSymbol 从native library中加载
  return DartSnapshotBuffer::CreateWithSymbolInLibrary(
      loaded_process, DartSnapshot::kVMDataSymbol);
}

對於iOS來說,它默認會根據kVMDataSymbol來從App中加載對應資源,而其實settings是給提供了通過path的方式來加載資源和snapshot入口,那麼對於flutter_assets、icudtl.dat這些靜態資源,我們完全可以將其移出託管到服務端,然後動態下發。

而由於iOS系統的限制,整個App可執行文件則不可以動態下發,但在第二部分的介紹中我們了解到,其實App是由kDartVmSnapshotData、kDartVmSnapshotInstructions、kDartIsolateSnapshotData、kDartIsolateSnapshotInstructions等四個部分組成的,其中kDartIsolateSnapshotInstructions、kDartVmSnapshotInstructions為指令段,不可通過動態下發的方式來加載,而kDartIsolateSnapshotData、kDartVmSnapshotData為數據段,它們在加載時不存在限制。

到這裡,其實我們就可以得到iOS側Flutter包大小的優化方案:將flutter_assets、icudtl.dat等靜態資源及kDartVmSnapshotData、kDartIsolateSnapshotData兩部分在編譯時拆分出去,通過動態下發的方式來實現包大小的縮減。但此方案有個問題,kDartVmSnapshotData、kDartIsolateSnapshotData是在編譯時就寫入到App中了,如何實現自動化地把此部分拆分出去是一個待解決的問題。為了解決此問題,我們需要先了解kDartVmSnapshotData、kDartIsolateSnapshotData的寫入時機。接下來,我們通過下圖6來簡單地介紹一下該過程:

Flutter包大小治理上的探索與實踐 8

圖6 Flutter Data段寫入時序圖

代碼通過gen_snapshot工具來進行編譯,它的入口在gen_snapshot.cc文件,通過初始化、預編譯等過程,最終調用Dart_CreateAppAOTSnapshotAsAssembly方法來寫入snapshot。因此,我們可以通過修改此流程,在寫入snapshot時只將instructions寫入,而將data重定向輸入到文件,即可實現kDartVmSnapshotData、kDartIsolateSnapshotData與App的分離。此部分流程示意圖如下圖7所示:

Flutter包大小治理上的探索與實踐 9

圖7 Flutter產物拆分流程示意圖

3.1.2 工程化方案

在完成了App數據段與代碼段分離的工作後,我們就可以將數據段及資源文件通過動態下發、運行時加載的方式來實現包體積的縮減。由此思路衍生的iOS側整體方案的架構如下圖8所示;其中定制編譯產物階段主要負責定制Flutter engine及Flutter SDK,以便完成產物的“瘦身”工作;發布集成階段則為產物的發布和工程集成提供了一套標準化、自動化的解決方案;而運行階段的使命是保證“瘦身”的資源在engine啟動的時候能被安全穩定地加載。

Flutter包大小治理上的探索與實踐 10

圖8 架構設計

注:圖例中MTFlutterRoute為Flutter路由容器,MWS指的是美團雲。

3.1.2.1 定制編譯產物階段

雖然我們不能把App.framework及Flutter.framework通過動態下發的方式完全拆分出去,但可以剝離出部分非安裝時必須的產物資源,通過動態下發的方式來達到Flutter包體積縮減的目的,因此在該階段主要工作包括三部分。

1. 新增編譯command

在將Flutter包瘦身工程化時,我們必須保證現有的流程的編譯規則不會被影響,需要考慮以下兩點:

  • 增加編譯“瘦身”的Flutter產物構建模式, 該模式應能編譯出AOT模式下的瘦身產物。
  • 不對常規的編譯模式(debug、profile、release)引入影響。

對於iOS平台來說,AOT模式Flutter產物編譯的關鍵工作流程圖如下圖9所示。 runCommand會將編譯所需參數及環境變量封裝傳遞給編譯後端(gen_snapshot負責此部分工作),進而完成產物的編譯工作:

Flutter包大小治理上的探索與實踐 11

圖9 AOT模式Flutter產物編譯的關鍵工作流程圖

為了實現“瘦身”的工作流,工具鏈在圖9的流程中新增了buildwithoutdata的編譯command,該命令針對通過傳遞相應參數(without-data=true)給到編譯後端(gen_snapshot),為後續編譯出剝離data段提供支撐:

xcode_backend.sh

if [[ $# == 0 ]]; then
  # Backwards-compatibility: if no args are provided, build.
  BuildApp
else
  case $1 in
    "build")
      BuildApp ;;
    "buildWithoutData")
      BuildAppWithoutData ;;
    "thin")
      ThinAppFrameworks ;;
    "embed")
      EmbedFlutterFrameworks ;;
  esac
fi

build_aot.dart

..addFlag('without-data',
        negatable: false,
        defaultsTo: false,
        hide: true,
  )

2. 編譯後端定制

該部分主要對gen_snapshot工具進行定制,當gen_snapshot工具在接收到Dart層傳來的“瘦身”命令時,會解析參數並執行我們定制的方法Dart_CreateAppAOTSnapshotAsAssembly,該部分主要做了兩件事:

  • 定制產物編譯過程,生成剝離data段的編譯產物。
  • 重定向data段到文件中,以便後續進行使用。

具體到處理的細節,首先我們需要在gen_sanpshot的入口處理傳參,並指定重定向data文件的地址:

gen_snapshot.cc

  CreateAndWritePrecompiledSnapshot() {
    ...
    if (snapshot_kind == kAppAOTAssembly) { // 常规release模式下产物的编译流程
      ...
    } else if (snapshot_kind == kAppAOTAssemblyDropData) { 
      ...
      result = Dart_CreateAppAOTSnapshotAsAssembly(StreamingWriteCallback, 
                                                   file, 
                                                   &vm_snapshot_data_buffer,
                                                   &vm_snapshot_data_size,
                                                   &isolate_snapshot_data_buffer,
                                                   &isolate_snapshot_data_size,
                                                   true); // 定制产物编译过程,生成剥离data段的编译产物snapshot_assembly.S
      ...
    } else if (...) {
      ...
    }
    ...
  }

在接受到編譯“瘦身”模式的命令後,將會調用定制的FullSnapshotWriter類來實現Snapshot_assembly.S的生成,該類會將原有編譯過程中vm_snapshot_data、isolate_snapshot_data的寫入過程改寫成緩存到buff中,以便後續寫入到獨立的文件中:

dart_api_imp.cc

// drop_data=true, 表示后瘦身模式的编译过程
// vm_snapshot_data_buffer、isolate_snapshot_data_buffer用于保存 vm_snapshot_data、isolate_snapshot_data以便后续写入文件
Dart_CreateAppAOTSnapshotAsAssembly(Dart_StreamingWriteCallback callback,
                                    void* callback_data, 
                                    bool drop_data,
                                    uint8_t** vm_snapshot_data_buffer,
                                    uint8_t** isolate_snapshot_data_buffer) {
  ...
  FullSnapshotWriter writer(Snapshot::kFullAOT, &vm_snapshot_data_buffer,
                            &isolate_snapshot_data_buffer, ApiReallocate,
                            &image_writer, &image_writer);

  if (drop_data) {
    writer.WriteFullSnapshotWithoutData(); // 分离出数据段
  } else {
    writer.WriteFullSnapshot();
  }
  ...
}

當data段被緩存到buffer中後,便可以使用gen_snapshot提供的文件寫入的方法WriteFile來實現數據段以文件形式從編譯產物中分離:

gen_snapshot.cc

static void WriteFile(const char* filename, const uint8_t* buffer, const intptr_t size);
// 写data到指定文件中
{
  ...
      WriteFile(vm_snapshot_data_filename, vm_snapshot_data_buffer, vm_snapshot_data_size); // 写入vm_snapshot_data
      WriteFile(isolate_snapshot_data_filename, isolate_snapshot_data_buffer, isolate_snapshot_data_size); // 写入isolate_snapshot_data
  ...
}

3. engine定制

編譯參數修改

iOS側使用-0z參數可以獲得包體積縮減的收益(大約為700KB左右的收益),但會有相應的性能損耗,因此該部分作為一個可選項提供給業務方,工具鏈提供相應版本的Flutter engine的定制。

資源加載方式定制

對於engine的定制,主要圍繞如何“手動”引入拆分出的資源來展開,好在engine提供了settings接口讓我們可以實現自定義引入文件的path,因此我們需要做的就是對Flutter engine初始化的過程進行相應改造:

shell /平台/darwin/ios/framework/Headers/FlutterDartProject.h

/**
 * custom icudtl.dat path
 */
@property(nonatomic, copy) NSString* icuDataPath;

/**
 * custom flutter_assets path
 */
@property(nonatomic, copy) NSString* assetPath;

/**
 * custom isolate_snapshot_data path
 */
@property(nonatomic, copy) NSString* isolateSnapshotDataPath;

/**
 *custom vm_snapshot_data path
 */
@property(nonatomic, copy) NSString* vmSnapshotDataPath;

在運行時“手動”配置上述路徑,並結合上述參數初始化FlutterDartProject,從而達到engine啟動時從配置路徑加載相應資源的目的。

engine編譯自動化

在完成engine的定制和改造後,還需要手動編譯一下engine源碼,生成各平台、架構、模式下的產物,並將其集成到Flutter SDK中,為了讓引擎定制的流程標準化、自動化,MTFlutter工具鏈提供了一套engine自動化編譯發布的工具。如流程圖10所示,在完成engine代碼的自定義修改之後,工具鏈會根據engine的patch code編譯出各平台、架構及不同模式下的engine產物,然後自動上傳到美團雲上,在開發和打包時只需要通簡單的命令,即可安裝和使用定制後的Flutter engine:

Flutter包大小治理上的探索與實踐 12

圖10 Flutter engine自動化編譯發布流程

3.1.2.2 發布集成階段

當完成Dart代碼編譯產物的定制後,我們下一步要做的就是改造MTFlutter工具鏈現有的產物發布流程,支持打出“瘦身”模式的產物,並將瘦身模式下的產物進行合理的組織、封裝、託管以方便產物的集成。從工具鏈的視角來看,該部分的流程示如下圖11所示:

Flutter包大小治理上的探索與實踐 13

圖11 Flutter產物發布集成流程示意圖

自動化發布與版本管理

MTFlutter工具鏈將“瘦身”集成到產物發布的流水線中,新增一種thin模式下的產物,在iOS側該產物包括release模式下瘦身後的App.framework、Flutter.framework以及拆分出的數據、資源等文件。當開發者提交了代碼並使用Talos(美團內部前端持續交付平台)觸發Flutter打包時,CI工具會自動打出瘦身的產物包及需要運行時下載的資源包、生成產物相關信息的校驗文件並自動上傳到美團雲上。

對於產物資源的版本管理,我們則復用了美團雲提供資源管理的能力。在美團雲上,產物資源以文件目錄的形式來實現各版本資源的相互隔離,同時對“瘦身”資源單獨開一個bucket進行單獨管理,在集成產物時,集成插件只需根據當前產物module的名稱及版本號便可獲取對應的產物。

自動化集成

針對瘦身模式MTFlutter工具鏈對集成插件也進行了相應的改造,如下圖12所示。我們對Flutter集成插件進行了修改,在原有的產物集成模式的基礎上新增一種thin模式,該模式在表現形式與原有的debug、release、profile類似,區別在於:為了方便開發人員調試,該模式會依據當前工程的buildconfigration來做相應的處理,即在debug模式下集成原有的debug產物,而在release模式下才集成“瘦身”產物包。

Flutter包大小治理上的探索與實踐 14

圖12 Flutter iOS端集成插件修改

3.1.2.3 運行階段

運行階段所處理的核心問題包括資源下載、緩存、解壓、加載及異常監控等。一個典型的瘦身模式下的engine啟動的過程如圖13所示。

該過程包括:

  • 資源下載 :讀取工程配置文件,得到當前Flutter module的版本,並查詢和下載遠程資源。
  • 資源解壓和校驗 :對下載資源進行完整性校驗,校驗完成則進行解壓和本地緩存。
  • 啟動engine :在engine啟動時加載下載的資源。
  • 監控和異常處理 :對整個流程可能出現的異常情況進行處理,相關數據情況進行監控上報。

Flutter包大小治理上的探索與實踐 15

圖13 iOS側瘦身模式下engine啟動流程圖

為了方便業務方的使用、減少其接入成本,MTFlutter將該部分工作集成至MTFlutterRoute中,業務方僅需引入MTFlutterRoute即可將“瘦身”功能接入到項目中。

3.2 Android側方案

3.2.1 整體架構

在Android側,我們做到了除Java代碼外的所有Flutter產物都動態下發。完整的優化方案概括來說就是:動態下發+自定義引擎初始化+自定義資源加載。方案整體分為打包階段和運行階段,打包階段會將Flutter產物移除並生成瘦身的APK,運行階段則完成產物下載、自定義引擎初始化及資源加載。其中產物的上傳和下載由DynLoader完成,這是由美團平台迭代工程組提供的一套so與assets的動態下發框架,它包括編譯時和運行時兩部分的操作:

  1. 工程配置:配置需要上傳的so和assets文件。
  2. App打包時,會將配置1中的文件壓縮上傳到動態發布系統,並從APK中移除。
  3. App每次啟動時,向動態發布系統發起請求,請求需要下載的壓縮包,然後下載到本地並解壓,如果本地已經存在了,則不進行下載。

我們在DynLoader的基礎上,通過對Flutter引擎初始化及資源加載流程進行定制,設計了整體的Flutter包大小優化方案:

Flutter包大小治理上的探索與實踐 16

圖14 Android側Flutter包大小優化方案整體架構

打包階段 :我們在原有的APK打包流程中,加入一些自定義的gradle plugin來對Flutter產物進行處理。在預處理流程,我們將一些無用的資源文件移除,然後將flutter_assets中的文件打包為bundle.zip。然後通過DynLoader提供的上傳插件將libflutter.so、libapp.so和flutter_assets/bundle.zip從APK中移除,並上傳到動態發布系統託管。其中對於多架構的so,我們通過在build.gradle中增加abiFilters進行過濾,只保留單架構的so。最終打包出來的APK即為瘦身後的APK。

不經處理的話,瘦身後的APK一進到Flutter頁面肯定會報錯,因為此時so和flutter_assets可能都還沒下載下來,即​​使已經下載下來,其位置也發生了改變,再使用原來的加載方式肯定會找不到。所以我們在運行階段需要做一些特殊處理:

1. Flutter路由攔截

首先要使用Flutter路由攔截器,在進到Flutter頁面之前,要確保so和flutter_assets都已經下載完成,如果沒有下載完,則顯示loading彈窗,然後調用DynLoader的方法去異步下載。當下載完成後,再執行原來的跳轉邏輯。

2. 自定義引擎初始化

第一次進到Flutter頁面,需要先初始化Flutter引擎,其中主要是將libflutter.so和libapp.so的路徑改為動態下發的路徑。另外還需要將flutter_assets/bundle.zip進行解壓。

3. 自定義資源加載

當引擎初始化完成後,開始執行Dart代碼的邏輯。此時肯定會遇到資源加載,比如字體或者圖片。原有的資源加載器是通過method channel調用AssetManager的方法,從APK中的assets中進行加載,我們需要改成從動態下發的路徑中加載。

下面我們詳細介紹下某些部分的具體實現。

3.2.2 自定義引擎初始化

原有的Flutter引擎初始化由FlutterMain類的兩個方法完成,分別為startInitialization和ensureInitializationComplete,一般在Application初始化時調用startInitialization(懶加載模式會延遲到啟動Flutter頁面時再調用),然後在Flutter頁面啟動時調用ensureInitializationComplete確保初始化的完成。

Flutter包大小治理上的探索與實踐 17

圖15 Android側Flutter引擎初始化流程圖

在startInitialization方法中,會加載libflutter.so,在ensureInitializationComplete中會構建shellArgs參數,然後將shellArgs傳給FlutterJNI.nativeInit方法,由jni側完成引擎的初始化。其中shellArgs中有個參數AOT_SHARED_LIBRARY_NAME可以用來指定libapp.so的路徑。

自定義引擎初始化,主要要修改兩個地方,一個是System.loadLibrary(“flutter”),一個是shellArgs中libapp.so的路徑。有兩種辦法可以做到:

  • 直接修改FlutterMain的源碼,這種方式簡單直接,但是需要修改引擎並重新打包,業務方也需要使用定制的引擎才可以。
  • 繼承FlutterMain類,重寫startInitialization和ensureInitializationComplete的邏輯,讓業務方使用我們的自定義類來初始化引擎。當自定義類完成引擎的初始化後,通過反射的方式修改sSettings和sInitialized,從而使得原有的初始化邏輯不再執行。

本文使用第二種方式,需要在FlutterActivity的onCreate方法中首先調用自定義的引擎初始化方法,然後再調用super的onCreate方法。

3.2.3 自定義資源加載

Flutter中的資源加載由一組類完成,根據數據源的不同分為了網絡資源加載和本地資源加載,其類圖如下:

Flutter包大小治理上的探索與實踐 18

圖16 Flutter 資源加載相關類圖

AssetBundle為資源加載的抽像類,網絡資源由NetworkAssetBundle加載,打包到Apk中的資源由PlatformAssetBundle加載。

PlatformAssetBundle通過channel調用,最終由AssetManager去完成資源的加載並返回給Dart層。

我們無法修改PlatformAssetBundle原有的資源加載邏輯,但是我們可以自定義一個資源加載器對其進行替換:在widget樹的頂層通過DefaultAssetBundle注入。

自定義的資源加載器DynamicPlatformAssetBundle,通過channel調用,最終從動態下發的flutter_assets中加載資源。

3.2.4 字體動態加載

字體屬於一種特殊的資源,其有兩種加載方式:

  • 靜態加載 :在pubspec.yaml文件中聲明的字體及為靜態加載,當引擎初始化的時候,會自動從AssetManager中加載靜態註冊的字體資源。
  • 動態加載 :Flutter提供了FontLoader類來完成字體的動態加載。

當資源動態下發後,assets中已經沒有字體文件了,所以靜態加載會失敗,我們需要改為動態加載。

3.2.5 運行時代碼組織結構

整個方案的運行時部分涉及多個功能模塊,包括產物下載、引擎初始化、資源加載和字體加載,既有Native側的邏輯,也有Dart側的邏輯。如何將這些模塊合理的加以整合呢?平台團隊的同學給了很好的答案,並將其實現為一個Flutter Plugin:flutter_dynamic(美團內部庫)。其整體分為Dart側和Android側兩部分,Dart側提供字體和資源加載方法,方法內部通過method channel調到Android側,在Android側基於DynLoader提供的接口實現產物下載和資源加載的邏輯。

Flutter包大小治理上的探索與實踐 19

圖17 FlutterDynamic結構圖

四、方案的接入與使用

為了讓大家了解上述方案使用層面的設計,我們在此把美團內部的使用方式介紹給大家,其中會涉及到一些內部工具細節我們暫不展開,重點解釋設計和使用體驗部分。由於Android和iOS的實現方案有所區別,故在接入方式相應的也會有些差異,下面針對不同平台分開進行介紹:

4.1 iOS

在上文方案的設計中,我們介紹到包瘦身功能已經集成進入美團內部MTFlutter工具鏈中,因此當業務方在使用了MTFlutter後只需簡單的幾步配置便可實現包瘦身功能的接入。 iOS 的接入使用上總體分為三步:

1. 引入Flutter集成插件(cocoapods-flutter-plugin 美團內部Cocoapods插件,進一步封裝Flutter模塊引入,使之更加清晰便捷)

寶石文件

gem 'cocoapods-flutter-plugin', '~> 1.2.0'

2. 接入MTFlutterRoute混合業務容器(美團內部pod庫,封裝了Flutter初始化及全局路由等能力),實現基於“瘦身”產物的初始化

Flutter 業務工程中引入mt_flutter_route:

pubspec.yaml

dependencies:
  mt_flutter_route: ^2.4.0

3. 在iOS Native工程中引入MTFlutterRoute pod

子檔案

binary_pod 'MTFlutterRoute', '2.4.1.8'

經過上面的配置後,正常Flutter業務發版時就會自動產生“瘦身”後的產物,此時只需在工程中配置瘦身模式即可完成接入:

子檔案

flutter 'your_flutter_project', 'x.x.x', :thin => true

4.2安卓

4.2.1 Flutter側修改

  1. 在Flutter工程pubspec.yaml中添加flutter_dynamic(美團內部Flutter Plugin,負責Dart側的字體、資源加載)依賴。
  2. 在main.dart中添加字體動態加載邏輯,並替換默認資源加載器。

主鏢

void main() async {
   // 动态加载字体
  await dynFontInit();
  // 自定义资源加载器
  runApp(DefaultAssetBundle(
    bundle: dynRootBundle,
    child: MyApp(),
  ));
}

4.2.2 Native 側修改

1. 打包腳本修改

在App模塊的build.gradle中通過apply特定plugin完成產物的刪減、壓縮以及上傳。

2. 在Application的onCreate方法中初始化FlutterDynamic。

3. 添加Flutter頁面跳轉攔截。

在跳轉到Flutter頁面之前,需要使用FlutterDynamic提供的接口來確保產物已經下載完成,在下載成功的回調中來執行真正的跳轉邏輯。

class FlutterRouteUtil {
    public static void startFlutterActivity(final Context context, Intent intent) {
        FlutterDynamic.getInstance().ensureLoaded(context, new LoadCallback() {
            @Override
            public void onSuccess() {
              // 在下载成功的回调中执行跳转逻辑
                context.startActivity(intent);
            }
        });
    }
}

備註:如果App有使用類似WMRoute之類的路由組件的話,可以自定義一個UriHandler來統一處理所有的Flutter頁面跳轉,同樣在ensureLoaded方法回調中執行真正的跳轉邏輯。

4. 添加引擎初始化邏輯

我們需要重寫FlutterActivity的onCreate方法,在super.onCreate之前先執行自定義的引擎初始化邏輯。

MainFlutterActivity.java

public class MainFlutterActivity extends FlutterActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) 
      // 确保自定义引擎初始化完成
        FlutterDynamic.getInstance().ensureFlutterInit(this);
        super.onCreate(savedInstanceState);
    }
}

五、總結展望

目前,动态下发的方案已在美团内部App上线使用,Android包瘦身效果到达95%,iOS包瘦身效果达到30%+。动态下发的方案虽然能显著减少Flutter的包体积,但其收益是通过运行时下载的方式置换回来的。当Flutter业务的不断迭代增长时,Flutter产物包也会随之不断变大,最终导致需下载的产物变大,也会对下载成功率带来压力。

未來,我們還會探索Flutter的分包邏輯,通過將不同的業務模塊拆分來降低單個產物包的大小,來進一步保障包瘦身功能的可用性。

作者介紹

艷東,2018年加入美團,到家平台前端工程師。

宗文,2019年加入美團,到家平台前端高級工程師。

會超,2014年加入美團,到家平台前端技術專家。

本文轉載自公眾號美團技術團隊(ID:meituantech)。

原文鏈接

Flutter包大小治理上的探索與實踐