怎么做编译优化，过后说了个计划，就是编译时将所有的模块依赖批改为 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/AR…

</article>
关注我，每天分享常识干货！