怎么做编译优化,过后说了个计划,就是编译时将所有的模块依赖批改为 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>
关注我,每天分享常识干货!