QQ音乐Android端120万行代码，编译耗时是怎样优化的

介绍QQ音乐团队在增量编译组件研发上的探索与实践。
原文：QQ音乐Android编译提速之路

1. 序言

工程编译，是Android应用开发工作中的重要一环。而随着工程代码量膨胀，编译耗时也越来越长，拖慢了开发效率。

这个问题在中大型团队中并不少见。以QQ音乐为例，Android工程代码量达到120万行以上，每修改一行代码，都要等待4分钟以上才能在手机上看到改动效果。

为了应对这个问题，我们自研推出了一款增量编译组件。经过一年时间的不断优化，组件已经可以支撑团队内的日常开发工作，有效提升了本地开发场景下的编译效率。

本文将会介绍QQ音乐团队在增量编译组件研发上的探索与实践历程。

2. 问题分析

本地开发过程中，我们会不断重复 修改代码-编译工程-安装APK-运行验证 这一过程。

因此，可以从编译与安装两个纬度来分析编译慢的原因。

首先是编译阶段。

其主要流程是，先收集工程中的所有资源文件进行编译，得到资源包以及资源索引类。随后资源索引类会跟随工程的所有代码文件，一起被编译为字节码文件，字节码文件还需要被进一步编译为Dex文件，这样才能被Android虚拟机所识别。

待资源包和Dex文件都准备好后，会被打包压缩到一起，执行签名、对齐等流程，最终完成编译，得到一个APK安装包。

在这个过程中，不论是资源编译还是代码编译，耗时都是与待编译的文件数量成正比的。我们在开发过程中，一般只会改动极少数的代码文件，然后触发编译。理想的情况是，编译工具应当只编译这些被改动的文件。但是由于代码的依赖关系，这在原生工具下很难实现。

Android Gradle Plugin自3.0版本开始，开始废弃compile关键字，并引入implementation关键字来声明依赖，是希望可以从module的粒度，去加快大型项目的编译速度。不过对于一些并未拆分多module的单一工程项目来说，使用效果并不理想。

再来看安装阶段。

安装包首先需要通过ADB工具传输到手机上，然后系统对其进行签名校验。校验成功后，还需要进行一系列文件解压、拷贝的操作。例如拷贝Dex文件、so文件等。

此外，如果是在系统版本为5.0、6.0的手机上，由于系统采用了AOT机制，安装过程中会进行预编译，将Dex中的字节码变成机器码，以提高应用运行时的效率，这就导致了安装耗时进一步被拉长。

可以看到，安装包体积、手机系统版本，都会影响到安装阶段的耗时。

3. 优化思路

根据上述分析，主要有三类解决方案。

工欲善其事，必先利其器，首先可以尝试对工程的构建工具链进行优化。

常见的方式是升级Android Gradle Plugin、Gradle等工具的版本、调整构建参数等。不过实践后发现，他们带来的优化效果并不理想。

当然，除了Gradle构建工具外，也可以考虑使用Facebook的Buck作为构建工具。根据官方介绍， 它利用多模块、多任务并行编译的思想，可以大幅度缩短编译耗时。

不过对于大型项目来说，要迁移构建工具，成本是极高的。目前使用的众多插件、周边开发工具链，都是基于Gradle体系的，迁移的话就会失去这些功能的支持；此外，如果工程还涉及到其他团队、项目的协作，构建方案也是无法随意更换的。

另外一种思路是，对工程代码进行优化，尽可能减少参与编译的代码数量。

这里可以做的事情很多，比如梳理业务删除冗余代码、进行多工程拆分、实施组件化（模块化）改造等；但是，由于代码耦合深、开发节奏紧等客观因素的存在，代码优化的难度通常比较大，各个方案的实施周期会比较长。所以并不能在短期内，快速解决编译缓慢的问题。

那么，能不能提供一个编译工具：在本地开发期间，每次仅编译被改动过的少量代码，而且最好可以跳过APK的安装过程，仅推送与加载新改动的代码。这样就可以从编译与安装两个纬度，去大幅缩减编译耗时。

这其实就是增量编译工具的核心思想。对于工具的接入方来说，不需要大刀阔斧地升级工具链或者进行工程改造，即可在较低的成本下，快速提高本地开发效率。

截止目前，业界主要有两款方案可以参考。

Instant Run是Google推出的第一代增量编译方案。不过在大型项目中，它带来的提速效果并不明显，甚至在某些场景下会让构建时间变得更长。

首先，在Gradle 4.6以前，如果项目中使用了注解处理器，那么每次代码修改都要进行全量编译。此外，若是修改的类中，包含有公有静态常量，那么也同样会导致本次修改需要进行全量编译。

Instant Run在使用过程中，有时也会遇到一些兼容性问题，但由于它是集成在Android Studio内部的，对于我们来