freeline Freeline：极速编译方案的开源之路

在“阿里开源项目最佳实践”上，蚂蚁金服客户端开发工程师黄勇分享了Freeline的整个开源过程和变化。他从不同角度描述了Freeline整个技术的底层原理和编译加速方案的比较，分享了Freeline开源以来的收获和经验。

以下内容根据现场分享和幻灯片进行组织。

Freeline是一个非常快速的编译工具，它的诞生主要是为了满足当前工程的需要，实现更好的动态性。Freeline最初是为了支持ant fortune的应用架构(mPaaS，插件架构)的增量编译而诞生的。2016年8月在AlibabaGithub上开通，至今累计3244星。目前是AlibabaGithub下的十大开源项目，已有数千个应用连接到Freeline，Freeline可能是东半球用户数量最多的第三方编译工具。

为什么选择Freeline？

目前市面上有很多类似Freeline的工具，比如谷歌官方的Instant Run，Facebook-buck，安卓的JRebel等。Freeline与这些工具相比有什么优势？我们来看看。

即时运行

首先介绍一下谷歌官方即时运行。它的优点是安卓工作室可以随身携带。下载后默认开启所有功能，零配置。与其他方案相比，它是最稳定的，基本上没有侵入性影响。即时运行可以在1s或2s内完成所有编译效果。其缺点是:一是对增量编译的支持有限，使得所有代码修改都无法支持增量编译，尤其是跨模块修改。比如一些大型的安卓项目，不是单个Module，而是几十个。如果工程师跨两三个模块同时修改编译，一般来说，Instant Run只完整编译，因为目前不支持这样的修改；其次，修改Java文件将重新启动整个应用程序。比如你要修改一个页面，可能是4-5级。进入更深层次后，使用Instant Run可能会使APP返回到原页面，进入深层次需要4-5步；另外，当植入ASM时，Instant Run植入一段自己的代码。增量修改后无法Debug，带来调试困难；Instant Run不能支持复杂的工程结构(主要指十几个模块的非常复杂的项目)，也不支持Kotlin和Jack。

脸书-巴克/优步-奥克巴克

Facebook-Buck是Facebook生产的，采用内部统一建设系统。Facebook整个后端的服务器工程包括iOS工程或者Android工程，基本都是Buck作为一个构建系统来构建的。然而，使用Buck需要一些额外的系统配置，这对几乎没有接触过Buck的工程师来说是一个相对较高的门槛。Okbuck是一个开源工具，帮助Gradle项目快速整合buck，目前由Uber维护。Buck的核心出发点是多线程开发和编译，充分利用缓存。Buck将一个Module拆分成各种小模块，大致达到增量编译效果和加速效果。而且它的效果很好，十秒钟就能编完。再者，Buck已经支持了目前非常流行的Retrolambda表达式的插件。

当然，巴克也有其局限性。对于有历史包袱的大型项目的准入，接触Buck的成本很高。施工流程和Gradle不一样。即使有Okbuck的帮助，Gradle的很多东西也需要工程师做特殊的改编才能用在buck身上。他们学习曲线高(国内相关资料不多)，无法快速使用社区最新技术。此外，巴克需要重新安装APK。在Android 7.0之前，一台APK 30M左右的安装时间甚至可以达到30 s以上，虽然编译过程可能需要十几秒，但整个安装过程，包括重新进入页面的过程，可能需要1分钟等待编译重启调试。Buck不支持Windows。有的国内工程师会有所顾忌，没有办法快速接近；它不支持Kotlin，这也是一些使用新技术的公司所担心的。

安卓开发插件

JRebel是来自国外开发公司Zeroround的开发工具，是比InstantRun更早的增量编译工具。Zeroround公司最早做JVM热部署，支持Spring和SSH框架，积累了大量的实践，做了大量的优化和性能。如果你想找一个即时Trunn的替代品，JRebel是个不错的选择。它是一个几乎零配置的项目，只需要安装一个插件就可以立即运行。Zeroround在这方面花了不少精力，支持Retrolambda和大量流行的Android开发组件库。原理是字节码级的动态加载，所以理论上支持Kotlin、Groovy等基于JVM的语言。

这个工具也有一些缺陷，最大的问题是收费，很贵，但是现在可以免费试用一年。而且不支持DataBinding，只有付费版才能调试。由于热部署功能和基于字节码级别的动态加载，没有办法使用IDE集成的Debug插件，所以必须使用JRebel为Android提供的插件进行调试。还有Crash之后又需要全编译，单次全编译安装速度很慢。它不支持杰克。

漂移板

那么Freeline与这些工具相比有什么优势呢？

目前Freeline已经支持了大部分场景的增量编译和Java文件的修改，比Instant Run更广。目前支持Retrolambda和APT，部分支持DataBinding。因为我们自己的开发中没有使用数据绑定，所以我们只能说在自测的范围内已经支持了数据绑定的大部分特性。但是支持可能是不完全的，也是在连续迭代中，这也是后期迭代要注意的事情；还有一个好处就是支持SO文件的动态替换，尤其是一些地图应用或者旅行应用，对于整个开发调试都会非常有用。这也是Freeline和目前几种开发工具的区别；同时Freeline的增量资源是真正的增量资源，可以达到几十K甚至几百K，I/O很小。如果仔细看看Instant Run打包的资源包，整个I/O传输需要很长时间。比如在不同的USB环境下，对于十几米的资源包，由于Freeline确实让资源包达到了增量级别，所以会让传输速度达到7秒或者8秒，整个增量传输非常快。它支持Windows/Linux/Mac，因此覆盖的用户范围更广。比JRebel更好的是Appcrash之后，仍然可以增量编译修复，基本不需要重新安装。因此，通过再次修改代码并运行Freeline插件，可以立即完成整个增量修复。

Freeline也有一些缺点，因为用的是十几个模块的比较复杂的项目进行改编，所以单模块项目基本没有优势，直接用Instant Run比较好。其次，黑客方案的本质导致了不可避免的兼容性问题。另外，它不支持删除ID为的资源，所以在删除资源ID时，可能需要重新运行Freeline进行完全编译。它也不支持科特林和杰克。

自由线原理

Freeline的本质是在基于Gradle的系统上构建一个Hack解决方案。去年是热替换爆发的一年，Freeline实际上是热替换方案在编译时的实际应用，实现实时热替换，即实现整体增量编译效果。黑客方案本身就存在兼容性问题。理论上充分利用多核性能，多级缓存，尽可能减少不必要的编译步骤。从上图可以简单分析Freeline过程。除了主进程，Freeline进程会独立运行，会有Socket链。整个Patch过程将通过Freeline进程与主进程的通信来完成，实现热替换，这也是它的运行模式。

Freeline完全编译

上图是Freeline完整的编译过程。从图中可以看出，中间有一个过程，就是gradle-full-build-with-Freeline。Freeline在Gardle全编译的整个过程中嵌入了Hack。在黑客攻击过程中，收集模块之间的依赖关系，包括依赖文件的存储位置。整个过程完成后，将执行构建-基础-res过程。如果只看Gradle的资源编译过程，Gradle会合并所有的资源，这将导致在编译资源时没有办法进一步处理和编译编译已编译的资源。因此，Freeline在此基础上构建-base-RES，并构建完整的资源包，为后续的增量资源做准备。通过这个图，我们可以清楚地看到对应的并发和依赖关系。

Freeline增量编译

接下来，看看Freeline增量编译过程。从右图可以看出，中间流水线下来后，整个并发过程是多模块编译的，可以达到最小粒度的编译单元。如果对比一下Facebook的Buck，你会发现Buck的编译是基于Module的，也就是说如果整个项目的Module没有做好，Buck就达不到十倍以上的提速编译效果。所以如果用Buck代替Freeline，整个项目的架构模式会被深度拆分成几个更小的模块，尽可能的对Freeline进行索引合并。Dx过程非常耗时。在Gradle的原始编译过程中，所有的模块编译和类编译都是合并的。为了达到更好的加速效果，省略了很多不必要的步骤，统一编译所有资源，单独进行统一的增量资源编译。像整个数据绑定一样，基于新的增量过程生成一个新的Java文件。在资源编译过程中，对整个R文件进行动态修改，使新添加的资源ID可以在后续编译过程中输入最新的ID并传递给Java Module，然后进行Merge-dex实现增量编译，最后完成Sync同步，实现资源编译。

整个过程也有一些缺陷。如果类图是由整体量生成的，那么在增量过程中是没有办法实现的。因为我们在增量过程中无法得到类依赖的全部量，这是Freeline无法支持的地方。如果想让路由组件支持Freeline编译，需要单独扩展开发路由资源，使用Freeline作为调用，实现整个Freeline的扩展和实现。

未来规划

接下来说说Freeline未来的规划进展。首先关注一下AndroidGradlePlugin的最新动态:

谷歌去年发布Android Gradle Plugin2.2.0的时候说，如果上一个版本的Instant Run关闭了，那么这个版本的Instant Run是值得打开的。因为这个版本对它做了很大的优化和改进，包括对多模块工程的支持，所以有了很大的改进，但是编译速度不是特别理想。从上表的对比可以看出，对于100 Module的测试，2.2.0版在配置阶段用了将近2 m分钟，只修改一个Java文件就花了这么长时间，而使用Freeline用的时间却没有这么多。因为如果没有工程变更，可能会跳过配置等流程。Google正式推出2.3版，可以减为9s，2.5版声称可以达到2.5s配置时间，6.4s内可以更改一行Java文件，马上生效。这是一个很大的性能提升，所以这也是Freeline未来会继续跟进的技术进步，看能否反馈到Freeline的开发过程中，实现更好的开发过程。

Freeline还将跟进谷歌的AAPT2的进展。看看LSP源代码，可以发现谷歌的很多源代码其实都是AAPT2编译的。AAPT2真的很像C++中的模块化编译和单元编译。它将每个模块的资源编译成一个单独的资源包，最后通过一个链接命令将所有编译好的资源包编译成最终的APK。这实际上表明，如果项目暴露给AAPT2，如果只改变一个Module，只需要用AAPT2编译一个Module，然后对这100个Module使用link命令，几乎可以达到增量的效果。因为耗时的编译过程只能到达新的资源包一次，这是目前AAPT2整个技术的实现。AAPT2对6.0或者7.0的整个源代码做了很大的改动。目前已经实现了使用AAPT2封装资源包的功能，接下来就看整个AAPT2是否值得访问和实现了。

后期Freeline还会跟进最近比较流行的Kotlin和Jack，希望以后能对这两个工具给予更好的支持。Kotlin用于社区发展等很多新项目，包括阿里内网。Jack也是谷歌几年前推出的。希望Freeline能在以后的迭代中支持这两个编译工具。

如何整合？

现在Freeline的整合很简单。直接搜索Freeline，会有一个插件，一键安装后自动配置整合整个环境。如果项目比较复杂，有几十个Module，需要特殊配置，也可以参考官网的文档。Freeline未来将继续朝着一键式集成和无缝集成的方向发展。

免费在线的开源课程

最后介绍一下Freeline的整个开源过程:

(1)Freeline始于2015年10月。原来是一个3000多行的Python文件。它只支持基于Maven的mPssS框架项目，最长编译时间为30分钟。后来缩短为10s增量编译，项目效率实现了质的飞跃。

(2)2016年5月重建，可以支持阿里集团Gradle搭建的Android项目和开源。然后在2016年8月实现开源，当天在Github Trending上市。

(3)2016年12月，Freeline再次实现发展，被多家技术微信官方账号推荐转载。连续一个月出现在Github Java Trending列表上，很多关于Freeline的技术文章开始在社区中讨论。在APT、Retrolambda和DataBinding的支持下，我们不断提高兼容性，引入IDE插件，以满足社区的需求。