QQ音乐Android端120万行代码，编译耗时是怎样优化的，Android开发面试问题

工程编译，是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体系的，迁移的话就