flutter打包的app有多大_Flutter包大小治理上的探索与实践

Flutter作为一种全新的响应式、跨平台、高性能的移动开发框架，在性能、稳定性和多端体验一致上都有着较好的表现，自开源以来，已经受到越来越多开发者的喜爱。
但是，Flutter的引入往往带来包体积的增大，给很多研发团队带来了很大的困扰。美团外卖前端团队对Flutter的包大小问题进行了调研和实践，设计并实现了一套基于动态下发的包大小优化方案，希望对从事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 实现原理简析