一、背景描述
在項目體量越來越大的情況下伐谈，編譯速度也隨著增長烂完，有時候一個修改需要等待長達好幾分鐘的編譯時間。
基于這種普遍的情況诵棵，推出了 RocketX ,通過在編譯流程 動態(tài) 替換 module 為 aar 抠蚣，提高全量編譯的速度。讓你體驗到所有模塊都是 aar 的速度履澳，又能保留所有的 module 便于修改嘶窄，簡直完美！
二距贷、效果展示
2.1柄冲、測試項目介紹
目標項目一共
3W+個類與資源文件，全量編譯4min左右-
通過
RocketX全量增速之后的效果（每一個操作取 3 次平均值）
build-speed.png 項目依賴關(guān)系如下圖忠蝗，
app依賴bm業(yè)務(wù)模塊现横，bm業(yè)務(wù)模塊依賴頂層base/comm模塊
架構(gòu)圖.png
-
rx(RocketX)編譯 - 可以看到rx(RocketX)在無論哪一個模塊的編譯速度基本都是在控制在 30s 左右，因為只編譯app和 改動的模塊阁最，其他模塊是aar包不參與編譯戒祠。 - 原生編譯 - 當
base/comm模塊改動，底部的所有模塊都必須參與編譯速种。因為app/bmxxx模塊可能使用了base模塊中的接口或變量等姜盈，并且不知道是否有改動到。（那么速度就非常慢） - 原生編譯和
RocketX的編譯差距就體現(xiàn)在這里配阵，RocketX 少編了60+個模塊馏颂，從而實現(xiàn)提速：
1641484922(1).png
三示血、思路問題分析與模塊搭建:
3.1、思路問題分析
-
上個思維導(dǎo)圖饱亮，涉及到以下問題：
未命名文件 (3).jpg
- 需要通過
gradle plugin的形式動態(tài)修改沒有改動過的module依賴為 相對應(yīng)的aar依賴矾芙，如果module改動，退化成project工程依賴近上，這樣每次只有改動的module和app兩個模塊編譯剔宪。 - 需要把
implement/api moduleB，修改為implement/api aarB壹无，并且需要知道插件中如何加入aar依賴和剔除原有依賴 - 需要構(gòu)建
local maven存儲未被修改的module對應(yīng)的aar（也可以通過flatDir代替速度更快） - 編譯流程啟動葱绒，需要找到哪一個
module做了修改 - 需要遍歷每一個
module的依賴關(guān)系進行置換，module依賴怎么獲榷范А地淀？一次性能獲取到所有模塊依賴，還是分模塊各自回調(diào)岖是？修改其中一個模塊依賴關(guān)系會阻斷后面模塊依賴回調(diào)帮毁？ - 每一個
module換變成aar之后，自身依賴的child依賴 （網(wǎng)絡(luò)依賴豺撑，aar）,給到parent module(如何找到所有parent module) ? 還是直接給app module? 有沒有app到module依賴斷掉的風(fēng)險烈疚？ 這里需要出一個技術(shù)方案。 - 需要
hook編譯流程聪轿，完成后置換loacal maven中被修改的aar - 提供
AS狀態(tài)欄button, 實現(xiàn)開啟關(guān)閉功能爷肝，加速編譯還是讓開發(fā)者使用已經(jīng)習(xí)慣性的三角形run按鈕
3.2、模塊搭建
- 依照上面的分析陆错，雖然問題很多灯抛，但是大致可以把整個項目分成以下幾塊：
image.png
四、問題解決與實現(xiàn):
4.1音瓷、如何手動添加 aar 依賴对嚼，分析implement 源碼實現(xiàn)入口在 DynamicAddDependencyMethods 中的 tryInvokeMethod 方法。他是一個動態(tài)語言的 methodMissing 功能
-
tryInvokeMethod代碼分析
public DynamicInvokeResult tryInvokeMethod(String name, Object... arguments) {
//省略部分代碼 ...
return DynamicInvokeResult.found(this.dependencyAdder.add(configuration, normalizedArgs.get(0), (Closure)null));
}
-
dependencyAdder實現(xiàn)是一個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方法三個參數(shù)通過debug源碼發(fā)現(xiàn)纵竖，configuration就是"implementation", "api", "compileOnly"這三個字符串生成的對象，dependencyNotation是一個LinkHashMap有兩個鍵值對偷线，分別是name:aarName,ext:aar,最后一個configureAction傳null就可以了，調(diào)用project.dependencies.add最終會調(diào)到doAdd方法沽甥，也就是說直接調(diào)用 add 即可声邦。
public Dependency add(String configurationName, Object dependencyNotation) {
return this.add(configurationName, dependencyNotation, (Closure)null);
}
public Dependency add(String configurationName, Object dependencyNotation, Closure configureClosure) {
//這里直接調(diào)用到了 doAdd
return this.doAdd(this.configurationContainer.getByName(configurationName), dependencyNotation, configureClosure);
}
- 那么依葫蘆畫瓢添加
aar/jar的實現(xiàn)代碼：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 優(yōu)先使用 flatDir 實現(xiàn)通過指定一個緩存目錄 getLocalMavenCacheDir 把生成 aar/jar 包丟進去,依賴修改時候通過 上面的 4.1 添加對應(yīng)的 aar 即可：
fun flatDirs() {
val map = mutableMapOf<String, File>()
map.put("dirs", File(getLocalMavenCacheDir()))
appProject.rootProject.allprojects {
it.repositories.flatDir(map)
}
}
4.3邓了、編譯流程啟動，需要找到哪一個 module做了修改
- 使用遍歷整個項目的文件的
lastModifyTime去做實現(xiàn) - 已每一個
module為一個粒度媳瞪，遞歸遍歷當前module的文件骗炉，把每個文件的lastModifyTime整合計算得出一個唯一標識countTime - 通過
countTime與上一次的作對比,相同說明沒改動,不同則改動. 并需要同步計算后的countTime到本地緩存中 - 整體
3W個文件耗時1.2s可以接受，目前在類ChangeModuleUtils.kt進行實現(xiàn)
4.4蛇受、 module 依賴關(guān)系獲取
- 目的找到生成整個項目的依賴關(guān)系圖時機句葵，并在此處生成依賴圖解析器。時機要在
run編譯的task之前兢仰，確保依賴關(guān)系獲取后替換能生效乍丈，而且要在全局module依賴圖已經(jīng)生成之后（也就是在 執(zhí)行完build.gradle），那么有目前有兩種方式：DependencyResolutionListener和projectsEvaluated把将，但是目前都有問題 轻专。
- 通過監(jiān)聽
DependencyResolutionListener，并在beforeResolve回調(diào)方法處理：
public interface DependencyResolutionListener {
void beforeResolve(ResolvableDependencies var1);
void afterResolve(ResolvableDependencies var1);
}
project.gradle.addListener(DependencyResolutionListener listener)
- 但是出現(xiàn)的問題是
beforeResolve會回調(diào)多次察蹲，并且執(zhí)行完畢每一個module的build.gradle把依賴解析出來則會回調(diào)请垛。那么如果在業(yè)務(wù)層處理一下，等待到最后一個module回調(diào)完畢洽议，再通過project.configurations獲取到所有module的依賴圖宗收？答案是可以的，但是 時機已經(jīng)晚了绞铃，等到最后一個module解析完畢之后 回調(diào)beforeResolve镜雨，再去修改依賴關(guān)系會報以下異常（無法修改依賴關(guān)系）：
Cannot change dependencies of dependency configuration ':app:implementation' after it has been included in dependency resolution.
換個法子通過
project.gradle.projectsEvaluated {}回調(diào)之后拿到所有module依賴關(guān)系并且去修改。依賴圖可以拿到儿捧，但是修改依賴關(guān)系還是會報異常荚坞，時機終究還是晚了。那么過一遍
gradle的生命周期（網(wǎng)上摳圖）
20190530121157928.png
- 發(fā)現(xiàn)執(zhí)行完畢
build.gradle（解析完依賴）之后的生命周期只有：Project.afterEvaluate和Gradle.projectsEvaluated（在3中試過不行）菲盾。那么只有afterEvaluate颓影，afterEvaluate還是每 個module執(zhí)行完畢依賴會回調(diào)一次，監(jiān)聽最后一個module回調(diào)的時機懒鉴，并修改依舊還是報相同錯誤诡挂。綜上在生命周期找不到合適的時機 - 直接找
gradle源碼 找到異常出現(xiàn)的代碼，具體是在 ：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()));
}
}
}
- 出現(xiàn)這個異常的原因主要是
type為MutationType.DEPENDENCY_ATTRIBUTES临谱，那么在哪里賦值為DEPENDENCY_ATTRIBUTES璃俗，并趕在它之前修改依賴不就解決了，給出相關(guān)gradle源碼調(diào)用流程：
未命名文件 (1).png
那么基本是通過
apply plugin: 'com.android.application'開始調(diào)用進來并通過設(shè)置
project.gradle.projectsEvaluated{}監(jiān)聽回調(diào)悉默，把type設(shè)置成DEPENDENCY_ATTRIBUTES 城豁，通過這次排查源碼知道 gradle 也是通過projectsEvaluated這個生命周期才開始解決依賴關(guān)系（這時候所有的module的依賴圖才全部生成）那么最后的解決方法 要在
projectsEvaluated去修改依賴，但是要趕在GradlePluginUtils里面的一個監(jiān)聽者之前抄课，通過反射剔除設(shè)置進去的所有projectsEvaluated監(jiān)聽者（其實就是Action的匿名內(nèi)部對象）唱星，先執(zhí)行rockectXPlugin的監(jiān)聽者雳旅，后面再執(zhí)行其他的監(jiān)聽者。大概是這樣子：
//AppProjectDependencies.kt
init {
val projectsEvaluatedList = hookProjectsEvaluatedAction()
project.gradle.projectsEvaluated {
//先執(zhí)行重依賴
resolveDenpendency()
//后執(zhí)行移除的監(jiān)聽（主要調(diào)整執(zhí)行順序间聊，重依賴才能生效和不報錯攒盈，可能有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)
}
}
}
//把所有 監(jiān)聽了 projectsEvaluated 的匿名內(nèi)部類移除
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 依賴關(guān)系 project 替換成 aar 技術(shù)方案
- 每一個
module依賴關(guān)系替換的遍歷順序是無序的偷遗，所以技術(shù)方案需要支持無序的替換 - 目前使用的方案是：如果當前模塊
A未改動，需要把A通過localMaven置換成A.aar,并把A.aar以及A的child依賴驼壶，給到第一層的parent module即可氏豌。（可能會質(zhì)疑如果 parent module 也是 aar 怎么辦，其實這塊也是沒有問題的热凹，這里就不展開說了泵喘，篇幅太長） - 為什么要給到
parent不能直接給到app，下圖一個簡單的示例如果B.aar不給A模塊的話般妙，A使用B模塊的接口不見了纪铺，會導(dǎo)致編譯不過
8b6e18135662895b9fae8e9940f3aed.png
-
給出整體項目替換的技術(shù)方案演示：
RocketXPlugin (3).jpg
- 整體的實現(xiàn)在
DependenciesHelper.kt這個類中，由于講起來篇幅太長碟渺，有興趣可查閱開源庫代碼
4.5鲜锚、hook 編譯流程，完成后置換 loacal maven 中被修改的 aar
- 點擊三角形
run苫拍，執(zhí)行的命令是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 狀態(tài)欄 button，小火箭按鈕一個噴火一個沒有噴火绒极，代表 enable/disable , 一個 掃把clean rockectx 的緩存骏令，需要通過編寫 intellij idea plugin 即可，也就是 目前擁有兩個插件了垄提，一個 gradle 插件一個 AS 插件:
image.png
五榔袋、一天一個小驚喜( bug 較多)
5.1、發(fā)現(xiàn)點擊 run 按鈕 铡俐，執(zhí)行的命令是 app:assembleDebug 凰兑，各個子 module 在 output 并沒有打包出 aar
解決：通過研究 gradle 源碼發(fā)現(xiàn)打包是由 bundle${Flavor}${BuildType}Aar 這個task執(zhí)行出來，那么只需要將各個模塊對應(yīng)的 task 找到并注入到 app:assembleDebug 之后運行即可：
android.applicationVariants.forEach {
getAppAssembleTask(ASSEMBLE + it.flavorName.capitalize() + it.buildType.name.capitalize())?.let { task ->
hookBundleAarTask(task, it.buildType.name)
}
}
5.2审丘、發(fā)現(xiàn)運行起來后存在多個 jar 包重復(fù)問題
解決： 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、發(fā)現(xiàn) aar/jar 存在多種依賴方式
implementation (name: 'libXXX', ext: 'aar')
implementation files("libXXX.aar")
解決：使用第一種露泊，第二種會合并進aar,導(dǎo)致類重復(fù)問題
5.4喉镰、發(fā)現(xiàn) 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 打包出來的產(chǎn)物沉噩。
解決：通過 childProject.configurations.maybeCreate("default").artifacts 找到所有添加進來的 aar 捺宗，單獨發(fā)布 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、發(fā)現(xiàn) android module 打包出來可以是 jar
解決：通過找到名字叫做 jar 的task川蒙，并且在 jar task 后面注入 uploadLocalMaven task,代碼實現(xiàn)在 JarFlatLocalMaven.kt
5.6蚜厉、發(fā)現(xiàn) arouter 有 bug，transform 沒有通過 outputProvider.deleteAll() 清理舊的緩存
解決：詳情查看 issue畜眨，結(jié)果arouter 問題是解決了昼牛，代碼也是合并了。但并沒有發(fā)布新的插件版本到 mavenCentral康聂，于是先自行幫 arouter 解決一下贰健。然而arouter 并沒有啟動 增量編譯，導(dǎo)致 DexArchiveBuilderTask 運行巨慢恬汁，也就是打 dex 包很慢伶椿，項目中我重改了 arouter 插件源碼支持 TransForm 增量速度提升一倍, 具體細節(jié)就下節(jié)和 dex 速度優(yōu)化一起講。
六氓侧、下一步展望
目前初步的版本已經(jīng)能夠在在項目 run 起來脊另，但是還是有很多小問題不斷的冒出并解決，路漫漫其修遠兮甘苍，吾將上下而求索尝蠕。。
下步計劃：
-
dexBuild task優(yōu)化 - 解決各種兼容性問題
目前插件趨于穩(wěn)定载庭，喜歡嘗鮮的朋友可以通過github教程接入看彼，一起關(guān)注后期進展。后續(xù) issue 的解決思路都會在本文不斷更新囚聚，如果你喜歡本文就給我們 star 吧靖榕。
github開源地址
