一、背景描述
在项目体量越来越大的情况下，编译速度也随着增长，有时候一个修改需要等待长达好几分钟的编译时间。 基于这种普遍的情况，推出了 RocketX ,通过在编译流程 动态 替换 module 为 aar ，提高全量编译的速度。
二、效果展示
2.1、测试项目介绍
- 目标项目一共
3W+个类与资源文件，全量编译4min左右（测试使用18 年 mbp 8代i7 16g） - 通过
RocketX全量增速之后的效果（每一个操作取 3 次平均值）
- 项目依赖关系如下图，
app依赖bm业务模块，bm业务模块依赖顶层base/comm模块
rx(RocketX)编译 - 可以看到rx(RocketX)在无论哪一个模块的编译速度基本都是在控制在 30s 左右，因为只编译app和 改动的模块，其他模块是aar包不参与编译。- 原生编译 - 当
base/comm模块改动，底部的所有模块都必须参与编译。因为app/bmxxx模块可能使用了base模块中的接口或变量等，并且不知道是否有改动到。（那么速度就非常慢） 原生编译 - 当
bmDiscover做了改动，只需要app模块和bmDiscover两个模块参与编译（速度较快）对于
rx(RocketX)编译顶层模块速度提升 300%+
三、思路问题分析与模块搭建:
3.1、思路问题分析
- 需要通过
gradle plugin的形式动态修改没有改动过的module依赖为 相对应的aar依赖，如果module改动，退化成project工程依赖，这样每次只有改动的module和app两个模块编译。 - 需要把
implement/api moduleB，修改为implement/api aarB，并且需要知道插件中如何加入aar依赖和剔除原有依赖 - 需要构建
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.1、如何手动添加 aar 依赖，分析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 {
private DirectDependencyAdder() {
}
public Dependency add(Configuration configuration, Object dependencyNotation, @Nullable Closure configureAction) {
return DefaultDependencyHandler.this.doAdd(configuration, dependencyNotation, configureAction);
}
}
- 最后是在
DefaultDependencyHandler.this.doAdd进行添加进去，而DefaultDependencyHandler在project可以获取
public interface Project extends Comparable, ExtensionAware, PluginAware {
...
DependencyHandler getDependencies();
...
}
- 而
doAdd方法三个参数通过debug源码发现，configuration就是"implementation", "api", "compileOnly"这三个字符串生成的对象，dependencyNotation是一个LinkHashMap有两个键值对，分别是name:aarName,ext:aar,最后一个configureAction传null就可以了，调用project.dependencies.add最终会调到doAdd方法，也就是说直接调用 add 即可。
public Dependency add(String configurationName, Object dependencyNotation) {
return this.add(configurationName, dependencyNotation, (Closure)null);
}
public Dependency add(String configurationName, Object dependencyNotation, Closure configureClosure) {
//这里直接调用到了 doAdd
return this.doAdd(this.configurationContainer.getByName(configurationName), dependencyNotation, configureClosure);
}
- 那么依葫芦画瓢添加
aar/jar的实现代码：configName是childProject中的configName，也就是"implementation", "api", "compileOnly"这三个字符串，原封不动拿过来：
fun addAarDependencyToProject(aarName: String, configName: String, project: Project) {
//添加 aar 依赖 以下代码等同于 api/implementation/xxx (name: 'libaccount-2.0.0', ext: 'aar'),源码使用 linkedMap
val map = linkedMapOf()
map.put("name", aarName)
map.put("ext", "aar")
project.dependencies.add(configName, map)
}
4.2、localMaven 优先使用 flatDir 实现通过指定一个缓存目录 getLocalMavenCacheDir 把生成 aar/jar 包丢进去,依赖修改时候通过 上面的 4.1 添加对应的 aar 即可：
fun flatDirs() {
val map = mutableMapOf()
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可以接受，目前在类ChangeModuleUtils.kt进行实现
4.4、 module 依赖关系获取
- 通过以下代码可以找到生成整个项目的依赖关系图时机，并在此处生成依赖图解析器。时机要在真正编译之前，确保依赖关系获取后替换能生效，而且要在全局
module依赖图已经生成之后，通过以下监听可以满足：
public interface DependencyResolutionListener {
void beforeResolve(ResolvableDependencies var1);
void afterResolve(ResolvableDependencies var1);
}
project.gradle.addListener(DependencyResolutionListener listener)
- 如何获取每个
module的依赖，依赖就藏在Configuration.dependencies，那么通过project.configurations.maybeCreate(configName)找到所有的Configuration对象，就能得到每个module的dependencies
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模块的接口不见了，会导致编译不过
- 给出整体项目替换的技术方案演示：
- 整体的实现在
DependenciesHelper.kt这个类中，由于讲起来篇幅太长，有兴趣可查阅开源库代码
4.5、hook 编译流程，完成后置换 loacal maven 中被修改的 aar
- 点击三角形
run，执行的命令是app:assembleDebug, 需要在assembleDebug后面补一个uploadLocalMavenTask, 通过finalizedBy把我们的task运行起来去同步修改后的aar：
val localMavenTask = childProject.tasks.maybeCreate("uploadLocalMaven"+buildType.capitalize(),LocalMavenTask::class.java)
localMavenTask.localMaven = this@AarFlatLocalMaven
bundleTask?.finalizedBy(localMavenTask)
4.6、提供 AS 状态栏 button，小火箭按钮一个喷火一个没有喷火，代表 enable/disable , 一个 扫把clean rockectx 的缓存，需要通过编写 intellij idea plugin 即可，也就是 目前拥有两个插件了，一个 gradle 插件一个 AS 插件:
五、一天一个小惊喜( bug 较多)
5.1、发现点击 run 按钮 ，执行的命令是 app:assembleDebug ，各个子 module 在 output 并没有打包出 aar
解决：通过研究 gradle 源码发现打包是由 bundle${Flavor}${BuildType}Aar 这个task执行出来，那么只需要将各个模块对应的 task 找到并注入到 app:assembleDebug 之后运行即可：
android.applicationVariants.forEach {
getAppAssembleTask(ASSEMBLE + it.flavorName.capitalize() + it.buildType.name.capitalize())?.let { task ->
hookBundleAarTask(task, it.buildType.name)
}
}
5.2、发现运行起来后存在多个 jar 包重复问题
解决： implementation fileTree(dir: "libs", include: ["*.jar"]) jar 依赖不能交到 parent module，jar 包会打进 aar 中的lib 可直接剔除。通过以下代码可以判断：
// 这里的依赖是以下两种： 无需添加在 parent ，因为 jar 包直接进入 自身的 aar 中的libs 文件夹
if (childDepency is DefaultSelfResolvingDependency && (childDepency.files is DefaultConfigurableFileCollection || childDepency.files is DefaultConfigurableFileTree)) {
// 这里的依赖是以下两种： 无需添加在 parent ，因为 jar 包直接进入 自身的 aar 中的libs 文件夹
// implementation rootProject.files("libs/tingyun-ea-agent-android-2.15.4.jar")
// implementation fileTree(dir: "libs", include: ["*.jar"])
} else {
parentProject.key.dependencies.add(childConfig.name, childDepency)
}
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
fun getAarByArtifacts(childProject: Project): MutableList {
//找到当前所有通过 artifacts.add("default", file('xxx.aar')) 依赖进来的 aar
var listArtifact = mutableListOf()
var aarList = mutableListOf()
childProject.configurations.maybeCreate("default").artifacts?.forEach {
if (it is DefaultPublishArtifact && "aar".equals(it.type)) {
listArtifact.add(it)
}
}
//拷贝一份到 localMaven
listArtifact.forEach {
it.file.copyTo(File(FileUtil.getLocalMavenCacheDir(), it.file.name), true)
//剔除后缀 （.aar）
aarList.add(removeExtension(it.file.name))
}
return aarList
}
5.5、发现 android module 打包出来可以是 jar
解决：通过找到名字叫做 jar 的task，并且在 jar task 后面注入 uploadLocalMaven task,代码实现在 JarFlatLocalMaven.kt
5.6、发现 arouter 有 bug，transform 没有通过 outputProvider.deleteAll() 清理旧的缓存
解决：结果arouter 问题是解决了，代码也是合并了。但并没有发布新的插件版本到 mavenCentral，于是先自行帮 arouter 解决一下。然而arouter 并没有启动 增量编译，导致 DexArchiveBuilderTask 运行巨慢，也就是打 dex 包很慢，项目中我重改了 arouter 插件源码支持 TransForm 增量速度提升一倍, 具体细节就下节和 dex 速度优化一起讲。
六、下一步展望
目前初步的版本已经能够在在项目 run 起来，但是还是有很多小问题不断的冒出并解决，路漫漫其修远兮，吾将上下而求索。。
下步计划：
dexBuild task优化- 解决各种兼容性问题
相关教程
Android基础系列教程：
Android基础课程UI-布局_哔哩哔哩_bilibili
Android基础课程UI-控件_哔哩哔哩_bilibili
Android基础课程UI-动画_哔哩哔哩_bilibili
Android基础课程-activity的使用_哔哩哔哩_bilibili
Android基础课程-Fragment使用方法_哔哩哔哩_bilibili
Android基础课程-热修复/热更新技术原理_哔哩哔哩_bilibili
本文转自 https://juejin.cn/post/7038157787976695815，如有侵权，请联系删除。