怎么做编译优化，当时说了个方案，就是编译时将所有的模块依赖修改为 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 F l a v o r {Flavor} 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
关注我，每天分享知识干货！