記得之前有同學(xué)在留言區(qū)問過我怎么做編譯優(yōu)化德澈，我當(dāng)時說了個方案圃验，就是編譯時將所有的模塊依賴修改為 aar缝呕，然后每次編譯將變動的模塊改成源碼依賴供常，同時編譯完成再將修改模塊上傳為 aar栈暇，這樣可以始終做到僅有最少的模塊參與源碼編譯煎源，從而提升編譯速度手销。
當(dāng)然說起來輕松锋拖，做起來沒有那么容易，終于有位小伙伴將上述描述開發(fā)成一個開源方案了适袜，非常值得大家學(xué)習(xí)和借鑒痪蝇。
1背景描述
在項目體量越來越大的情況下鄙陡，編譯速度也隨著增長躏啰，有時候一個修改需要等待長達(dá)好幾分鐘的編譯時間。
基于這種普遍的情況给僵，推出了 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)系進(jì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 進(jìn)行添加進(jìn)去,而 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 包丟進(jìn)去,依賴修改時候通過找尋進(jìn)行替換。
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)系圖時機(jī)空郊，并在此處生成依賴圖解析器。
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 后面補(bǔ)一個 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 包會打進(jìn) aar 中的lib 可直接剔除浅萧。通過以下代碼可以判斷：
// 這里的依賴是以下兩種： 無需添加在 parent 逐沙，因為 jar 包直接進(jìn)入 自身的 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")
解決：使用第一種吩案，第二種會合并進(jìn)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 找到所有添加進(jìn)來的 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 起來，但是還是有很多小問題不斷的冒出并解決肩袍，路漫漫其修遠(yuǎn)兮杭棵，吾將上下而求索。
下步計劃：
dexBuild task 優(yōu)化氛赐。
解決各種兼容性問題魂爪。
目前插件 上傳maven還在流程中，喜歡嘗鮮的朋友可以通過本地接入艰管，一起關(guān)注后期進(jìn)展滓侍。
