一、背景

Flutter作为一种全新的响应式、跨平台、高性能的挪动开发框架，在性能、稳定性和多端体验统一上都有着较好的体现，自开源以来，曾经受到越来越多开发者的青睐。随着Flutter框架的一直倒退和欠缺，业内越来越多的团队开始尝试并落地Flutter技术。不过在实际过程中咱们发现，Flutter的接入会给现有的利用带来比拟显著的包体积减少。不论是在Android还是在iOS平台上，仅仅是接入一个Flutter Demo页面，包体积至多要减少5M，这对于那些包大小敏感的利用来说其实是很难承受的。

对于包大小问题，Flutter官网也在继续跟进优化：

  • Flutter V1.2 开始反对Android App Bundles，反对Dynamic Module下发。
  • Flutter V1.12 优化了2.6% Android平台Hello World App大小（3.8M -> 3.7M）。
  • Flutter V1.17 通过优化Dart PC Offset存储以缩小StackMap大小等多个伎俩，再次优化了产物大小，实现18.5%的缩减。
  • Flutter V1.20 通过Icon font tree shaking移除未用到的icon fonts，进一步优化了利用大小。

除了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产物

iOS侧的Flutter产物次要由四局部组成（info.plist 比拟小，对包体积的影响可疏忽，这里不作为重点介绍），表格1中列出了各局部的详细信息。

2.1.2 Android侧Flutter产物

Android侧的Flutter产物总共5.16MB，由四局部组成，表格2中列出了各局部的详细信息。

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各资源变动的趋势：

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等技术，用于生成汇编模式的机器代码。

产物加载流程：

如上图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为例，它的加载逻辑如下：

std::unique_ptr<DartSnapshotBuffer> 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来简略地介绍一下该过程：

代码通过gen_snapshot工具来进行编译，它的入口在gen_snapshot.cc文件，通过初始化、预编译等过程，最终调用Dart_CreateAppAOTSnapshotAsAssembly办法来写入snapshot。因而，咱们能够通过批改此流程，在写入snapshot时只将instructions写入，而将data重定向输出到文件，即可实现 kDartVmSnapshotData、kDartIsolateSnapshotData与App的拆散。此局部流程示意图如下图7所示：

3.1.2 工程化计划

在实现了App数据段与代码段拆散的工作后，咱们就能够将数据段及资源文件通过动静下发、运行时加载的形式来实现包体积的缩减。由此思路衍生的iOS侧整体计划的架构如下图8所示；其中定制编译产物阶段次要负责定制Flutter engine及Flutter SDK，以便实现产物的“瘦身”工作；公布集成阶段则为产物的公布和工程集成提供了一套标准化、自动化的解决方案；而运行阶段的使命是保障“瘦身”的资源在engine启动的时候能被平安稳固地加载。

注：图例中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负责此局部工作），进而实现产物的编译工作：

为了实现“瘦身”的工作流，工具链在图9的流程中新增了buildwithoutdata的编译command，该命令针对通过传递相应参数（without-data=true）给到编译后端（gen_snapshot），为后续编译出剥离data段提供撑持：

if [[ $# == 0 ]]; then  # Backwards-compatibility: if no args are provided, build.  BuildAppelse  case $1 in    "build")      BuildApp ;;    "buildWithoutData")      BuildAppWithoutData ;;    "thin")      ThinAppFrameworks ;;    "embed")      EmbedFlutterFrameworks ;;  esacfi
..addFlag('without-data',        negatable: false,        defaultsTo: false,        hide: true,  )

2.编译后端定制

该局部次要对gen_snapshot工具进行定制，当gen_snapshot工具在接管到Dart层传来的“瘦身”命令时，会解析参数并执行咱们定制的办法Dart_CreateAppAOTSnapshotAsAssembly，该局部次要做了两件事：

  1. 定制产物编译过程，生成剥离data段的编译产物。
  2. 重定向data段到文件中，以便后续进行应用。

具体到解决的细节，首先咱们须要在gen_sanpshot的入口解决传参，并指定重定向data文件的地址：

  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中，以便后续写入到独立的文件中：

// 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来实现数据段以文件模式从编译产物中拆散：

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初始化的过程进行相应革新：

/** * 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：

3.1.2.2 公布集成阶段

当实现Dart代码编译产物的定制后，咱们下一步要做的就是革新MTFlutter工具链现有的产物公布流程，反对打出“瘦身”模式的产物，并将瘦身模式下的产物进行正当的组织、封装、托管以不便产物的集成。从工具链的视角来看，该局部的流程示如下图11所示：

自动化公布与版本治理

MTFlutter工具链将“瘦身”集成到产物公布的流水线中，新增一种thin模式下的产物，在iOS侧该产物包含release模式下瘦身后的App.framework、Flutter.framework以及拆分出的数据、资源等文件。当开发者提交了代码并应用Talos（美团外部前端继续交付平台）触发Flutter打包时，CI工具会主动打出瘦身的产物包及须要运行时下载的资源包、生成产物相干信息的校验文件并主动上传到美团云上。对于产物资源的版本治理，咱们则复用了美团云提供资源管理的能力。在美团云上，产物资源以文件目录的模式来实现各版本资源的互相隔离，同时对“瘦身”资源独自开一个bucket进行独自治理，在集成产物时，集成插件只需依据以后产物module的名称及版本号便可获取对应的产物。

自动化集成

针对瘦身模式MTFlutter工具链对集成插件也进行了相应的革新，如下图12所示。咱们对Flutter集成插件进行了批改，在原有的产物集成模式的根底上新增一种thin模式，该模式在表现形式与原有的debug、release、profile相似，区别在于：为了不便开发人员调试，该模式会根据以后工程的buildconfigration来做相应的解决，即在debug模式下集成原有的debug产物，而在release模式下才集成“瘦身”产物包。

3.1.2.3 运行阶段

运行阶段所解决的外围问题包含资源下载、缓存、解压、加载及异样监控等。一个典型的瘦身模式下的engine启动的过程如图13所示。

该过程包含：

  • 资源下载：读取工程配置文件，失去以后Flutter module的版本，并查问和下载近程资源。
  • 资源解压和校验：对下载资源进行完整性校验，校验实现则进行解压和本地缓存。
  • 启动engine：在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包大小优化计划：

打包阶段：咱们在原有的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确保初始化的实现。

在startInitialization办法中，会加载libflutter.so，在ensureInitializationComplete中会构建shellArgs参数，而后将shellArgs传给FlutterJNI.nativeInit办法，由jni侧实现引擎的初始化。其中shellArgs中有个参数AOT_SHARED_LIBRARY_NAME能够用来指定libapp.so的门路。

自定义引擎初始化，次要要批改两个中央，一个是System.loadLibrary("flutter")，一个是shellArgs中libapp.so的门路。有两种方法能够做到：

  1. 间接批改FlutterMain的源码，这种形式简略间接，然而须要批改引擎并从新打包，业务方也须要应用定制的引擎才能够。
  2. 继承FlutterMain类，重写startInitialization和ensureInitializationComplete的逻辑，让业务方应用咱们的自定义类来初始化引擎。当自定义类实现引擎的初始化后，通过反射的形式批改sSettings和sInitialized，从而使得原有的初始化逻辑不再执行。

本文应用第二种形式，须要在FlutterActivity的onCreate办法中首先调用自定义的引擎初始化办法，而后再调用super的onCreate办法。

3.2.3 自定义资源加载

Flutter中的资源加载由一组类实现，依据数据源的不同分为了网络资源加载和本地资源加载，其类图如下：

AssetBundle为资源加载的抽象类，网络资源由NetworkAssetBundle加载，打包到Apk中的资源由PlatformAssetBundle加载。

PlatformAssetBundle通过channel调用，最终由AssetManager去实现资源的加载并返回给Dart层。

咱们无奈批改PlatformAssetBundle原有的资源加载逻辑，然而咱们能够自定义一个资源加载器对其进行替换：在widget树的顶层通过DefaultAssetBundle注入。

自定义的资源加载器DynamicPlatformAssetBundle，通过channel调用，最终从动静下发的flutter_assets中加载资源。

3.2.4 字体动静加载

字体属于一种非凡的资源，其有两种加载形式：

  1. 动态加载：在pubspec.yaml文件中申明的字体及为动态加载，当引擎初始化的时候，会主动从AssetManager中加载动态注册的字体资源。
  2. 动静加载：Flutter提供了FontLoader类来实现字体的动静加载。

当资源动静下发后，assets中曾经没有字体文件了，所以动态加载会失败，咱们须要改为动静加载。

3.2.5 运行时代码组织构造

整个计划的运行时局部波及多个功能模块，包含产物下载、引擎初始化、资源加载和字体加载，既有Native侧的逻辑，也有Dart侧的逻辑。如何将这些模块正当的加以整合呢？平台团队的同学给了很好的答案，并将其实现为一个Flutter Plugin：flutter_dynamic（美团外部库）。其整体分为Dart侧和Android侧两局部，Dart侧提供字体和资源加载办法，办法外部通过method channel调到Android侧，在Android侧基于DynLoader提供的接口实现产物下载和资源加载的逻辑。

四、计划的接入与应用

为了让大家理解上述计划应用层面的设计，咱们在此把美团外部的应用形式介绍给大家，其中会波及到一些外部工具细节咱们暂不开展，重点解释设计和应用体验局部。因为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：

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 Android

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之前先执行自定义的引擎初始化逻辑。

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年退出美团，到家平台前端技术专家。

招聘信息

美团外卖长期招聘Android、iOS、FE 高级/资深工程师和技术专家。欢送感兴趣的同学投递简历至：tech@meituan.com（邮件题目请注明：美团外卖技术团队）。

浏览更多技术文章，请扫码关注微信公众号-美团技术团队！