一、背景描述

在項(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)?nbsp;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);
    }

那么依葫蘆畫瓢添加 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<String, String>()
        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<String, File>()
        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)

提供 AS 狀態(tài)欄 button，小火箭按鈕一個(gè)噴火一個(gè)沒(méi)有噴火，代表 enable/disable , 一個(gè) 掃把clean rockectx 的緩存，需要通過(guò)編寫 intellij idea plugin 即可，也就是 目前擁有兩個(gè)插件了，一個(gè) gradle 插件一個(gè) AS 插件: image.png

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

5.1 output 沒(méi)有打包出 aar

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

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

5.6 arouter  bug

發(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)展。

以上就是Android 性能優(yōu)化實(shí)現(xiàn)全量編譯提速的黑科技的詳細(xì)內(nèi)容，更多關(guān)于Android 全量編譯提速的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論