快捷導(dǎo)航

使用Composing?builds提升Android編譯速度

更新時間：2022年06月22日 16:15:27 作者：程序員DHL

這篇文章主要介紹了使用Composing?builds提升Android編譯速度示例詳解，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

前言

長期以來困擾我們的一個問題就是構(gòu)建速度，AndroidStudio 的構(gòu)建速度嚴(yán)重影響 Android 開發(fā)者的工作效率，尤其是更新一個版本號，導(dǎo)致整個項(xiàng)目重新構(gòu)建，在網(wǎng)絡(luò)慢的情況下，這是無法忍受的。

buildSrc 這種方式，在最近幾年是非常流行的，因?yàn)樗幸韵聝?yōu)點(diǎn)：

共享 buildSrc 庫工件的引用，全局只有一個地方可以修改它

支持 AndroidStudio 自動補(bǔ)全

支持 AndroidStudio 單擊跳轉(zhuǎn)

有優(yōu)點(diǎn)的同時也有缺點(diǎn)，來看一下 Gradle 文檔

A change in buildSrc causes the whole project to become out-of-date. Thus, when making small incremental changes, the --no-rebuild command-line option is often helpful to get faster feedback. Remember to run a full build regularly or at least when you’re done, though.

buildSrc的更改會導(dǎo)致整個項(xiàng)目過時，因此，在進(jìn)行小的增量更改時，-- --no-rebuild命令行選項(xiàng)通常有助于獲得更快的反饋。不過，請記住要定期或至少在完成后運(yùn)行完整版本。

匯總一句話就是說，buildSrc 依賴更新將重新構(gòu)建整個項(xiàng)目，那么有沒有一種方法支持自動補(bǔ)全和單擊跳轉(zhuǎn)，有不用重新構(gòu)建整個項(xiàng)目，Composing builds 就可以實(shí)現(xiàn)，接下來我們來演示一下 buildSrc 和 Composing builds 它們的 build 的時間，相關(guān)代碼我已經(jīng)上傳到 GitHub 了：ComposingBuilds-vs-buildSrc

通過這篇文章你將學(xué)習(xí)到以下內(nèi)容，將在文末總結(jié)部分會給出相應(yīng)的答案

什么是 buildSrc？
什么是 Composing builds？
如何使用 Composing builds 和 buildSrc
buildSrc 和 Composing builds 優(yōu)勢劣勢對比？
Composing builds 編譯速度怎么樣？
buildSrc 如何遷移到 Composing builds？
管理 Gradle 依賴都有那幾種方式？以及效率怎么樣？

這篇文章涉及很多重要的知識點(diǎn)，請耐心讀下去，我相信應(yīng)該會給大家?guī)砗芏嗖灰粯拥臇|西。

Composing builds 和 buildSrc 對比

接下來我們來演示一下 buildSrc 和 Composing builds 它們的優(yōu)勢劣勢對比，在分析之前，先來了解一下基本概念

什么是 buildSrc

摘自 Gradle 文檔：當(dāng)運(yùn)行 Gradle 時會檢查項(xiàng)目中是否存在一個名為 buildSrc 的目錄。然后 Gradle 會自動編譯并測試這段代碼，并將其放入構(gòu)建腳本的類路徑中, 對于多項(xiàng)目構(gòu)建，只能有一個 buildSrc 目錄，該目錄必須位于根項(xiàng)目目錄中, buildSrc 是 Gradle 項(xiàng)目根目錄下的一個目錄，它可以包含我們的構(gòu)建邏輯，與腳本插件相比，buildSrc 應(yīng)該是首選，因?yàn)樗子诰S護(hù)、重構(gòu)和測試代碼

什么是 Composing builds

摘自 Gradle 文檔：復(fù)合構(gòu)建只是包含其他構(gòu)建的構(gòu)建. 在許多方面，復(fù)合構(gòu)建類似于 Gradle 多項(xiàng)目構(gòu)建，不同之處在于，它包括完整的 builds ，而不是包含單個 projects

組合通常獨(dú)立開發(fā)的構(gòu)建，例如，在應(yīng)用程序使用的庫中嘗試錯誤修復(fù)時
將大型的多項(xiàng)目構(gòu)建分解為更小，更孤立的塊，可以根據(jù)需要獨(dú)立或一起工作

buildSrc vs Composing builds

為了正確對比這兩種方式，新建了兩個空的項(xiàng)目分別是 Project-buildSrc 和 Project-ComposingBuild，這兩個項(xiàng)目引用的依賴都是一樣的，Project-buildSrc 包含 buildSrc，Project-ComposingBuild 包含 Composing builds。

Project-buildSrc 和 Project-ComposingBuild 它們的結(jié)構(gòu)都差不多，接下來我們來看一下，編譯速度和使用上有什么不同。

編譯速度

Project-buildSrc 和 Project-ComposingBuild 這兩個項(xiàng)目，它們的 androidx.appcompat:appcompat 的版本是 1.0.2，現(xiàn)在我們從 1.0.2 升級到 1.1.0 來看一下它們 Build 的時間。

Project-buildSrc：修改了版本號 1.0.2 -> 1.1.0 重新 Build 用時 37s

Project-ComposingBuild：修改了版本號 1.0.2 -> 1.1.0 重新 Build 用時 8s

當(dāng)修改了版本號，Project-buildSrc 項(xiàng)目 Build 的時間幾乎是 Project-ComposingBuild 項(xiàng)目的 4.6 倍（ PS: 每個人的環(huán)境不同，時間上會有差異，但是 Project-buildSrc 的時間總是大于 Project-ComposingBuild ）

在更大的項(xiàng)目中，網(wǎng)絡(luò)慢的情況下，這種差異會更加明顯，幾分鐘的構(gòu)建都是常事，在 buildSrc 中做微小的更改，可能需要花很長時間構(gòu)建，等待團(tuán)隊(duì)其他成員在他們提取更改之后，都將導(dǎo)致項(xiàng)目重新構(gòu)建，這個代價是非常昂貴的。

它們在使用上有什么不同呢

Project-buildSrc

在項(xiàng)目根目錄下新建一個名為 buildSrc 的文件夾( 名字必須是 buildSrc，因?yàn)檫\(yùn)行 Gradle 時會檢查項(xiàng)目中是否存在一個名為 buildSrc 的目錄 )
在 buildSrc 文件夾里創(chuàng)建名為 build.gradle.kts 的文件，添加以下內(nèi)容

plugins {
    `kotlin-dsl`
}
repositories{
    jcenter()
}

在 buildSrc/src/main/java/包名/ 目錄下新建 Deps.kt 文件，添加以下內(nèi)容

object Versions {
    ......
    val appcompat = "1.1.0"
    ......
}
object Deps {
    ......
    val appcompat =  "androidx.appcompat:appcompat:${Versions.appcompat}"
    ......
}

重啟你的 Android Studio，項(xiàng)目里就會多出一個名為 buildSrc 的 module，實(shí)現(xiàn)上面演示的效果

Project-ComposingBuild

新建的 module 名稱 versionPlugin
在 versionPlugin 文件夾下的 build.gradle 文件內(nèi)，添加以下內(nèi)容

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        // 因?yàn)槭褂玫?Kotlin 需要需要添加 Kotlin 插件
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.72"
    }
}
apply plugin: 'kotlin'
apply plugin: 'java-gradle-plugin'
repositories {
    // 需要添加 jcenter 否則會提示找不到 gradlePlugin
    jcenter()
}
gradlePlugin {
    plugins {
        version {
            // 在 app 模塊需要通過 id 引用這個插件
            id = 'com.hi.dhl.plugin'
            // 實(shí)現(xiàn)這個插件的類的路徑
            implementationClass = 'com.hi.dhl.plugin.Deps'
        }
    }
}

在 versionPlugin/src/main/java/包名/ 目錄下新建 Deps.kt 文件，添加以下內(nèi)容

class Deps : Plugin<Project> {
    override fun apply(project: Project) {
    }
    companion object {
        val appcompat = "androidx.appcompat:appcompat:1.1.0"
    }
}

在 settings.gradle 文件內(nèi)添加 includeBuild 'versionPlugin' 重啟你的 Android Studio

在 app 模塊 build.gradle 文件內(nèi)首行添加以下內(nèi)容，就可以實(shí)現(xiàn)上面演示的效果

plugins{
    // 這個 id 就是在 versionPlugin 文件夾下 build.gradle 文件內(nèi)定義的 id
    id "com.hi.dhl.plugin"
}

ps：plugins{} 需要放在 app 模塊 build.gradle 文件內(nèi)首行位置

Project-ComposingBuild 比 Project-buildSrc 多了兩步操作需要在 settings.gradle 和 build.gradle 引入插件，兩者在使用都是差不多的

如何快速使用 buildSrc

訪問 ComposingBuilds-vs-buildSrc 拷貝 buildSrc 文件夾到你的項(xiàng)目的根目錄
重啟你的 Android Studio，項(xiàng)目里就會多出一個名為 buildSrc 的 module

如何快速使用 Composing builds

訪問 ComposingBuilds-vs-buildSrc 拷貝 versionPlugin 文件夾到你的項(xiàng)目的根目錄
按照上面的配置方式，分配在 settings.gradle 和 app 模塊的 build.gradle 引用插件即可

總結(jié)

總共從以下幾個方面對比了 Composing builds 和 buildSrc

目錄結(jié)構(gòu)：它們的基本目錄結(jié)構(gòu)是相同的，可以根據(jù)自己的項(xiàng)目進(jìn)行不同的擴(kuò)展
編譯速度：當(dāng)修改了版本號，Project-buildSrc 項(xiàng)目 Build 的時間幾乎是 Project-ComposingBuild 項(xiàng)目的 4.6 倍（ PS: 每個人的環(huán)境不同，時間上會有差異，但是 Project-buildSrc 的時間總是大于 Project-ComposingBuild ）
使用上的區(qū)別：Composing builds 比 buildSrc 多了兩步操作需要在 settings.gradle 和 build.gradle 引入插件

Project-buildSrc 和 Project-ComposingBuild 相關(guān)代碼已經(jīng)上傳到 GitHub 了：ComposingBuilds-vs-buildSrc

到目前為止大概管理 Gradle 依賴提供了 4 種不同方法：