今日头条 Android ‘秒‘ 级编译速度优化

2401_84122902

于 2024-05-02 00:27:27 发布

阅读量1k

点赞数 9

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/2401_84122902/article/details/138383524

版权

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

获取 kapt configuration 的所有依赖，可以得到 kapt 依赖库的 jar 包，利用 asm 获取所有 annotation.
遍历所有 subproject 的 sourceset 下所有 .java，.kt 源文件，解析 import 信息，看是否有步骤 1 中解析的 annotation
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，尽可能降低优化方案对业务的负面影响。

收益

mac 全源码场景中有 58s 左右的加速收益。
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 特征比较相似，可能在一些插桩细节上有所不同，它们大致的处理逻辑为：

在各个模块中使用 apt processor 收集模块 xx 注解的 class 信息然后生成一个 xxCollect 类，该类的作用是收集好 apt 阶段解析到的本模块的类信息
将所有模块收集到的信息进行汇总，利用 transform 阶段扫描出所有的 xxCollect 信息，通过 javaassit 或者 asm 往一个 xxCollectMgr 的某个 collectXxx 方法插桩注入之前收到的信息
业务代码可通过 xxCollectMgr 的 collectXxx 方法获取到在各个模块动态生成的所有 xxCollect 信息。（例: 页面路由相关框架便是通过该逻辑收集到所有子模块的路由注册信息)

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