如何缩减接近 50% 的 Flutter 包体积

---

我们先来统一认识，包体积到底重要不重要？结论是很重要。

右图是 Google 2016 年公布的研究报告，核心思想是包体积每上升 6MB 就会带来下载转化率降低 1%，当包体积增大到 100MB 时就会有断崖式的下跌。这是 2016 年的数据，现在流量虽然变得更廉价一点，但是用户的心理是不会变的。可能 6MB 这个数据现在变成 10MB 或者 20MB，但是当你 APP 出现在应用市场的相同位置时，包体积越大，用户下载意愿就越低，这是毫无疑问的。所以我们的结论是：包体积很重要，需要优化。

那现状是什么？结合今日头条的数据：Android 可以动态下发，我们现在使用的插件化框架，包体积增量约等于 0，即便是大家没有插件化，也可以用各种方式使包体积增量约等于 0。至于为什么安卓可以做我们后续会讲到。但 iOS 上是什么情况呢？今日头条 APP 优化前包体积是 167M，Flutter 产物占 18MB，占比超过了 10%。那看到这个数据的结论就是：现阶段需要重点关注并优化 Flutter 在 iOS 平台上的包体积问题。

那我们引用 Flutter 之后会对现有的包体积产生多大影响呢？结论很出乎意料，iOS 平台上，如果用 OC 写，它大概是一个线性增长的关系，随着代码量增加，包体积也会这样增加；但是 Flutter 不是，它不是一个线性的关系，它是这样的一个曲线：初始增长速度极快，随着代码增多，增长速度逐渐减缓，最终趋近线性增长。原因是 Flutter 有一个 Tree Shaking 机制，从 Main 方法开始，逐级引用，最终没有被引用的代码，诸如类和函数都会被裁剪掉。

这个机制在 iOS 里没有，但是在 Android 里挺常见的，类似 ProGuard，安卓开发工程师应该很熟悉这个概念。一开始引入 Flutter 之后随便写一个业务，你就会大量用到 Flutter/Dart SDK 代码，这样初期 Flutter 包体积极速增加，但是过了一个临界点，用户包体积的增加就基本取决于你 Flutter 业务代码增量，不会增长得那么快。

所以我们分析 Flutter Release 产物的时候是不能用太简单的 Demo 的，如果你只是在屏幕上绘制一个 Hello World Text，包体积就会非常小，脱离实际的小，因为大部分 Flutter SDK 就都会被 Tree Shaken 掉了。但是实际的项目不是这样的，我们需要写个稍微复杂一点的项目让包体积超过临界点，但是又不能超过太多，否则编译时间就会非常长，优化包体积时需要反复的编译，这样开发效率和优化效率就会降低。我们就写了这么一个简单的 Demo，这个 Demo 有一个按钮、用到了 Material Design 库的一些控件，屏幕背后还用一些类做了一些别的事情，最终编译出来之后长成这样子。

组成部分是两个 Framework，一个是 APP Framework，还有一个是 Flutter Framework，后面会讲这两个 Framework 主要由什么组成。

画了一张图给大家详细解释一下：

第一部分是 App Framework，里面的 App 在我这个 Demo 工程下是 9.2M，主要来源是 Dart 代码 AOT 编译产物，它是一个动态链接库；还有一部分是 Flutter 静态资源，内含图片，字体等，注意这一部分是一个变值，它是随着你的业务变化而变化的，有可能增加，有可能减少。在我的这个工程里，flutter_assets 基本没有东西，但是不等于你的项目 flutter_assets 没有东西，同样这个 9.2M 的 App 在你的工程里可能就不是 9.2MB 了。

而 Flutter.Framework 里则是一个定值，一个固定的值。第一部分是 Flutter 这个动态编译库，也就是我们的 Flutter Engine，他是由用 Flutter 底层和 Dart 语言的的 C++代码编译而成的。这个部分的大小主要是看用哪个分支或者哪个版本打出来的，基本上编译 100 次，无数次都是这么大，我们现在是 7.3MB。还有一个 icudtl.dat，国际化支持相关数据文件，883KB，基本可以忽略不计。

二、Dart 编译产物生成与优化

---

在我们讲包体积优化前，先讲一下包体积优化的方法论。启动速度有方法论，包体积也有方法论。包体积的优化无非是三个方式：删、缩、挪。