作者：Overried鏈接：https://www.jianshu.com/p/59b95b5a7fab

一、背景描述

在項(xiàng)目體量越來(lái)越大的情況下，編譯速度也隨著增長(zhǎng)，有時(shí)候一個(gè)修改需要等待長(zhǎng)達(dá)好幾分鐘的編譯時(shí)間。

基于這種普遍的情況，推出了 RocketX ,通過(guò)在編譯流程 動(dòng)態(tài) 替換 module 為 aar ，提高全量編譯的速度。

二、效果展示

2.1、測(cè)試項(xiàng)目介紹

• 目標(biāo)項(xiàng)目一共 3W+ 個(gè)類與資源文件，全量編譯 4min 左右（測(cè)試使用 18 年 mbp 8代i7 16g）

• 通過(guò) RocketX 全量增速之后的效果（每一個(gè)操作取 3 次平均值）

項(xiàng)目依賴關(guān)系如下圖，app 依賴 bm 業(yè)務(wù)模塊，bm 業(yè)務(wù)模塊依賴頂層 base/comm模塊

• rx(RocketX) 編譯 - 可以看到 rx(RocketX) 在無(wú)論哪一個(gè)模塊的編譯速度基本都是在控制在 30s 左右，因?yàn)橹痪幾g app 和 改動(dòng)的模塊，其他模塊是 aar 包不參與編譯。

• 原生編譯 - 當(dāng) base/comm 模塊改動(dòng)，底部的所有模塊都必須參與編譯。因?yàn)?app/bmxxx 模塊可能使用了 base 模塊中的接口或變量等，并且不知道是否有改動(dòng)到。（那么速度就非常慢）

• 原生編譯 - 當(dāng) bmDiscover 做了改動(dòng)，只需要 app模塊和 bmDiscover 兩個(gè)模塊參與編譯（速度較快）

對(duì)于 rx(RocketX) 編譯頂層模塊速度提升 300%+

三、思路問(wèn)題分析與模塊搭建:

3.1、思路問(wèn)題分析

• 需要通過(guò) gradle plugin 的形式動(dòng)態(tài)修改沒(méi)有改動(dòng)過(guò)的 module 依賴為 相對(duì)應(yīng)的 aar 依賴，如果 module 改動(dòng)，退化成 project 工程依賴，這樣每次只有改動(dòng)的 module 和 app 兩個(gè)模塊編譯。

• 需要把implement/api moduleB，修改為implement/api aarB，并且需要知道插件中如何加入 aar 依賴和剔除原有依賴

• 需要構(gòu)建 local maven 存儲(chǔ)未被修改的 module 對(duì)應(yīng)的 aar（也可以通過(guò) flatDir 代替速度更快）

• 編譯流程啟動(dòng)，需要找到哪一個(gè) module 做了修改

• 需要遍歷每一個(gè) module的依賴關(guān)系進(jìn)行置換，module依賴怎么獲??？一次性能獲取到所有模塊依賴，還是分模塊各自回調(diào)？修改其中一個(gè)模塊依賴關(guān)系會(huì)阻斷后面模塊依賴回調(diào)？

• 每一個(gè)module換變成 aar 之后，自身依賴的 child 依賴 （網(wǎng)絡(luò)依賴，aar）,給到 parent module (如何找到所有 parent module) ? 還是直接給 app module ? 有沒(méi)有 app 到 module 依賴斷掉的風(fēng)險(xiǎn)？這里需要出一個(gè)技術(shù)方案。

• 需要hook 編譯流程，完成后置換 loacal maven 中被修改的 aar

• 提供 AS 狀態(tài)欄 button, 實(shí)現(xiàn)開(kāi)啟關(guān)閉功能，加速編譯還是讓開(kāi)發(fā)者使用已經(jīng)習(xí)慣性的三角形 run 按鈕

3.2、模塊搭建

依照上面的分析，雖然問(wèn)題很多，但是大致可以把整個(gè)項(xiàng)目分成以下幾塊：

四、問(wèn)題解決與實(shí)

如何手動(dòng)添加 aar 依賴，分析implement 源碼實(shí)現(xiàn)入口在 DynamicAddDependencyMethods 中的 tryInvokeMethod 方法。他是一個(gè)動(dòng)態(tài)語(yǔ)言的methodMissing 功能

tryInvokeMethod 代碼分析

?public?DynamicInvokeResult?tryInvokeMethod(String?name,?Object...?arguments)?{
???????//省略部分代碼?...
???????return?DynamicInvokeResult.found(this.dependencyAdder.add(configuration,?normalizedArgs.get(0),?(Closure)null));
?}

dependencyAdder 實(shí)現(xiàn)是一個(gè) 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 進(jìn)行添加進(jìn)去，而 DefaultDependencyHandler 在 project可以獲取

public?interface?Project?extends?Comparable<Project>,?ExtensionAware,?PluginAware?{
?????...
?????DependencyHandler?getDependencies();?
?????...
}

而 doAdd 方法三個(gè)參數(shù)通過(guò)debug 源碼發(fā)現(xiàn)，configuration就是 "implementation","api", "compileOnly" 這三個(gè)字符串生成的對(duì)象，dependencyNotation是一個(gè) LinkHashMap 有兩個(gè)鍵值對(duì)，分別是 name:aarName, ext:aar,最后一個(gè)configureAction 傳 null 就可以了，調(diào)用project.dependencies.add 最終會(huì)調(diào)到 doAdd 方法，也就是說(shuō)直接調(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);
????}

那么依葫蘆畫(huà)瓢添加 aar/jar 的實(shí)現(xiàn)代碼：configName 是 childProject中的 configName ，也就是 "implementation", "api","compileOnly" 這三個(gè)字符串，原封不動(dòng)拿過(guò)來(lái)：

????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)
????}

localMave 優(yōu)先使用 flatDir實(shí)現(xiàn)通過(guò)指定一個(gè)緩存目錄 getLocalMavenCacheDir 把生成aar/jar 包丟進(jìn)去,依賴修改時(shí)候通過(guò) 上面的 4.1 添加對(duì)應(yīng)的 aar 即可：

??fun?flatDirs()?{
????????val?map?=?mutableMapOf()
????????map.put("dirs",?File(getLocalMavenCacheDir()))
????????appProject.rootProject.allprojects?{
????????????it.repositories.flatDir(map)
????????}
????}

編譯流程啟動(dòng)，需要找到哪一個(gè) module做了修改

使用遍歷整個(gè)項(xiàng)目的文件的 lastModifyTime 去做實(shí)現(xiàn)

已每一個(gè) module 為一個(gè)粒度，遞歸遍歷當(dāng)前 module 的文件，把每個(gè)文件的 lastModifyTime 整合計(jì)算得出一個(gè)唯一標(biāo)識(shí) countTime 通過(guò) countTime 與上一次的作對(duì)比,相同說(shuō)明沒(méi)改動(dòng),不同則改動(dòng). 并需要同步計(jì)算后的 countTime 到本地緩存中

整體 3W 個(gè)文件耗時(shí) 1.2s 可以接受，目前在類 ChangeModuleUtils.kt 進(jìn)行實(shí)現(xiàn)

module 依賴關(guān)系獲取

通過(guò)以下代碼可以找到生成整個(gè)項(xiàng)目的依賴關(guān)系圖時(shí)機(jī)，并在此處生成依賴圖解析器。時(shí)機(jī)要在真正編譯之前，確保依賴關(guān)系獲取后替換能生效，而且要在全局module依賴圖已經(jīng)生成之后，通過(guò)以下監(jiān)聽(tīng)可以滿足：

??public?interface?DependencyResolutionListener?{
????void?beforeResolve(ResolvableDependencies?var1);

????void?afterResolve(ResolvableDependencies?var1);
}

???project.gradle.addListener(DependencyResolutionListener?listener)

如何獲取每個(gè)module 的依賴，依賴就藏在Configuration.dependencies，那么通過(guò)project.configurations.maybeCreate(configName) 找到所有的 Configuration對(duì)象，就能得到每個(gè)module的 dependencies

module 依賴關(guān)系 project 替換成 aar 技術(shù)方案

每一個(gè) module 依賴關(guān)系替換的遍歷順序是無(wú)序的，所以技術(shù)方案需要支持無(wú)序的替換

目前使用的方案是：如果當(dāng)前模塊 A 未改動(dòng)，需要把 A 通過(guò) localMaven 置換成 A.aar,并把 A.aar 以及 A 的 child 依賴，給到第一層的 parent module 即可。（可能會(huì)質(zhì)疑如果 parent module 也是 aar 怎么辦，其實(shí)這塊也是沒(méi)有問(wèn)題的，這里就不展開(kāi)說(shuō)了，篇幅太長(zhǎng)） 為什么要給到 parent 不能直接給到 app ，下圖一個(gè)簡(jiǎn)單的示例如果 B.aar 不給 A 模塊的話，A 使用 B 模塊的接口不見(jiàn)了，會(huì)導(dǎo)致編譯不過(guò)

給出整體項(xiàng)目替換的技術(shù)方案演示：

整體的實(shí)現(xiàn)在 DependenciesHelper.kt這個(gè)類中，由于講起來(lái)篇幅太長(zhǎng)，有興趣可查閱開(kāi)源庫(kù)代碼

hook 編譯流程，完成后置換 loacal maven 中被修改的 aar

點(diǎn)擊三角形 run，執(zhí)行的命令是 app:assembleDebug , 需要在 assembleDebug 后面補(bǔ)一個(gè) uploadLocalMavenTask, 通過(guò) finalizedBy把我們的task運(yùn)行起來(lái)去同步修改后的 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，小火箭按鈕一個(gè)噴火一個(gè)沒(méi)有噴火，代表 enable/disable , 一個(gè) 掃把clean rockectx 的緩存，需要通過(guò)編寫(xiě) intellij idea plugin 即可，也就是 目前擁有兩個(gè)插件了，一個(gè) gradle 插件一個(gè) AS 插件: image.png

五、一天一個(gè)小驚喜( bug 較多)

5.1、發(fā)現(xiàn)點(diǎn)擊 run 按鈕 ，執(zhí)行的命令是 app:assembleDebug ，各個(gè)子 module 在 output 并沒(méi)有打包出 aar

解決：通過(guò)研究 gradle 源碼發(fā)現(xiàn)打包是由 bundle{BuildType}Aar 這個(gè)task執(zhí)行出來(lái)，那么只需要將各個(gè)模塊對(duì)應(yīng)的 task 找到并注入到 app:assembleDebug 之后運(yùn)行即可：

????????android.applicationVariants.forEach?{
????????????getAppAssembleTask(ASSEMBLE?+?it.flavorName.capitalize()?+?it.buildType.name.capitalize())?.let?{?task?->
????????????????????hookBundleAarTask(task,?it.buildType.name)
????????????????}
????????}

5.2 發(fā)現(xiàn)運(yùn)行起來(lái)后存在多個(gè) jar 包重復(fù)問(wèn)題

• 解決：implementation fileTree(dir: "libs", include: ["*.jar"])jar 依賴不能交到 parent module，jar 包會(huì)打進(jìn) aar 中的lib 可直接剔除。通過(guò)以下代碼可以判斷：

//?這里的依賴是以下兩種：?無(wú)需添加在 parent ，因?yàn)?jar 包直接進(jìn)入?自身的 aar 中的libs 文件夾
if?(childDepency?is?DefaultSelfResolvingDependency?&&?(childDepency.files?is?DefaultConfigurableFileCollection?||?childDepency.files?is?DefaultConfigurableFileTree))?{
//?這里的依賴是以下兩種：?無(wú)需添加在 parent ，因?yàn)?jar 包直接進(jìn)入?自身的 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")

解決：使用第一種，第二種會(huì)合并進(jìn)aar,導(dǎo)致類重復(fù)問(wèn)題

5.4 發(fā)現(xiàn) aar 新姿勢(shì)依賴

configurations.maybeCreate("default")
artifacts.add("default",?file('lib-xx.aar'))

上面代碼把 aar 做了一個(gè)單獨(dú)的 module 給到其他 module 依賴，default config 其實(shí)是 module 最終輸出 aar 的持有者，default config 可以持有一個(gè) 列表的aar ，所以把 aar 手動(dòng)添加到 default config，也相當(dāng)于當(dāng)前 module 打包出來(lái)的產(chǎn)物。

解決： 通過(guò) childProject.configurations.maybeCreate("default").artifacts 找到所有添加進(jìn)來(lái)的 aar ，單獨(dú)發(fā)布 localmaven

???fun?getAarByArtifacts(childProject:?Project):?MutableList?{
????????//找到當(dāng)前所有通過(guò)?artifacts.add("default",?file('xxx.aar'))?依賴進(jìn)來(lái)的?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 發(fā)現(xiàn) android module 打包出來(lái)可以是 jar

解決：通過(guò)找到名字叫做 jar 的task，并且在 jar task 后面注入 uploadLocalMaven task,代碼實(shí)現(xiàn)在 JarFlatLocalMaven.kt

5.6發(fā)現(xiàn) arouter 有 bug，transform 沒(méi)有通過(guò) outputProvider.deleteAll() 清理舊的緩存

解決：詳情查看 issue，結(jié)果arouter 問(wèn)題是解決了，代碼也是合并了。但并沒(méi)有發(fā)布新的插件版本到 mavenCentral，于是先自行幫 arouter 解決一下。然而arouter 并沒(méi)有啟動(dòng) 增量編譯，導(dǎo)致 DexArchiveBuilderTask運(yùn)行巨慢，也就是打 dex 包很慢，項(xiàng)目中我重改了 arouter 插件源碼支持 TransForm 增量速度提升一倍, 具體細(xì)節(jié)就下節(jié)和 dex 速度優(yōu)化一起講。

六、下一步展望

目前初步的版本已經(jīng)能夠在在項(xiàng)目 run 起來(lái)，但是還是有很多小問(wèn)題不斷的冒出并解決，路漫漫其修遠(yuǎn)兮，吾將上下而求索。。

下步計(jì)劃：

• dexBuild task 優(yōu)化
• 解決各種兼容性問(wèn)題 目前插件趨于穩(wěn)定，喜歡嘗鮮的朋友可以通過(guò)github教程接入，一起關(guān)注后期進(jìn)展。

github地址:https://github.com/trycatchx/RocketXPlugin