作者簡(jiǎn)介

小明，攜程移動(dòng)開發(fā)工程師，專注于移動(dòng)端框架和基建開發(fā)；

(資料圖片僅供參考)

黃拉歡，攜程移動(dòng)開發(fā)經(jīng)理，專注于移動(dòng)端框架建設(shè)及性能調(diào)優(yōu)。

一、背景

Android 項(xiàng)目一般使用 Gradle 作為構(gòu)建打包工具，隨著業(yè)務(wù)需求的不斷迭代，代碼量提升的同時(shí)，Gradle 編譯耗時(shí)也在不斷的增長(zhǎng)，而編譯速度會(huì)直接決定開發(fā)流程效率的高低，影響面主要涉及到開發(fā)和測(cè)試階段。

對(duì)于火車票項(xiàng)目，經(jīng)過長(zhǎng)期的迭代過程導(dǎo)致模塊眾多工程龐大，優(yōu)化前一次干凈的全量編譯時(shí)間可達(dá)到10m39s，造成開發(fā)和測(cè)試都需要長(zhǎng)時(shí)間等待編譯出包，嚴(yán)重影響到開發(fā)和測(cè)試的效率。因此對(duì)火車票 App 進(jìn)行編譯速度優(yōu)化是件亟待解決的事情。

本次編譯速度優(yōu)化采用的方案是模塊AAR方案, 優(yōu)化目標(biāo)為: 優(yōu)化后一次干凈的全量編譯時(shí)間縮減為原來(lái)編譯時(shí)間的50%以下。

二、 模塊AAR方案介紹

Google 官網(wǎng)提供了優(yōu)化構(gòu)建速度的幾種方案，但基本上效果都不明顯。業(yè)內(nèi)常用的編譯加速方案一般有模塊aar、控制增量編譯、transform 優(yōu)化、dexBuilder 優(yōu)化等，其中有些方案侵入性太強(qiáng)或者 ROI 不高，模塊aar方案侵入性低，預(yù)計(jì)收益顯著，并且在大廠已經(jīng)成為標(biāo)配方案，可以作為本次編譯優(yōu)化的主方向。

AAR（Android ARchive）文件為 Android 庫(kù)編譯產(chǎn)物，其中包括 class、資源和清單文件，可用作 Android 應(yīng)用模塊依賴項(xiàng)。在Android 的構(gòu)建流程中，源碼編譯時(shí)會(huì)將依賴的 aar 庫(kù)和應(yīng)用模塊合并，在通過 apkbuilder 輸出 apk 產(chǎn)物。

圖1：android的構(gòu)建流程圖

Android 項(xiàng)目大多都是多模塊 Gradle 項(xiàng)目，構(gòu)建項(xiàng)目時(shí)所有的子模塊需要參與編譯，導(dǎo)致全量編譯時(shí)間冗長(zhǎng)。實(shí)際上，對(duì)于大部分的開發(fā)人員來(lái)說(shuō)，并不需要關(guān)注所有的模塊，只需要負(fù)責(zé)功能相關(guān)的業(yè)務(wù)模塊即可，因此這也提供了模塊aar方案的切入點(diǎn)。

一般來(lái)說(shuō)，aar方案都大同小異，涉及到模塊aar發(fā)布，project和module依賴的切換，傳遞依賴的處理等幾個(gè)方面。依賴切換我們采用的是 Gradle 官方文檔中直接自定義依賴項(xiàng)的解析方案，通過定義依賴替換規(guī)則來(lái)更改依賴項(xiàng)；aar的發(fā)布使用的是maven-publish插件；傳遞依賴使用的mavenPom文件管理。

火車票項(xiàng)目經(jīng)過多次模塊化的重構(gòu)后現(xiàn)有20個(gè)子模塊，可將這些子模塊獨(dú)立打包aar并發(fā)布至遠(yuǎn)程maven倉(cāng)庫(kù)中，在需要打包時(shí)用aar替換項(xiàng)目的構(gòu)建，就能將編譯的時(shí)間給節(jié)省下來(lái)，以提高打包效率。

圖2: 模塊aar開發(fā)示意圖

三、改造過程和遇到的問題3.1 構(gòu)建測(cè)量指標(biāo)

良好的優(yōu)化基于數(shù)據(jù)的呈現(xiàn)，首先第一步需要做的是分析構(gòu)建的性能。此處采用的是官方提供的Gradle --profile選項(xiàng)的方式統(tǒng)計(jì)數(shù)據(jù)?；静襟E為：

gradlew clean在每個(gè)build之間執(zhí)行干凈編譯，確保剖析完整的構(gòu)建流程；gradlew--profile--offline--rerun-tasks assembleFlavorDebug為某個(gè)變種task啟用性能剖析，并確保gradle使用的是緩存依賴項(xiàng)，且強(qiáng)制gradle重新運(yùn)行所有任務(wù)；構(gòu)建完成后，會(huì)生成html格式的性能剖析報(bào)告，可用于分析構(gòu)建信息和前后構(gòu)建對(duì)比；3.2 模塊aar的改造

因存在單個(gè)模塊發(fā)布的過程，模塊間需要盡量的解耦，而解耦首先要進(jìn)行模塊的劃分；其次，存在依賴關(guān)系的模塊間不能互相使用資源，這會(huì)造成編譯的失敗，所以理清模塊間的關(guān)系是當(dāng)務(wù)之急。

同時(shí)，我們需意識(shí)到當(dāng)我們完成 Gradle 腳本的編寫后，我們得到的應(yīng)該是一個(gè)app殼+其他模塊的依賴樹組合，可通過以下步驟進(jìn)行改造：

1）模塊間依賴樹重構(gòu)

首先分析項(xiàng)目各模塊依賴關(guān)系, 可使用開源腳本工具projectDependencyGraph.gradle生成依賴圖，示意圖如下：

圖3: 模塊間依賴樹混亂示意圖

可直觀的看出模塊間依賴關(guān)系冗余，模塊間的依賴不清晰，且基礎(chǔ)庫(kù)一般固定卻呈現(xiàn)網(wǎng)狀結(jié)構(gòu)。故需對(duì)網(wǎng)狀結(jié)構(gòu)進(jìn)行整理,將不經(jīng)常改動(dòng)的庫(kù)直接發(fā)布遠(yuǎn)程，如下：

圖4: 模塊間依賴樹整理示意圖

2）歷史Gradle腳本重構(gòu)

因歷史原因，火車票項(xiàng)目的 Gradle 邏輯冗余繁瑣，無(wú)統(tǒng)一管理略顯臃腫。為提高 Gradle 的擴(kuò)展性和靈活性，需要重構(gòu) Gradle 代碼：

對(duì)現(xiàn)有 Gradle 腳本按功能職責(zé)拆分成單個(gè)Gradle文件，需要使用的地方通過apply關(guān)鍵字應(yīng)用即可；基于原插件com.android.application和com.android.library建立兩套基準(zhǔn)Gradle文件，統(tǒng)一控制不同類型的模塊；抽取共有基礎(chǔ)依賴項(xiàng)作為獨(dú)立的 Gradle 文件，在subprojects中讓所有模塊都應(yīng)用這些依賴項(xiàng)；整理libs目錄中本地的aar文件，移動(dòng)至一個(gè)目錄，統(tǒng)一依賴本地aar；建立app_bundle.json文件記錄所有模塊項(xiàng)目的信息及類型，便于模塊項(xiàng)目是源碼還是aar的切換控制；開發(fā)一套模擬參數(shù)機(jī)制，支持合并環(huán)境輸入?yún)?shù)和local.properties參數(shù) 以便于 Gradle 功能的控制；如開啟某個(gè)transform，指定哪些模塊為aar等功能；重構(gòu) flavor 變體功能，動(dòng)態(tài)控制 flavor 的創(chuàng)建。

3）發(fā)布和依賴aar版本的控制

當(dāng)我們發(fā)布aar至遠(yuǎn)程倉(cāng)庫(kù)后，需要一個(gè)文件記錄已發(fā)布模塊aar的版本號(hào)，打包時(shí)通過此文件查找對(duì)應(yīng)版本的aar，此處使用的是 MCD 平臺(tái)采用 json 格式的 versionPath 文件。示意圖如下：

圖5：通過versionPath文件控制版本

模塊aar的核心在于對(duì)依賴項(xiàng)的控制。我們想要的是一個(gè)app殼+部分源碼模塊+部分aar模塊+其他依賴的結(jié)構(gòu)，因此下面幾點(diǎn)是要考慮到的：

在所有子模塊發(fā)布 maven 成功后，本地編譯使用aar模塊且環(huán)境參數(shù)沒有傳遞 versionPath 參數(shù)時(shí)，構(gòu)建腳本會(huì)自動(dòng)拉取Mcd最新的versionPath.json鏈接作為默認(rèn)的模塊aar信息表。開發(fā)階段需切換源碼/aar，可對(duì)項(xiàng)目中所有模塊進(jìn)行分類，分別為：入口模塊，源碼模塊，aar發(fā)布模塊，可移除模塊。另外，合并 gradle 環(huán)境參數(shù)和local.properties參數(shù)共同作為控制參數(shù)，然后修改app_bundle.json指定模塊類型以達(dá)到靈活切換的目的。例如，定義一個(gè)sourceProject參數(shù)指定哪些模塊作為源碼構(gòu)建。為模塊之間的依賴關(guān)系建立一個(gè)json文件aar_config.json，便于查看和修改模塊間依賴關(guān)系。

整個(gè)模塊aar打包流程圖如下：

圖6：模塊aar下的打包流程

4）抽取app多余代碼，使其成為真正的"殼"

App入口項(xiàng)目中存在的代碼會(huì)影響編譯效率，為盡可能降低編譯時(shí)間，將app中大部分 main 目錄代碼移動(dòng)至子模塊中，保證app模塊只剩一個(gè)空殼而已。

5）自定義依賴項(xiàng)的替換規(guī)則

通過app_bundle.json得知目標(biāo)模塊是aar格式后，我們可使用 Gradle 提供的自定義依賴替換規(guī)則來(lái)實(shí)現(xiàn)aar的切換功能。

依賴替換規(guī)則允許項(xiàng)目和模塊依賴項(xiàng)透明地替換為指定的替換項(xiàng)，項(xiàng)目和模塊依賴可互換地替換。對(duì)應(yīng)于源碼中ResolutionStrategyApi中的DependencySubstitutions接口，此功能常用于多項(xiàng)目構(gòu)建中靈活的組裝子項(xiàng)目。通過允許從存儲(chǔ)庫(kù)下載而不是構(gòu)建項(xiàng)目依賴項(xiàng)的子集，這對(duì)于加快大型多項(xiàng)目構(gòu)建的開發(fā)非常有用。

自定義依賴項(xiàng)替換規(guī)則如下：

//此處采用偽代碼形式，正式場(chǎng)景最佳實(shí)踐應(yīng)抽取到plugin中并提供extension和log功能//通過app_bundles.json信息決定是否應(yīng)用替換規(guī)則gradle.ext.appBundles.each { bundleName, bundleInfo ->    if (bundleInfo.buildType == "aar") {        gradle.ext.subsitituteMap[":$bundleName"] = "$specialGroupID:$bundleName:${bundleInfo.versionName}"    }  }//制定自定義解析規(guī)則,用模塊替換項(xiàng)目依賴項(xiàng)configurations.all { conf ->    resolutionStrategy.dependencySubstitution {        gradle.ext.subsitituteMap.each {            substitute project(it.key) with module(it.value)        }    }}

6）自定義pom文件管理傳遞依賴

此處通過maven-publish插件發(fā)布模塊aar，發(fā)布aar時(shí)不可混淆以防止依賴報(bào)錯(cuò)。

通過聲明pom文件來(lái)管理依賴及傳遞依賴是個(gè)很好的方式。發(fā)布模塊aar時(shí)，本身項(xiàng)目的子模塊aar不建議寫入pom文件，否則在模塊切換源碼時(shí)會(huì)存在遠(yuǎn)程aar和源碼沖突的情況，此時(shí)需要添加額外的exclude操作。

自定義pom文件如下：

//使用maven-publish插件發(fā)布aarapply plugin: "maven-publish"...publishing{...//自定義pom文件處理傳遞依賴  pom {      packaging = "aar"      withXml {          pomGenerate(it)      }  }}//獲取配置的依賴 configuration => dependenciesMapdef ascribeDependencies(String confName) {    def dependencySet = project.configurations.getByName(confName).getAllDependencies()    def dependenciesMap = [:]    //獲取module類型依賴，待寫入pom文件    dependencySet.withType(ExternalModuleDependency)        .findAll {            if (it.group != null && it.name != null && it.version != null) {                return it            }            return null        }        .each {            ...            dependenciesMap.put("${it.group}:${it.name}", it)        }    return dependenciesMap}//拼接pom文件def pomGenerate(XmlProvider xp) {    def dependenciesMap = [:]    dependenciesMap.putAll(ascribeDependencies("implementation"))    dependenciesMap.putAll(ascribeDependencies("api"))    ...        // 添加節(jié)點(diǎn)的閉包        def addDependencyNode = { rootNode, entry ->...            Dependency target = entry.value            //寫入基本依賴信息            def node = rootNode.appendNode("dependency")            node.appendNode("groupId", target.group)            node.appendNode("artifactId", target.name)            node.appendNode("version", target.version)            node.appendNode("scope", "compile")            //如果有，寫入classifier            def artifacts = target.getArtifacts()            if (!artifacts.isEmpty()) {                DependencyArtifact artifact = artifacts.first()                artifact.type && node.appendNode("type", artifact.type)                artifact.classifier && node.appendNode("classifier", artifact.classifier)            }            //如果有，寫入exclude規(guī)則            Set excludes = target.getExcludeRules()            if (!excludes.isEmpty()) {                def exclusions = node.appendNode("exclusions")                excludes.each { rule ->                    def exclusion = exclusions.appendNode("exclusion")                    rule.group && exclusion.appendNode("groupId", rule.group)                    rule.module && exclusion.appendNode("artifactId", rule.module)                }            }        }        //添加dependencies節(jié)點(diǎn)        def dependenciesNode = xp.asNode().appendNode("dependencies")        dependenciesMap.each {            addDependencyNode(dependenciesNode, it)        }}

7）其他核心Gradle腳本代碼一覽

setting入口處合并參數(shù)

//加載local.properties屬性gradle.ext.localProperties = gradle.ext.loadProperties("$rootDir/local.properties")//因?yàn)間radle版本兼容問題，startParameter.projectProperties不能注入直接注入，//類型為com.google.common.collect.ImmutableMap,需要統(tǒng)一。def inputProjectProperties = new HashMap()if (startParameter.projectProperties != null) {    for (key in startParameter.projectProperties.keySet()) {        def value = startParameter.projectProperties.get(key)        if (value != null) {            println "注入ProjectProperty >> $key :${utf(value)}"            inputProjectProperties.put(key, value)        }    }}//local property 參數(shù)注入，優(yōu)先級(jí)高于環(huán)境參數(shù)if (gradle.ext.localProperties) {    gradle.ext.localProperties.each { k, v ->        println "注入LocalProperty >> $k :${utf(v)}"        inputProjectProperties.put(k, utf(v))    }}

入口處更新全模塊信息app_bundle.json指定模塊打包類型

//解析初始模塊信息app_bundles.jsongradle.ext.appBundles = gradle.ext.getConfigJson("$rootDir/app_bundles.json")//利用輸入?yún)?shù)更新模塊信息gradle.ext.appBundles.each { bundleName, bundleInfo ->      ...        // App混合編譯打包        if (gradle.ext.sourceProjects.contains(bundleName)) {            //強(qiáng)制指定源碼編譯的模塊            bundleInfo.buildType = "lib"            bundleInfo.include = true        } else if ((!bundleInfo.required) && gradle.ext.excludeProjects.contains(bundleName)) {            //指定可移除模塊            bundleInfo.buildType = "lib"            bundleInfo.include = false        } else if (gradle.ext.versionPathConfig) {            // AAR 混合編譯，versionPath決定aar信息            def that = gradle.ext.versionPathConfig.find { item -> bundleName == item.bundleCode }            if (that) {                // AAR編譯的模塊                bundleInfo.buildType = "aar"                bundleInfo.include = true                bundleInfo.versionName = that.version            } else {                // 其他模塊                bundleInfo.buildType = "lib"                bundleInfo.include = false                if (bundleInfo.required) {                    println("Build bundle missing，bundleName:" + bundleName)                }            }        } else {            // 純?cè)创a編譯            bundleInfo.buildType = "lib"            bundleInfo.include = true        }}

在各個(gè)模塊的ext擴(kuò)展中定義統(tǒng)一的模塊依賴方法，方便修改

//ext擴(kuò)展(接口為ExtraPropertiesExtension.java)中定義統(tǒng)一方法def compileBundle(Project project, String depName = null) {    def projectName = depName ?: project.name    def dependenciesHandler = project.configurations.implementation    if (projectName != project.name) {        //指定單個(gè)模塊依賴        def findProject = project.rootProject.findProject(projectName)        if (findProject != null) {            dependenciesHandler.dependencies.add(                    project.dependencies.create(project.rootProject.project(projectName))            )            println("compileBundle direct >> ${project.name} $projectName")        } else {            println("compileBundle direct skip >> ${project.name} $projectName")        }    } else {        //傳遞模塊依賴，moduleTransitives即為解析的aar_config.json對(duì)象        if (gradle.ext.moduleTransitives != null) {            def depList = gradle.ext.moduleTransitives[projectName]            depList?.each {                def findProject = project.rootProject.findProject(it.depName)                if (it.depName != null && findProject != null) {                    dependenciesHandler.dependencies.add(                            project.dependencies.create(project.rootProject.project(it.depName))                    )                    println("compileBundle relationship >> ${projectName} ${it.depName}")                } else {                    println("compileBundle relationship skip >> ${projectName} ${it.depName}")                }            }        }    }}//模塊gradle使用處dependencies {    ...    compileBundle(project)}

3.3 改造中遇到的問題

1）同名資源沖突

模塊AAR改造的過程中，進(jìn)行了模塊依賴關(guān)系的調(diào)整，導(dǎo)致同名資源的覆蓋關(guān)系發(fā)生了改變。如果多個(gè) AAR 庫(kù)之間發(fā)生沖突，系統(tǒng)會(huì)使用依賴項(xiàng)列表中首先列出的庫(kù)（靠近dependencies塊頂部）中的資源。同名資源沖突會(huì)導(dǎo)致兩種結(jié)果：

File資源的沖突導(dǎo)致在運(yùn)行時(shí)會(huì)因?yàn)橥Y源中 id 找不到而 crash。Value資源的沖突導(dǎo)致 UI 不符合預(yù)期。

要解決這個(gè)問題，首先需要了解 Android 的資源打包流程，如圖所示：

圖7：android資源打包流程

Android 資源打包工具 aapt 在編譯和打包資源的過程中，會(huì)對(duì)非 assets 資源做如下處理：

賦予每一個(gè)非 assets 資源一個(gè)ID值，這些ID值以常量的形式定義在一個(gè) R.java 文件中生成一個(gè) resources.arsc 文件，用來(lái)描述那些具有ID值的資源的配置信息，它的內(nèi)容就相當(dāng)于是一個(gè)資源索引表

資源索引表對(duì)同名的資源只會(huì)生成一個(gè)id，因此項(xiàng)目中如果有同名的資源，構(gòu)建工具會(huì)根據(jù)以下優(yōu)先級(jí)順序（左側(cè)的優(yōu)先級(jí)最高）選擇要保留的版本：

圖8：同名資源合并優(yōu)先級(jí)

為了避免常用的資源 ID 發(fā)生資源沖突，主要方案有兩種：

使用對(duì)模塊具有唯一性（或在所有項(xiàng)目模塊之間具有唯一性）的前綴命名其他一致的命名方案

但是實(shí)際操作下來(lái)，發(fā)現(xiàn)還是存在幾個(gè)問題：

一是如何找出沖突的資源進(jìn)行重命名處理二是對(duì)什么樣的同名資源處理三方庫(kù)和三方庫(kù)中的資源沖突該怎么辦

為了解決這些問題，我們使用了CheckResourceConflict開源插件，原理是對(duì)工程做一個(gè)掃描，使用BaseVariantImpl.allRawAndroidResources.files接口可以在編譯期間獲取到所有的資源文件，然后檢測(cè)同名資源并分類輸出到一個(gè)可視化的html文件中，如圖：

圖9：同名資源沖突的分析

現(xiàn)在，我們可以看到哪些資源有重復(fù)以及重復(fù)資源所在的位置，可以用唯一性命名來(lái)解決同名資源沖突的問題了。

針對(duì)第二個(gè)問題，如果是布局 ID 相差較大的File資源和會(huì)影響UI展示的 value 資源可通過唯一性命名來(lái)解決沖突；對(duì)于雖然同名但內(nèi)容相同的資源可記錄不做處理。

第三個(gè)問題較為復(fù)雜，如果同名資源相差較大，可以考慮源碼的方式引入，或者直接在變體中覆蓋。

2）aar發(fā)布相關(guān)

將模塊源碼發(fā)布成遠(yuǎn)程aar需要注意不能混淆aar的代碼，否則開發(fā)階段依賴aar時(shí)不能識(shí)別其中的代碼，混淆階段放在app打包階段即可。

3）依賴替換中依賴標(biāo)記不可添加classifier ,否則會(huì)拋出UnsupportedNotationException

dependencySubstitution聲明的module依賴標(biāo)記只能有g(shù)roupId,artifactId,version這三者，如果多于或者少于3，會(huì)直接拋出不支持的標(biāo)記異常，拋出異常的標(biāo)記轉(zhuǎn)換類為ModuleSelectorStringNotationConverter

//ModuleSelectorStringNotationConverter.java@Overrideprotected ComponentSelector parseType(String notation) {    ...    String[] split = notation.split(":");    if (split.length < 2 || split.length > 3) {        throw new UnsupportedNotationException(notation);    }    ...    return DefaultModuleComponentSelector.newSelector(moduleIdentifierFactory.module(group, name), DefaultImmutableVersionConstraint.of(version));}

4）在應(yīng)用依賴替換規(guī)則后遇到的 java.lang.StackOverflowError

此處用到的依賴替換規(guī)則為用模塊標(biāo)記替換項(xiàng)目依賴。官網(wǎng)介紹在大型的多項(xiàng)目構(gòu)建中，這個(gè)規(guī)則允許項(xiàng)目依賴的子集是從倉(cāng)庫(kù)中下載而不是構(gòu)建項(xiàng)目，對(duì)加速開發(fā)效率是很有用的；被替換的project必須在setting文件中被include，且為了去解析依賴配置，構(gòu)建被替換依賴項(xiàng)的任務(wù)將不會(huì)執(zhí)行。

意思是被替換的project中的任務(wù)將不會(huì)執(zhí)行，然而實(shí)際操作中，被替換Project的 dependencies 閉包中 api 動(dòng)態(tài)方法會(huì)導(dǎo)致StackOverflowError異常,如果用implementation會(huì)導(dǎo)致Could not find method xxx on object DefaultDependencyHandler編譯異常。

為了查找原因和對(duì)Gradle有個(gè)形象的認(rèn)知，當(dāng)我們分析了 Gradle 依賴過程會(huì)發(fā)現(xiàn):

Gradle 存在一個(gè)ServiceRegistry的注冊(cè)中心, 且 封裝了一系列類似于JavaSpi機(jī)制的Services類，其中一個(gè)DependencyServices類提供了DependencyFactory依賴工廠的構(gòu)建方法；默認(rèn)的DependencyFactory工廠實(shí)現(xiàn)類，包含通過靜態(tài)工廠方法創(chuàng)建的DependencyNotationParser對(duì)象,其中組裝了我們常用的StringNotation和ProjectNotation,返回一個(gè)組合的標(biāo)記解析類NotationParser;

- 我們常用的group:artifact:version即為StringNotation；而project(":xxx")即為ProjectNotation;

當(dāng)我們通過 api或implement 聲明依賴時(shí)，實(shí)際上是通過Project中的DependencyHandler對(duì)象來(lái)進(jìn)行處理的，這個(gè)對(duì)象就是ServiceRegistry提供的，這就和 DependencyServices 等功能類建立了聯(lián)系；DependencyHandler 類中并沒有 implement和api 方法，因?yàn)镚roovy是一個(gè)動(dòng)態(tài)語(yǔ)言，允許運(yùn)行時(shí)去catch未定義方法的調(diào)用。我們只需知道如果遇到這種找不到的方法會(huì)交給此類中的DynamicAddDependencyMethods對(duì)象去處理，最終會(huì)使用 DependencyNotationParser 中構(gòu)建的標(biāo)記解析類去解析。

至此，上述報(bào)錯(cuò)的原因很有可能是因?yàn)橐蕾囂鎿Q之后，改變了原本的DependencyHandler和NotationParser的聯(lián)系,導(dǎo)致原本正確的動(dòng)態(tài)方法在替換后的功能類中找不到對(duì)應(yīng)的方法或重復(fù)動(dòng)態(tài)方法調(diào)用棧出錯(cuò)。因此需要對(duì)模塊 Gradle 邏輯做一個(gè)跳過處理，不進(jìn)入project的腳本邏輯。類似于：

//提供方法跳過替換后的模塊gradle邏輯def isSubstitute() {    return gradle.ext.subsitituteMap.containsKey(":${project.name}".toString())}

5）aar 自動(dòng)化構(gòu)建方案的選擇

就構(gòu)建這塊來(lái)說(shuō)，aar編譯方式相比于之前，需要構(gòu)建的模塊大大增加，以前不管代碼改動(dòng)多少，只需要構(gòu)建工程模塊即可；現(xiàn)在如果改動(dòng)了模塊的代碼，需要先構(gòu)建所有有變動(dòng)的模塊，在這些模塊構(gòu)建完成之后才能構(gòu)建主包。如果這個(gè)過程全部由人手動(dòng)來(lái)控制和觸發(fā)，其繁瑣程度不言而喻。

于是我們使用了webhook來(lái)實(shí)現(xiàn)自動(dòng)化構(gòu)建，在代碼 commit 的時(shí)候觸發(fā)相應(yīng)的 webhook，來(lái)通知打包服務(wù)器執(zhí)行自動(dòng)構(gòu)建的流程，打包服務(wù)器在接受到請(qǐng)求以后，先分析出發(fā)生改動(dòng)的模塊是哪些，然后構(gòu)建變動(dòng)模塊的依賴樹，從依賴樹的底層開始從下而上觸發(fā)模塊構(gòu)建，最后打包完成后通知相關(guān)人員。這樣一來(lái)，開發(fā)只需提交下代碼，剩下的就交給機(jī)器去做了。

圖10：自動(dòng)化構(gòu)建示意圖

但也因此出現(xiàn)了aar自動(dòng)化的兩種方案：

提交并同時(shí)構(gòu)建所有的aar；此種方案優(yōu)點(diǎn)是發(fā)布aar迅速，但因aar依賴順序問題會(huì)出現(xiàn)打包失敗，此時(shí)只能再打一次包解決此問題；提交并按依賴順序構(gòu)建aar；此種方案能解決打包失敗的問題，但總的aar發(fā)布時(shí)間緩慢，導(dǎo)致整個(gè)打包流程的時(shí)間劇增，特定情況下會(huì)大幅超過源碼構(gòu)建時(shí)間。此種情況可對(duì)模塊進(jìn)行細(xì)粒度的拆分，減少開發(fā)業(yè)務(wù)時(shí)頻繁的進(jìn)行aar模塊的傳遞性打包。

一般來(lái)說(shuō)，對(duì)于不經(jīng)常變動(dòng)的模塊使用方案一，對(duì)于業(yè)務(wù)改動(dòng)頻繁的模塊使用方案二。

6）構(gòu)建過程的特征化標(biāo)記或資源應(yīng)放在App殼中

一般 CI/CD 系統(tǒng)中對(duì)構(gòu)建的安裝包都有特征標(biāo)記和資源注入，這些過程都應(yīng)該放在app殼的Gradle腳本中，否則會(huì)出現(xiàn)資源不及時(shí)更新的問題。舉個(gè)例子：

問題描述：測(cè)試的時(shí)候發(fā)現(xiàn)，aar模式打的包拉不到新發(fā)布的rn。對(duì)打出來(lái)包進(jìn)行分析后發(fā)現(xiàn)，包內(nèi)的rn是工程里的原始rn，版本很老，服務(wù)那邊無(wú)法識(shí)別這么老的版本，導(dǎo)致rn增量下發(fā)失敗。

原因：gradle腳本下載rn資源的目錄為模塊aar的assets目錄，因此在aar模式下，總包rn的版本取決于模塊aar中的rn版本，而發(fā)布模塊aar打包腳本未更新rn,導(dǎo)致使用的rn為舊版。示意圖如下。

解決方案：修改下載rn資源的目錄為app殼的assets目錄，避免aar發(fā)布階段處理需要即時(shí)更新的邏輯。類似的問題還有AndroidMainifest清單文件中使用gradle參數(shù)，需要即時(shí)更新的資源或者參數(shù)需要放于app殼中執(zhí)行，保證其實(shí)時(shí)性。

圖11：動(dòng)態(tài)資源未更新示意圖

3.4 其他優(yōu)化

1）IDE插件的開發(fā)

為了方便開發(fā)同學(xué)本地開發(fā)時(shí)能夠靈活的進(jìn)行 aar/源碼 的切換，我們引入了一個(gè)有圖形化界面的AS插件?；驹硎歉鶕?jù)項(xiàng)目中的 json配置文件可視化的展示項(xiàng)目中的所有模塊，提供拖拽的功能方便模塊類型的變換，保存時(shí)改變本地的local.properties文件，達(dá)到控制參數(shù)的目的。

另外，也可定制參數(shù)化打包，因?yàn)闇y(cè)試階段需要頻繁出包，這時(shí)如果要等aar包發(fā)布在打總包整個(gè)流程會(huì)變長(zhǎng)，所以傳入sourceProject參數(shù)指定源碼模塊的參數(shù)化打包在測(cè)試階段尤為重要。

圖12：AS插件靈活切換AAR/源碼

3.5 結(jié)果一覽

經(jīng)過如上所述的改造后，對(duì)基于模塊aar方案的編譯時(shí)間進(jìn)行統(tǒng)計(jì)。統(tǒng)計(jì)基于本地機(jī)器的干凈編譯時(shí)間，可得到比較精確的打包時(shí)間。

1）本地機(jī)器干凈編譯時(shí)間統(tǒng)計(jì)

操作步驟：

開始第一次編譯

– as 進(jìn)行一次 invalidate cache 清除緩存 + 進(jìn)行一次 clean project

– 執(zhí)行干凈編譯保證所有task都會(huì)執(zhí)行g(shù)radlew--profile--offline--rerun-tasks assembleXXFlavorRelease

開始第二次編譯

– as 進(jìn)行一次 clean project

– 執(zhí)行干凈編譯保證所有task都會(huì)執(zhí)行g(shù)radlew--profile--offline--rerun-tasks assembleXXFlavorRelease

測(cè)試結(jié)果對(duì)照表：

表1：干凈編譯耗時(shí)統(tǒng)計(jì)表

表2：干凈編譯耗時(shí)對(duì)比

結(jié)果如上圖表所示，可直觀的得出結(jié)論：

本地電腦測(cè)試去除干擾項(xiàng)后，第一次構(gòu)建源碼平均耗時(shí)為 8m47s，aar平均耗時(shí)為 4m24s, 總包時(shí)間縮減率為 50%；第二次構(gòu)建源碼平均耗時(shí)為 5m50s，aar平均耗時(shí)為 3m15s，總包時(shí)間縮減率為 44%。

綜上，對(duì)基于模塊AAR的編譯優(yōu)化方案可得出如下結(jié)論：

從總包構(gòu)建時(shí)間上來(lái)看，通過模塊AAR方案改造后 release 總包時(shí)間縮減率可達(dá)50%左右，時(shí)間縮減明顯。開發(fā)階段關(guān)閉transform等耗時(shí)操作且支持部分模塊以AAR引入，編譯時(shí)間會(huì)進(jìn)一步縮減，可有效提高開發(fā)效率。但從整個(gè)流程上來(lái)看，打包流程從傳統(tǒng)的源碼構(gòu)建分成了發(fā)布aar和構(gòu)建aar總包兩部分。其中發(fā)布aar的平均時(shí)間為2m左右，如果發(fā)布一個(gè)aar后再打總包，此時(shí)整個(gè)打包流程的時(shí)間縮減率在13%~27%之間，而自動(dòng)化的aar打包會(huì)有依賴問題，存在多個(gè)aar順序打包后再打總包的情況，故整個(gè)流程上的時(shí)間縮減并不明顯并大有可能會(huì)超過源碼編譯時(shí)間。四、總結(jié)與展望

本次主要對(duì)項(xiàng)目的工程結(jié)構(gòu)和 gradle 腳本進(jìn)行一定的優(yōu)化，通過 gradle 參數(shù)支持模塊 aar/源碼 的切換，可在一定程度上提高開發(fā)的效率，全aar下可節(jié)省出包時(shí)間，同時(shí)模塊化也是其他優(yōu)化方案的基礎(chǔ)。

通過對(duì)項(xiàng)目進(jìn)行模塊aar的改造后，編譯速度上收益明顯，尤其通過as插件可視化的切換更增加了開發(fā)的靈活度，開發(fā)階段不用長(zhǎng)時(shí)間的等待編譯完成。為了保持較快的編譯速度，后續(xù)還可以做到以下幾點(diǎn)：

項(xiàng)目在保持良好的工程結(jié)構(gòu)的同時(shí)，對(duì)業(yè)務(wù)模塊進(jìn)行適當(dāng)粒度的拆分，可以讓項(xiàng)目結(jié)構(gòu)更清晰，更加有利于項(xiàng)目的更新；可對(duì)高耗時(shí)的task，如 dexBuilder，單獨(dú)做優(yōu)化；添加工程構(gòu)建監(jiān)控機(jī)制，及時(shí)對(duì)編譯過程分析和處理；

關(guān)鍵詞：