一、背景描述
在项目体量越来越大的情况下,编译速度也随着增长,有时候一个修改需要等待长达好几分钟的编译时间。
基于这种普遍的情况,推出了 RocketX
,通过在编译流程 动态 替换 module
为 aar
,提高全量编译的速度。让你体验到所有模块都是 aar 的速度,又能保留所有的 module 便于修改,简直完美!
二、效果展示
2.1、测试项目介绍
-
目标项目一共
3W+
个类与资源文件,全量编译4min
左右 -
通过
RocketX
全量增速之后的效果(每一个操作取 3 次平均值)
-
项目依赖关系如下图,
app
依赖bm
业务模块,bm
业务模块依赖顶层base/comm
模块
rx(RocketX)
编译 - 可以看到rx(RocketX)
在无论哪一个模块的编译速度基本都是在控制在 30s 左右,因为只编译app
和 改动的模块,其他模块是aar
包不参与编译。- 原生编译 - 当
base/comm
模块改动,底部的所有模块都必须参与编译。因为app/bmxxx
模块可能使用了base
模块中的接口或变量等,并且不知道是否有改动到。(那么速度就非常慢) - 原生编译和
RocketX
的编译差距就体现在这里,RocketX 少编了60+
个模块,从而实现提速:
三、思路问题分析与模块搭建:
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<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
可以获取
public interface Project extends Comparable<Project>, 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<String, String>()
map.put("name", aarName)
map.put("ext", "aar")
project.dependencies.add(configName, map)
}
4.2、localMave
优先使用 flatDir
实现通过指定一个缓存目录 getLocalMavenCacheDir
把生成 aar/jar
包丢进去,依赖修改时候通过 上面的 4.1 添加对应的 aar
即可:
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
可以接受,目前在类ChangeModuleUtils.kt
进行实现
4.4、 module 依赖关系获取
- 目的找到生成整个项目的依赖关系图时机,并在此处生成依赖图解析器。时机要在
run
编译的task
之前,确保依赖关系获取后替换能生效,而且要在全局module
依赖图已经生成之后(也就是在 执行完build.gradle
),那么有目前有两种方式:DependencyResolutionListener
和projectsEvaluated
,但是目前都有问题 。
- 通过监听
DependencyResolutionListener
,并在beforeResolve
回调方法处理:
public interface DependencyResolutionListener {
void beforeResolve(ResolvableDependencies var1);
void afterResolve(ResolvableDependencies var1);
}
project.gradle.addListener(DependencyResolutionListener listener)
- 但是出现的问题是
beforeResolve
会回调多次,并且执行完毕每一个module
的build.gradle
把依赖解析出来则会回调。那么如果在业务层处理一下,等待到最后一个module
回调完毕,再通过project.configurations
获取到所有module
的依赖图?答案是可以的,但是 时机已经晚了,等到最后一个module
解析完毕之后 回调beforeResolve
,再去修改依赖关系会报以下异常(无法修改依赖关系):
Cannot change dependencies of dependency configuration ':app:implementation' after it has been included in dependency resolution.
-
换个法子通过
project.gradle.projectsEvaluated {}
回调之后拿到所有module
依赖关系并且去修改。依赖图可以拿到,但是修改依赖关系还是会报异常,时机终究还是晚了。 -
那么过一遍
gradle
的生命周期(网上抠图)
- 发现执行完毕
build.gradle
(解析完依赖)之后的生命周期只有:Project.afterEvaluate
和Gradle.projectsEvaluated
(在3中试过不行)。那么只有afterEvaluate
,afterEvaluate
还是每 个module
执行完毕依赖会回调一次,监听最后一个module
回调的时机,并修改依旧还是报相同错误。综上在生命周期找不到合适的时机 - 直接找
gradle
源码 找到异常出现的代码,具体是在 :DefaultConfiguration.preventIllegalMutation
这个方法
private void preventIllegalParentMutation(MutationType type) {
if (type != MutationType.DEPENDENCY_ATTRIBUTES) {
if (this.resolvedState == InternalState.ARTIFACTS_RESOLVED) {
throw new InvalidUserDataException(String.format("Cannot change %s of parent of %s after it has been resolved", type, this.getDisplayName()));
} else if (this.resolvedState == InternalState.GRAPH_RESOLVED && type == MutationType.DEPENDENCIES) {
throw new InvalidUserDataException(String.format("Cannot change %s of parent of %s after task dependencies have been resolved", type, this.getDisplayName()));
}
}
}
- 出现这个异常的原因主要是
type
为MutationType.DEPENDENCY_ATTRIBUTES
,那么在哪里赋值为DEPENDENCY_ATTRIBUTES
,并赶在它之前修改依赖不就解决了,给出相关gradle
源码调用流程:
-
那么基本是通过
apply plugin: 'com.android.application'
开始调用进来并通过设置
project.gradle.projectsEvaluated{}
监听回调,把type
设置成DEPENDENCY_ATTRIBUTES ,通过这次排查源码知道 gradle 也是通过projectsEvaluated
这个生命周期才开始解决依赖关系(这时候所有的module
的依赖图才全部生成) -
那么最后的解决方法 要在
projectsEvaluated
去修改依赖,但是要赶在GradlePluginUtils
里面的一个监听者之前,通过反射剔除设置进去的所有projectsEvaluated
监听者(其实就是Action
的匿名内部对象),先执行rockectXPlugin
的监听者,后面再执行其他的监听者。大概是这样子:
//AppProjectDependencies.kt
init {
val projectsEvaluatedList = hookProjectsEvaluatedAction()
project.gradle.projectsEvaluated {
//先执行重依赖
resolveDenpendency()
//后执行移除的监听(主要调整执行顺序,重依赖才能生效和不报错,可能有AGP 版本兼容问题)
val clazz = Class.forName("org.gradle.api.invocation.Gradle")
val method = clazz.getDeclaredMethod("projectsEvaluated", Action::class.java)
val mMethodInvocation = MethodInvocation(method, arrayOf(it))
projectsEvaluatedList.forEach {
it.dispatch(mMethodInvocation)
}
}
}
//把所有 监听了 projectsEvaluated 的匿名内部类移除
fun hookProjectsEvaluatedAction(): List<BroadcastDispatch<BuildListener>> {
var removeDispatch = mutableListOf<BroadcastDispatch<BuildListener>>()
try {
var buildListenerBroadcast: ListenerBroadcast<BuildListener>? = null
val fBuildListenerBroadcast =
DefaultGradle::class.java.getDeclaredField("buildListenerBroadcast")
fBuildListenerBroadcast.isAccessible = true
buildListenerBroadcast =
fBuildListenerBroadcast.get(project.gradle) as? ListenerBroadcast<BuildListener>
val fBroadcast = ListenerBroadcast::class.java.getDeclaredField("broadcast")
fBroadcast.isAccessible = true
val broadcast: BroadcastDispatch<BuildListener>? =
fBroadcast.get(buildListenerBroadcast) as? BroadcastDispatch<BuildListener>
val fDispatchers = broadcast?.javaClass?.getDeclaredField("dispatchers")
fDispatchers?.isAccessible = true
val dispatchers: ArrayList<BroadcastDispatch<BuildListener>>? =
fDispatchers?.get(broadcast) as? ArrayList<BroadcastDispatch<BuildListener>>
val clazz =
Class.forName("org.gradle.internal.event.BroadcastDispatch\$ActionInvocationHandler")
val iterator = dispatchers?.iterator()
iterator?.let {
while (iterator.hasNext()) {
try {
val next = iterator.next()
val fDispatch = next.javaClass.getDeclaredField("dispatch")
fDispatch.isAccessible = true
val dispatch: Any? = fDispatch.get(next)
val fMethodName = clazz.getDeclaredField("methodName")
fMethodName.isAccessible = true
val methodName = fMethodName.get(dispatch) as? String
if (methodName?.contains("projectsEvaluated") == true) {
removeDispatch.add(next)
iterator.remove()
}
} catch (ignore: Exception) {
}
}
}
} catch (ignore: Exception) {
}
return removeDispatch
}
- 至此完美解决修改依赖时机问题,更多详情可查看 issue18
- 如何获取每个
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<String> {
//找到当前所有通过 artifacts.add("default", file('xxx.aar')) 依赖进来的 aar
var listArtifact = mutableListOf<DefaultPublishArtifact>()
var aarList = mutableListOf<String>()
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()
清理旧的缓存
解决:详情查看 issue,结果arouter
问题是解决了,代码也是合并了。但并没有发布新的插件版本到 mavenCentral
,于是先自行帮 arouter
解决一下。然而arouter
并没有启动 增量编译,导致 DexArchiveBuilderTask
运行巨慢,也就是打 dex
包很慢,项目中我重改了 arouter
插件源码支持 TransForm
增量速度提升一倍, 具体细节就下节和 dex
速度优化一起讲。
六、下一步展望
目前初步的版本已经能够在在项目 run
起来,但是还是有很多小问题不断的冒出并解决,路漫漫其修远兮,吾将上下而求索。。
下步计划:
dexBuild task
优化- 解决各种兼容性问题
目前插件趋于稳定,喜欢尝鲜的朋友可以通过github
教程接入,一起关注后期进展。后续 issue 的解决思路都会在本文不断更新,如果你喜欢本文就给我们 star 吧。
github开源地址