Android 编译速度提升黑科技 - RocketX

Android社区 收藏文章

记得之前有同学在留言区问过我怎么做编译优化,我当时说了个方案,就是编译时将所有的模块依赖修改为 aar,然后每次编译将变动的模块改成源码依赖,同时编译完成再将修改模块上传为 aar,这样可以始终做到仅有最少的模块参与源码编译,从而提升编译速度。

当然说起来轻松,做起来没有那么容易,终于有位小伙伴将上述描述开发成一个开源方案了,非常值得大家学习和借鉴。

1背景描述

在项目体量越来越大的情况下,编译速度也随着增长,有时候一个修改需要等待长达好几分钟的编译时间。

基于这种普遍的情况,推出了 RocketX ,通过在编译流程动态修改项目依赖关系, 动态 替换 module 为 aar,做到只编译改动模块,其他模块不参与编译,无需改动原有项目任何代码,提高全量编译的速度。

2效果展示

2.1、测试项目介绍

目标项目一共 3W+ 个类与资源文件,全量编译 4min 左右(测试使用 18 年 mbp 8代i7 16g)。

通过 RocketX 全量增速之后的效果(每一个操作取 3 次平均值)。

项目依赖关系如下图,app 依赖 bm 业务模块,bm 业务模块依赖顶层 base/comm 模块。

依赖关系

• 当 base/comm 模块改动,底部的所有模块都必须参与编译。因为 app/bmxxx 模块可能使用了 base 模块中的接口或变量等,并且不知道是否有改动到。(那么速度就非常慢)

• 当 bmDiscover 做了改动,只需要 app 模块和 bmDiscover 两个模块参与编译。(速度较快)

• rx(RocketX) 在无论哪一个模块的编译速度基本都是在控制在 30s 左右,因为只编译 app 和 改动的模块,其他模块是 aar 包不参与编译。

顶层模块速度提升 300%+

3思路问题分析与模块搭建

3.1、思路问题分析

需要通过 gradle plugin 的形式动态修改没有改动过的 module 依赖为 相对应的 aar 依赖,如果 module 改动,退化成 project 工程依赖,这样每次只有改动的 module 和 app 两个模块编译。

需要把 implement/api moduleB,修改为implement/api aarB。

需要构建 local maven 存储未被修改的 module 对应的 aar。(也可以通过 flatDir 代替速度更快)

编译流程启动,需要找到哪一个 module 做了修改。

需要遍历每一个 module 的依赖关系进行置换, module 依赖怎么获取?一次性能获取到所有模块依赖,还是分模块各自回调?修改其中一个模块依赖关系会阻断后面模块依赖回调?

每一个 module 换变成 aar 之后,自身依赖的 child 依赖 (网络依赖,aar),给到 parent module (如何找到所有 parent module) ? 还是直接给 app module ? 有没有 app 到 module 依赖断掉的风险?这里需要出一个技术方案。

需要hook 编译流程,完成后置换 loacal maven 中被修改的 aar。

提供 AS 状态栏 button, 实现开启关闭功能,加速编译还是让开发者使用已经习惯性的三角形 run 按钮。

3.2、模块搭建

依照上面的分析,虽然问题很多,但是大致可以把整个项目分成以下几块:

4问题解决与实现

4.1、implement 源码实现入口在 DynamicAddDependencyMethods 中的 tryInvokeMethod 方法。他是一个动态语言的 methodMissing 功能。

tryInvokeMethod 代码分析:

 public DynamicInvokeResult tryInvokeMethod(String name, Object... arguments) {
       //省略部分代码 ...
       return DynamicInvokeResult.found(this.dependencyAdder.add(configuration, normalizedArgs.get(0), (Closure)null));
 }

dependencyAdder 实现是一个 DirectDependencyAdder。

private class DirectDependencyAdder implements DependencyAdder<Dependency> {
    private DirectDependencyAdder() {
    }
    public Dependency add(Configuration configuration, Object dependencyNotation, @Nullable Closure configureAction) {
        return DefaultDependencyHandler.this.doAdd(configuration, dependencyNotation, configureAction);
    }
}

最后是在 DefaultDependencyHandler.this.doAdd 进行添加进去,而 DefaultDependencyHandler 在 project可以获取。

  DependencyHandler getDependencies(); 

通过以上的分析,添加相对应的 aar/jar 可以通过以下代码实现。

fun addAarDependencyToProject(aarName: String, configName: String, project: Project) {
    //添加 aar 依赖 以下代码等同于 api/implementation/xxx (name: 'libaccount-2.0.0', ext: 'aar'),源码使用 linkedMap
    if (!File(FileUtil.getLocalMavenCacheDir() + aarName + ".aar").exists()) return
    val map = linkedMapOf<String, String>()
    map.put("name", aarName)
    map.put("ext", "aar")
    // TODO: 2021/11/5 改变依赖 这里后面需要修改成
    //project.dependencies.add(configName, "com.${project.name}:${project.name}:1.0")
    project.dependencies.add(configName, map)
}
4.2、localMave 优先使用 flatDir 实现通过指定一个缓存目录把生成 aar/jar 包丢进去,依赖修改时候通过找寻进行替换。
fun flatDirs() {
    val map = mutableMapOf<String, File>()
    map.put("dirs", File(getLocalMavenCacheDir()))
    appProject.rootProject.allprojects {
        it.repositories.flatDir(map)
    }
}
4.3、编译流程启动,需要找到哪一个 module做了修改。

使用遍历整个项目的文件的 lastModifyTime 去做实现。

以每一个 module 为一个粒度,递归遍历当前 module 的文件,把每个文件的 lastModifyTime 整合计算得出一个唯一标识 countTime。

通过 countTime 与上一次的作对比,相同说明没改动,不同则改动. 并需要同步计算后的 countTime 到本地缓存中。

整体 3W 个文件耗时 1.2s 可以接受。

4.4、 module 依赖关系获取。

通过以下代码可以找到生成整个项目的依赖关系图时机,并在此处生成依赖图解析器。

 project.gradle.addListener(DependencyResolutionListener listener)
4.5、 module 依赖关系 project 替换成 aar 技术方案

每一个 module 依赖关系替换的遍历顺序是无序的,所以技术方案需要支持无序的替换。

目前使用的方案是:如果当前模块 A 未改动,需要把 A 通过 localMaven 置换成 A.aar,并把 A.aar 以及 A 的 child 依赖,给到第一层的 parent module 即可。(可能会质疑如果 parent module 也是 aar 怎么办,其实这块也是没有问题的,这里就不展开说了,篇幅太长)

为什么要给到 parent 不能直接给到 app ,下图一个简单的示例如果 B.aar 不给 A 模块的话,A 使用 B 模块的接口不见了,会导致编译不过。

给出整体项目替换的技术方案演示:

4.5、hook 编译流程,完成后置换 loacal maven 中被修改的 aar。

点击三角形 run,执行的命令是 app:assembleDebug , 需要在 assembleDebug 后面补一个 uploadLocalMavenTask, 通过 finalizedBy 把我们的 task 运行起来去同步修改后的 aar

4.6、提供 AS 状态栏 button,小火箭按钮一个喷火一个没有喷火,代表 enable/disable , 一个 扫把clean rockectx 的缓存。

5一天一个小惊喜

5.1、发现点击 run 按钮 ,执行的命令是 app:assembleDebug ,各个子 module 在 output 并没有打包出 aar。

解决:通过研究 gradle 源码发现打包是由 bundle${Flavor}${BuildType}Aar 这个task执行出来,那么只需要将各个模块对应的 task 找到并注入到 app:assembleDebug 之后运行即可。

5.2、发现运行起来后存在多个 jar 包重复问题。

解决:implementation fileTree(dir: "libs", include: ["*.jar"]) jar 依赖不能交到 parent module,jar 包会打进 aar 中的lib 可直接剔除。通过以下代码可以判断:

// 这里的依赖是以下两种: 无需添加在 parent ,因为 jar 包直接进入 自身的 aar 中的libs 文件夹
//    implementation rootProject.files("libs/xxx.jar")
//    implementation fileTree(dir: "libs", include: ["*.jar"])
childDepency.files is DefaultConfigurableFileCollection || childDepency.files is DefaultConfigurableFileTree
5.3、发现 aar/jar 存在多种依赖方式。

implementation (name: 'libXXX', ext: 'aar')

implementation files("libXXX.aar")

解决:使用第一种,第二种会合并进aar,导致类重复问题.

5.4、发现 aar 新姿势依赖。
configurations.maybeCreate("default")
artifacts.add("default", file('lib-xx.aar'))

上面代码把 aar 做了一个单独的 module 给到其他 module 依赖,default config 其实是 module 最终输出 aar 的持有者,default config 可以持有一个 列表的aar ,所以把 aar 手动添加到 default config,也相当于当前 module 打包出来的产物。

解决:通过 childProject.configurations.maybeCreate("default").artifacts 找到所有添加进来的 aar ,单独发布 localmaven。

5.5、发现 android module 打包出来可以是 jar。

解决:通过找到名字叫做 jar 的task,并且在 jar task 后面注入 uploadLocalMaven task。

5.6、发现 arouter 有 bug,transform 没有通过 outputProvider.deleteAll() 清理旧的缓存。

解决:详情查看 issue,结果arouter 问题是解决了,代码也是合并了。但并没有发布新的插件版本到 mavenCentral,于是先自行帮 arouter 解决一下。

https://github.com/alibaba/ARouter/issues/964

6下一步展望

目前初步的版本已经能够在在项目 run 起来,但是还是有很多小问题不断的冒出并解决,路漫漫其修远兮,吾将上下而求索。

下步计划:

1. dexBuild task 优化。

2. 解决各种兼容性问题。

目前插件 上传maven还在流程中,喜欢尝鲜的朋友可以通过本地接入,一起关注后期进展。

相关标签

扫一扫

在手机上阅读