Android效能優化:全量編譯提速黑科技!

語言: CN / TW / HK

 BATcoder技術 群,讓一部分人先進大廠

大家好,我是劉望舒,騰訊最具價值專家,著有三本業內知名暢銷書,連續五年蟬聯電子工業出版社年度優秀作者, 百度百科收錄的資深技術專家。

前華為面試官、獨角獸公司技術總監。

想要 加入  BATcoder技術群,公號回覆 BAT  即可。

作者: Overried 連結:https://www.jianshu.com/p/59b95b5a7fab

一、背景描述

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

基於這種普遍的情況,推出了 RocketX , 通過在編譯流程 動態 替換 module 為 aar ,提高全量編譯的速度。

二、效果展示

2.1、測試專案介紹

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

  • 通過 RocketX 全量增速之後的效果(每一個操作取 3 次平均值)

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

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

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

  • 原生編譯 - 當 bmDiscover 做了改動,只需要 app 模組和 bmDiscover 兩個模組參與編譯(速度較快)

對於 rx(RocketX) 編譯頂層模組速度提升 300%+

三、思路問題分析與模組搭建:

3.1、思路問題分析

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

  • 需要把 implement/api moduleB ,修改為 implement/api aarB ,並且需要知道外掛中如何加入 aar 依賴和剔除原有依賴

  • 需要構建 local maven 儲存未被修改的 module 對應的 aar(也可以通過 flatDir 代替速度更快)

  • 編譯流程啟動,需要找到哪一個 module 做了修改

  • 需要遍歷每一個 module 的依賴關係進行置換, module 依賴怎麼獲取?一次效能獲取到所有模組依賴,還是分模組各自回撥?修改其中一個模組依賴關係會阻斷後面模組依賴回撥?

  • 每一個 module 換變成 aar 之後,自身依賴的 child 依賴 (網路依賴,aar),給到 parent module (如何找到所有 parent module) ? 還是直接給 app module ? 有沒有 appmodule 依賴斷掉的風險?這裡需要出一個技術方案。

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

  • 提供 AS 狀態列 button, 實現開啟關閉功能,加速編譯還是讓開發者使用已經習慣性的三角形 run 按鈕

3.2、模組搭建

依照上面的分析,雖然問題很多,但是大致可以把整個專案分成以下幾塊:

四、問題解決與實

如何手動新增 aar 依賴,分析 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可以獲取

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

doAdd 方法三個引數通過 debug 原始碼發現, configuration 就是 "implementation" , "api" , "compileOnly" 這三個字串生成的物件, dependencyNotation 是一個 LinkHashMap 有兩個鍵值對,分別是 name:aarName , ext:aar ,最後一個configureAction 傳 null 就可以了,呼叫 project.dependencies.add 最終會調到 doAdd 方法 ,也就是說直接呼叫 add 即可。

 public Dependency add(String configurationName, Object dependencyNotation) {
return this.add(configurationName, dependencyNotation, (Closure)null);
}

public Dependency add(String configurationName, Object dependencyNotation, Closure configureClosure) {
//這裡直接呼叫到了 doAdd
return this.doAdd(this.configurationContainer.getByName(configurationName), dependencyNotation, configureClosure);
}

那麼依葫蘆畫瓢新增 aar/jar 的實現程式碼: configNamechildProject 中的 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)
}

localMave 優先使用 flatDir 實現通過指定一個快取目錄 getLocalMavenCacheDir 把生成 aar/jar 包丟進去,依賴修改時候通過 上面的 4.1 新增對應的 aar 即可:

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

編譯流程啟動,需要找到哪一個 module做了修改

使用遍歷整個專案的檔案的 lastModifyTime 去做實現

已每一個 module 為一個粒度,遞迴遍歷當前 module 的檔案,把每個檔案的 lastModifyTime 整合計算得出一個唯一標識 countTime 通過 countTime 與上一次的作對比,相同說明沒改動,不同則改動. 並需要同步計算後的 countTime 到本地快取中

整體 3W 個檔案耗時 1.2s 可以接受,目前在類 ChangeModuleUtils.kt 進行實現

module 依賴關係獲取

通過以下程式碼可以找到生成整個專案的依賴關係圖時機,並在此處生成依賴圖解析器。時機要在真正編譯之前,確保依賴關係獲取後替換能生效,而且要在全域性module依賴圖已經生成之後,通過以下監聽可以滿足:

  public interface DependencyResolutionListener {
void beforeResolve(ResolvableDependencies var1);

void afterResolve(ResolvableDependencies var1);
}

project.gradle.addListener(DependencyResolutionListener listener)

如何獲取每個module 的依賴,依賴就藏在 Configuration.dependencies ,那麼通過 project.configurations.maybeCreate(configName ) 找到所有的 Configuration 物件,就能得到每個module的 dependencies

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

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

整體的實現在 DependenciesHelper.kt 這個類中,由於講起來篇幅太長,有興趣可查閱開源庫程式碼

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

點選三角形 run,執行的命令是 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 狀態列 button,小火箭按鈕一個噴火一個沒有噴火,代表 enable/disable , 一個 掃把clean rockectx 的快取,需要通過編寫 intellij idea plugin 即可,也就是 目前擁有兩個外掛了,一個 gradle 外掛一個 AS 外掛: image.png

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

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

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

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

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

  • 解決: 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 發現 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


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 發現 android module 打包出來可以是 jar

解決:通過找到名字叫做 jar 的task,並且在 jar task 後面注入 uploadLocalMaven task,程式碼實現在 JarFlatLocalMaven.kt

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

解決:詳情檢視 issue,結果arouter 問題是解決了,程式碼也是合併了。但並沒有釋出新的外掛版本到 mavenCentral ,於是先自行幫 arouter 解決一下。然而arouter 並沒有啟動 增量編譯,導致 DexArchiveBuilderTask 執行巨慢,也就是打 dex 包很慢,專案中我重改了 arouter 外掛原始碼支援 TransForm 增量速度提升一倍, 具體細節就下節和 dex 速度優化一起講。

六、下一步展望

目前初步的版本已經能夠在在專案 run 起來,但是還是有很多小問題不斷的冒出並解決,路漫漫其修遠兮,吾將上下而求索。。

下步計劃:

  • dexBuild task 優化

  • 解決各種相容性問題 目前外掛趨於穩定,喜歡嚐鮮的朋友可以通過github教程接入,一起關注後期進展。

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