背景

今日头条项目进行了多次组件化和模块化的重构，分拆出了 200 多个子模块，这些子模块如果全都 include 进项目，那么在 clean build 的时候，所有子模块的代码需要重新编译，而对于大多数开发人员来说，基本上只关心自己负责的少数几个模块，根本不需要改动其他模块的代码，这些其他 project 的配置和编译时间就成为了不必要的代价。

优化方案

对于以上子模块过多的解决方案是：将所有模块发布成 aar ，在项目中全部默认通过 maven 依赖这些编译好的组件，而在需要修改某个模块时，通过配置项将该模块的依赖形式改为源码依赖，做到在编译时只编译改动的模块。但是这样做会导致模块渐渐的又全部变为源码依赖的形式，除非规定每次修改完对应模块后，开发人员自己手动将模块发布成 aar ，并改回依赖形式。这种严重依赖开发人员自觉，并且在模块数量多依赖关系复杂的时候会显得异常繁琐，因此为了开发阶段的便利，设计了一整套更完整细致的方案:

1. 开发时，从主分支拉取的代码一定是全 aar 依赖的，除了 app 模块没有任何子模块是源码引入。

2. 需要修改对应模块时，通过修改 local.properties 里的 INCLUDES 参数指定源码引入的模块。

3. 开发完成后，push 代码至远端，触发代码合并流程后，在 ci 预编译过程与合码目标分支对比，检测修改的模块，将这些模块按照依赖关系依次发布成 aar ，并在工程中修改依赖为新版本的 aar, 这一步保证了每次代码合入完成后，主分支上的依赖都是全 aar 依赖的。

收益

通过上述改造，将源码模块切换成 aar 依赖后，clean build 耗时从 7，8 分钟降低至 4，5 分钟，收益接近 50%，效果显著。

增量 java/kotlin 编译

背景

在非 clean build 的情况下，更改 java/kotlin 代码虽然会做增量编译，但是为了绝对的正确性，gradle 会根据一些列依赖关系计算，选择需要重新编译的代码，这个计算粒度比较粗，稍微改动一个类的代码，就可能导致大量代码重新执行 apt, 编译等流程。

由于 gradle 作为通用框架，其设计的基本原则是绝对的正确，因此很容易导致增量编译失效，在实际开发中，为了快速编译展示结果，可以在编译正确性和编译速度上做一个折中的方案：

1. 禁用原始的 javac/kotlinCompile 等 task, 自行实现代码增量修改判断，只编译修改的代码。

2. 动态禁用 kapt 相关的 task, 降低 kapt,kaptGenerateStub 等 task 的耗时。

以上方案（下文全部简称为 fastbuild) 虽然在涉及常量修改，方法签名变更方面 存在一定的问题（常量内联等），但是能换来增量编译从 2 分多降低至 20~30s，极大的提升编译效率，且有问题的场景并不常见，因此整体上该方案是利大于弊的。

编译耗时恶化

通过上文介绍的几个优化方案和其他优化方式，在 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 的所有依赖，可以得到 kapt 依赖库的 jar 包，利用 asm 获取所有 annotation.

2. 遍历所有 subproject 的 sourceset 下所有 .java，.kt 源文件，解析 import 信息，看是否有步骤 1 中解析的 annotation

3. package task 完成后遍历 所有 subproject 所有 generate/apt ,generate/kapt 目录下生成的 java 文件

使用上述方案，通过全源码打包最终扫描出来大概是 70+模块不会进行任何 kapt 的实际输出，且将这些不会进行输出的 kapt，kaptGenerateStub 的 task 耗时累加起来较高 217s （由于 task 并发执行所以实际总时长可能要少一些).

获取到不实际生成 kapt 内容的模块后，开始对这些模块进行细粒度的拆分，让它们从 apply library.gradle 改为没有 kapt 相关的 library-api.gradle ，该文件除了禁用 kapt 外，与 library 逻辑一致。

但是这样做算是在背后偷偷做了些更改，很可能后续新来的同学不知道有这种优化手段，可能新增了注解后却没有任何输出且找不到原因，而优化效果最好是尽量少给业务同学带来困扰。为了避免这种情况，便对这些 library-api 模块依赖的注解做隔离优化，即：把这些模块依赖的注解库全部 自动 exclude 掉，在尝试使用注解时会因获取不到引用（如下图所示），第一时间发现到依赖被移除的问题。

另一方面在编译出现错误时，对应 gradle 插件会自动解析找不到的符号，如果发现该符号是被隔离优化的注解，会提示将 library-api 替换成 library，尽可能降低优化方案对业务的负面影响。

收益

1. mac 全源码场景中有 58s 左右的加速收益。

2. ci 机器上由于 cpu 核数更多 ，task 并发性能更好，只有 10s 左右的收益。

transform 优化

背景

transform 作为 Android gradle plugin 提供给开发者的 API，用于在 apk 构建过程中，对 class 字节码，resources 等文件内容进行插桩修改，例如官方的 dex, proguard 等功能均由此 api 实现。

对于今日头条这种大型工程来说，有很多诸如性能插桩、自动埋点插桩等相关需求，因此基于此 api 开发了大量 transform，用于实现特定功能，但是这些 transform 基本上都是不支持增量编译的，即使只改动了一行代码，这 些 transform 都会遍历所有 class 文件，解析字节码中的方法字段信息，关键是这类 transform 数量有十几个，将这些遍历耗时乘以 10 累加之后，增量编译耗时自然居高不下。

根据分析，其中性能插桩等相关 transform 做的一些面向线上的插桩方案是完全可以只在 release 打包时打开的，因此可以直接在 debug 编译时禁用这些功能，用于提升开发期间的编译速度。而剩下的 9 个 transform 特征比较相似，可能在一些插桩细节上有所不同，它们大致的处理逻辑为：

1. 在各个模块中使用 apt processor 收集模块 xx 注解的 class 信息然后生成一个 xxCollect 类，该类的作用是收集好 apt 阶段解析到的本模块的类信息

2. 将所有模块收集到的信息进行汇总，利用 transform 阶段扫描出所有的 xxCollect 信息，通过 javaassit 或者 asm 往一个 xxCollectMgr 的某个 collectXxx 方法插桩注入之前收到的信息

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

3. 业务代码可通过 xxCollectMgr 的 collectXxx 方法获取到在各个模块动态生成的所有 xxCollect 信息。（例: 页面路由相关框架便是通过该逻辑收集到所有子模块的路由注册信息)

由于这 9 个自定义 transform 的功能如此类似，便决定将这些 transform 合并成一个，这样同一个文件的读写操作只执行一次，并且可以做定制化的增量编译优化。虽然公司内有类似的 transform 合并优化方案 byteX ( 已在 github 开源），但是由于今日头条项目在 debug 阶段未开启该功能，且 ByteX 做了一些诸如 ClassGrapth 的构建，对类文件做两次遍历等操作，对于实现类信息收集和信息注入 这个功能来说，byteX 显得比较重 ，于是仍然针对类信息收集注入功能这个细分场景开发了一个收敛框架。

收益

该框架完成了内部 9 种类信息收集注入相关框架的收敛，编译耗时的绝对值加速了 25s 左右，且由于提供了统一的增量缓存功能，使得改动一行代码的耗时可以从 2 分 30s 降低到 35~40s ，实现了增量编译速度大的飞跃。最关键的是将所有自定义 transform 统一管控后，后续可以做统一定制化的需求，进一步优化编译速度。

dexBuilder 优化

背景

在 Android debug 编译 过程中，最主要的耗时在 transform 上，而上文 介绍 今日头条项目自定义 transform 已经被高度优化过，剩下的 dexBuilder(将 class 转换成 dex ) ，dexMerge 等 task 耗时就成为了性能瓶颈，dexBuilder 全量编译耗时 60s 左右，增量编译耗时 22s 左右。

根据 DexArchiveBuilderTransform 关键方法 launchProcessing 里面关键一行 isDirectoryBased，如果是目录类型的输入，会根据具体变动 class 文件做增量的 dex 编译 ，但是如果是 jar 输入类型，那只要 jar 里任何一个类变动，则整个 jar 所有类都需要重执行 dex，但是由于 gradle 的依赖特性，基本上只有 app 模块是目录类的输入，其他 library 都是 jar 输入类型，对于比较大的业务模块 ，如果该模块有几千个类，那每改动一次类，就会有几千类连带重新 执行 dex 编译。

dexBuilder 增量效果量化

在优化前为了得到真正的重新执行 dex 编译的数值，做到最佳优化，设计了一套 hook dex 编译流程的方法(该方法理论上可以 hook Android gradle plugin 任意类：大致就是 hook classLoader ，提前用 asm 修改 D8DexArchiveBuilder 中的 convert 方法

通过对 D8DexArchiveBuilder 的 hook ，统计到优化前改动一行代码会连带着 24968 个类重新执行 dex 编译，增量效果非常差。

优化方案

既然 jar 输入相比于 目录输入来说增量编译效果非常差，那么可以想到 hook TransformInvocation 中的 input 方法，动态将 project 的 jar 类型输入（JarInput）映射为一个 目录输入（DirectoryInput），那么子模块修改对应代码时，只重新编译目录中被修改的 class 为 dex（而不是原来的整个 jar 内所有 class 重新执行 dex 编译），整体 dex 重新编译的数量将大幅度减少。实现具体方案如下：

• 自动发现源码依赖的子模块 project，配置经常需要变更的注入类所在的 SDK jar

• hook TransformInvocation 的 input 将上面步骤中的 JarInput 映射为 DirectoryInput

• 每次 hook input 前检查与上一次需要优化的 project，sdk 是否一致，否则直接抛异常（影响增量判断）

而 jar 转 目录的映射细节为:

• 如果是新增的 jar， 那解压该 jar 所有类文件到目录，将该目录下所有类定义为 ADD

• 如果是移除的 jar， 检查之前解压的目录，该目录下所有类文件定义为 REMOVE

• 如果 jar 没有变更，那定义为之前解压的目录中没有任何子文件变更 NOT_CHANGE

• 如果 jar 有修改，需要进一步判断内容有哪些修改，如果 jar 中有的文件在 解压目录不存在，该文件定义为 ADD，如果目录有的文件在 jar 中不存在，该文件定义为 REMOVE，如果都同时存在，比较文件内容（大小，hash) ，相同定义为 NOT_CHANGED 否则为 CHANGED

在第一次增量修改完成后，重新执行 dex 编译的类数量降低至 2152 个，但是其中仍然有很多迷惑的不该执行 dex 编译的类，预期是修改多少类，就重新执行 多少次 dex，因此继续对其中原因进行进一步的探索

desugarGraph 异常

由于 java8 的字节码有些指令在 Android 虚拟机中并不能得到支持，会在编译流程中，将这些指令进行脱糖，转换成已有的指令，而 d8 中 desugar 的流程合并到了 dexBuilder 中，为了避免某些类 desugar 后，依赖它的类的行为正确，需要把依赖它的所有类重新执行一遍 dex 编译。

而 d8 会根据 DesugaringGraph 查找 desguar 有变动的类及其依赖的 jar 包，如图下面获得到的 addtionalPaths 是 desguar 类可能直接间接相关的 jar 包，即使这些 jar 包没有任何文件内容变更，其中所有类也得重新全部执行一次 dex 编译。

DesugaringGraph 逻辑概述

该类用来辅助获取依赖或间接依赖到变更文件的所有文件，而它的生成逻辑为: 全量或增量编译类的时候记录类型之间的依赖和被依赖关系，依赖关系的判断条件有

1. 父类

2. 直接实现的接口

3. 调用 dynamic 方法指令时的返回类型

DesugaringGraph 不仅记录了类依赖的类，和依赖它的类，同时也记录了一个文件路径包含了哪些类