怎麼做編譯優化，當時說了個方案，就是編譯時將所有的模組依賴修改為 aar，然後每次編譯將變動的模組改成原始碼依賴，同時編譯完成再將修改模組上傳為 aar，這樣可以始終做到僅有最少的模組參與原始碼編譯，從而提升編譯速度。

當然說起來輕鬆，做起來沒有那麼容易，終於有位小夥伴將上述描述開發成一個開源方案了，非常值得大家學習和借鑑。

1.背景描述

在專案體量越來越大的情況下，編譯速度也隨著增長，有時候一個修改需要等待長達好幾分鐘的編譯時間。

基於這種普遍的情況，推出了 RocketX ,通過在編譯流程動態修改專案依賴關係， 動態 替換 module 為 aar，做到只編譯改動模組，其他模組不參與編譯，無需改動原有專案任何程式碼，提高全量編譯的速度。

2.效果展示

2.1、測試專案介紹

目標專案一共 3W+ 個類與資原始檔，全量編譯 4min 左右（測試使用 18 年 mbp 8代i7 16g）。

通過 RocketX 全量增速之後的效果（每一個操作取 3 次平均值）。

專案依賴關係如下圖，app 依賴 bm 業務模組，bm 業務模組依賴頂層 base/comm 模組。

依賴關係

• 當 base/comm 模組改動，底部的所有模組都必須參與編譯。因為 app/bmxxx 模組可能使用了 base 模組中的介面或變數等，並且不知道是否有改動到。（那麼速度就非常慢）

• 當 bmDiscover 做了改動，只需要 app 模組和 bmDiscover 兩個模組參與編譯。（速度較快）

• rx(RocketX) 在無論哪一個模組的編譯速度基本都是在控制在 30s 左右，因為只編譯 app 和 改動的模組，其他模組是 aar 包不參與編譯。

頂層模組速度提升 300%+

3.思路問題分析與模組搭建

3.1、思路問題分析

需要通過 gradle plugin 的形式動態修改沒有改動過的 module 依賴為 相對應的 aar 依賴，如果 module 改動，退化成 project 工程依賴，這樣每次只有改動的 module 和 app 兩個模組編譯。

需要把 implement/api moduleB，修改為implement/api aarB。

需要構建 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.問題解決與實現

4.1、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可以獲取。

  DependencyHandler getDependencies(); 

通過以上的分析，新增相對應的 aar/jar 可以通過以下程式碼實現。

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 優先使用 flatDir 實現通過指定一個快取目錄把生成 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 去做實現。

以每一個 module 為一個粒度，遞迴遍歷當前 module 的檔案，把每個檔案的 lastModifyTime 整合計算得出一個唯一標識 countTime。

通過 countTime 與上一次的作對比,相同說明沒改動,不同則改動. 並需要同步計算後的 countTime 到本地快取中。

整體 3W 個檔案耗時 1.2s 可以接受。

4.4、 module 依賴關係獲取。

通過以下程式碼可以找到生成整個專案的依賴關係圖時機，並在此處生成依賴圖解析器。

 project.gradle.addListener(DependencyResolutionListener listener)

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 模組的介面不見了，會導致編譯不過。

給出整體專案替換的技術方案演示：

4.5、hook 編譯流程，完成後置換 loacal maven 中被修改的 aar。

點選三角形 run，執行的命令是 app:assembleDebug , 需要在 assembleDebug 後面補一個 uploadLocalMavenTask, 通過 finalizedBy 把我們的 task 執行起來去同步修改後的 aar

4.6、提供 AS 狀態列 button，小火箭按鈕一個噴火一個沒有噴火，代表 enable/disable , 一個 掃把clean rockectx 的快取。

5一天一個小驚喜

5.1、發現點選 run 按鈕 ，執行的命令是 app:assembleDebug ，各個子 module 在 output 並沒有打包出 aar。

解決：通過研究 gradle 原始碼發現打包是由 bundle{BuildType}Aar 這個task執行出來，那麼只需要將各個模組對應的 task 找到並注入到 app:assembleDebug 之後執行即可。

5.2、發現執行起來後存在多個 jar 包重複問題。

解決：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、發現 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。

5.5、發現 android module 打包出來可以是 jar。

解決：通過找到名字叫做 jar 的task，並且在 jar task 後面注入 uploadLocalMaven task。

5.6、發現 arouter 有 bug，transform 沒有通過 outputProvider.deleteAll() 清理舊的快取。

解決：詳情檢視 issue，結果arouter 問題是解決了，程式碼也是合併了。但並沒有釋出新的外掛版本到 mavenCentral，於是先自行幫 arouter 解決一下。

https://github.com/alibaba/ARouter/issues/964

</article>
關注我，每天分享知識乾貨！