专科毕业的我会这个今日头条也能进——-Android-‘秒‘-级编译速度优化

通过上文介绍的几个优化方案和其他优化方式，在 18 年时，今日头条 Android 项目的整体编译速度（clean build 4~5min, fast 增量编译 20~30s）在同量级的大型工程中来说是比较快的 ，然而后期随着业务发展的需求，编译脚本添加了很多新的逻辑：

1. kotlin 大规模使用，kapt 新增了很多注解处理逻辑。
2. 引入对 java8 语法的支持 ， java8 语法的 desugar(脱糖）操作增加了编译耗时。
3. 大量的字节码插桩需求，添加了许多 transform ，大幅度提升了增量编译耗时。

这些逻辑的引入，使得增量编译耗时恶化到 2 分 30s，即使采用 fastbuild，改动一行代码编译也需要 1 分 30s 之多，开发体验非常差。而下文将着重描述最近一段时间对上述问题的优化过程。

近期优化方案

app 壳模块 kapt 优化

背景

今日头条工程经过多次模块化，组件化重构后， app 模块(NewsArticle)的大部分代码都已经迁移到子模块（上文已经介绍过子模块可以采用 aar 化用于编译速度优化，app 模块只剩下一个壳而已。

但是从 build profile 数据（执行 gradle 命令时添加 --profile 参数会在编译完成后输出相关 task 耗时的统计文件） 中发现到一个异常 case：明明只有 2 个类的 app 模块 kapt(annotationProcessor 注解处理) 相关耗时近 1 分钟。

通过进一步观察，虽然 app 模块拆分后只有 2 个简单类的代码，但是却用了 6 种 kapt 库， 且实际生效的只是其中 ServiceImpl 一个注解 （内部 ServiceManager 框架，用于指示生产 Proxy 类，对模块之间代码调用进行解耦）。如此一顿操作猛如虎，每次编译却只生成固定的两个 Proxy 类，与 53s 的高耗时相比，投入产出比极低。

优化方案

把固定生成的 Proxy 类从 generate 目录移动到 src 目录，然后禁止 app 模块中 kapt 相关 task ，并添加相关管控方案（如下图: 检测到不合理情况后立刻抛出异常），防止其他人添加新增的 kapt 库。

收益

1. 在 mac clean build 中平均有 40s 收益
2. 在 ci clean build 中平均有 20s 收益

kapt 隔离优化

背景

通过上文介绍在 app 模块发现的异常的 kapt case， 进而发现在工程中为了方便，定义了一个 library.gradle ，该文件的作用是定义项目中通用的 Android dsl 配置和共有的基础依赖，因此项目中所有子模块均 apply 了这个文件，但是这个文件陆陆续续的被不同的业务添加新的 kapt 注解处理库，在全源码编译时，所有子模块都得执行 library 模块中定义的全部 6 个 kapt ，即使该模块没有任何注解相关的处理也不例外。

而上述情况的问题在于：相比纯 java 模块的注解处理，kotlin 代码需要先通过 kaptGenerateStub 将 kt 文件转换成为 java ，让 apt 处理程序能够统一的面向 java 做注解扫描和处理。但是上面讲到其实有很多模块是根本不会有任何实际 kapt 处理过程的，却白白的做了一次 kt 转 java 的操作，源码引入的模块越多，这种无意义的耗时累加起来也非常可观。

为了能够弄清楚到底有哪些子模块真正用到了 kapt ，哪些没用到可以禁用掉 kapt 相关 task ，对项目中所有子模块进行了一遍扫描：

1. 获取 kapt configuration 的所