記得之前有同學(xué)在留言區(qū)問過我怎么做編譯優(yōu)化，我當(dāng)時說了個方案，就是編譯時將所有的模塊依賴修改為 aar，然后每次編譯將變動的模塊改成源碼依賴，同時編譯完成再將修改模塊上傳為 aar，這樣可以始終做到僅有最少的模塊參與源碼編譯，從而提升編譯速度。
當(dāng)然說起來輕松，做起來沒有那么容易，終于有位小伙伴將上述描述開發(fā)成一個開源方案了，非常值得大家學(xué)習(xí)和借鑒。
1背景描述
在項目體量越來越大的情況下，編譯速度也隨著增長，有時候一個修改需要等待長達好幾分鐘的編譯時間。
基于這種普遍的情況，推出了 RocketX ,通過在編譯流程動態(tài)修改項目依賴關(guān)系， 動態(tài) 替換 module 為 aar，做到只編譯改動模塊，其他模塊不參與編譯，無需改動原有項目任何代碼，提高全量編譯的速度。
2效果展示
2.1、測試項目介紹
目標(biāo)項目一共 3W+ 個類與資源文件，全量編譯 4min 左右（測試使用 18 年 mbp 8代i7 16g）。
通過 RocketX 全量增速之后的效果（每一個操作取 3 次平均值）。
項目依賴關(guān)系如下圖，app 依賴 bm 業(yè)務(wù)模塊，bm 業(yè)務(wù)模塊依賴頂層 base/comm 模塊。
依賴關(guān)系
? 當(dāng) base/comm 模塊改動，底部的所有模塊都必須參與編譯。因為 app/bmxxx 模塊可能使用了 base 模塊中的接口或變量等，并且不知道是否有改動到。（那么速度就非常慢）
? 當(dāng) bmDiscover 做了改動，只需要 app 模塊和 bmDiscover 兩個模塊參與編譯。（速度較快）
? rx(RocketX) 在無論哪一個模塊的編譯速度基本都是在控制在 30s 左右，因為只編譯 app 和 改動的模塊，其他模塊是 aar 包不參與編譯。
頂層模塊速度提升 300%+
3思路問題分析與模塊搭建
3.1、思路問題分析
需要通過 gradle plugin 的形式動態(tài)修改沒有改動過的 module 依賴為 相對應(yīng)的 aar 依賴，如果 module 改動，退化成 project 工程依賴，這樣每次只有改動的 module 和 app 兩個模塊編譯。
需要把 implement/api moduleB，修改為implement/api aarB。
需要構(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、模塊搭建
依照上面的分析，雖然問題很多，但是大致可以把整個項目分成以下幾塊：
4問題解決與實現(xiàn)
4.1、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可以獲取。
DependencyHandler getDependencies();
通過以上的分析，添加相對應(yīng)的 aar/jar 可以通過以下代碼實現(xiàn)。
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 優(yōu)先使用 flatDir 實現(xiàn)通過指定一個緩存目錄把生成 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 去做實現(xiàn)。
以每一個 module 為一個粒度，遞歸遍歷當(dāng)前 module 的文件，把每個文件的 lastModifyTime 整合計算得出一個唯一標(biāo)識 countTime。
通過 countTime 與上一次的作對比,相同說明沒改動,不同則改動. 并需要同步計算后的 countTime 到本地緩存中。
整體 3W 個文件耗時 1.2s 可以接受。
4.4、 module 依賴關(guān)系獲取。
通過以下代碼可以找到生成整個項目的依賴關(guān)系圖時機，并在此處生成依賴圖解析器。
project.gradle.addListener(DependencyResolutionListener listener)
4.5、 module 依賴關(guān)系 project 替換成 aar 技術(shù)方案
每一個 module 依賴關(guān)系替換的遍歷順序是無序的，所以技術(shù)方案需要支持無序的替換。
目前使用的方案是：如果當(dāng)前模塊 A 未改動，需要把 A 通過 localMaven 置換成 A.aar,并把 A.aar 以及 A 的 child 依賴，給到第一層的 parent module 即可。（可能會質(zhì)疑如果 parent module 也是 aar 怎么辦，其實這塊也是沒有問題的，這里就不展開說了，篇幅太長）
為什么要給到 parent 不能直接給到 app ，下圖一個簡單的示例如果 B.aar 不給 A 模塊的話，A 使用 B 模塊的接口不見了，會導(dǎo)致編譯不過。
給出整體項目替換的技術(shù)方案演示：
4.5、hook 編譯流程，完成后置換 loacal maven 中被修改的 aar。
點擊三角形 run，執(zhí)行的命令是 app:assembleDebug , 需要在 assembleDebug 后面補一個 uploadLocalMavenTask, 通過 finalizedBy 把我們的 task 運行起來去同步修改后的 aar
4.6、提供 AS 狀態(tài)欄 button，小火箭按鈕一個噴火一個沒有噴火，代表 enable/disable , 一個 掃把clean rockectx 的緩存。
5一天一個小驚喜
5.1、發(fā)現(xiàn)點擊 run 按鈕 ，執(zhí)行的命令是 app:assembleDebug ，各個子 module 在 output 并沒有打包出 aar。
解決：通過研究 gradle 源碼發(fā)現(xiàn)打包是由 bundle{BuildType}Aar 這個task執(zhí)行出來，那么只需要將各個模塊對應(yīng)的 task 找到并注入到 app:assembleDebug 之后運行即可。
5.2、發(fā)現(xiàn)運行起來后存在多個 jar 包重復(fù)問題。
解決：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、發(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，也相當(dāng)于當(dāng)前 module 打包出來的產(chǎn)物。
解決：通過 childProject.configurations.maybeCreate("default").artifacts 找到所有添加進來的 aar ，單獨發(fā)布 localmaven。
5.5、發(fā)現(xiàn) android module 打包出來可以是 jar。
解決：通過找到名字叫做 jar 的task，并且在 jar task 后面注入 uploadLocalMaven task。
5.6、發(fā)現(xiàn) arouter 有 bug，transform 沒有通過 outputProvider.deleteAll() 清理舊的緩存。
解決：詳情查看 issue，結(jié)果arouter 問題是解決了，代碼也是合并了。但并沒有發(fā)布新的插件版本到 mavenCentral，于是先自行幫 arouter 解決一下。
https://github.com/alibaba/ARouter/issues/964
6下一步展望
目前初步的版本已經(jīng)能夠在在項目 run 起來，但是還是有很多小問題不斷的冒出并解決，路漫漫其修遠兮，吾將上下而求索。
下步計劃：
dexBuild task 優(yōu)化。
解決各種兼容性問題。
目前插件 上傳maven還在流程中，喜歡嘗鮮的朋友可以通過本地接入，一起關(guān)注后期進展。
