改善 Gradle 建置效能 - Gradle 繁體中文

建置效能對於生產力至關重要。建置完成所需時間越長，越有可能中斷您的開發流程。建置每天執行多次，因此即使是短暫的等待時間也會累積。持續整合 (CI) 建置也是如此：花費的時間越少，您就能越快對新問題做出反應，並且可以更頻繁地進行實驗。

這一切都表示值得花費一些時間和精力，讓您的建置盡可能快速。本節提供多種方法來加快建置速度。此外，您還會找到導致建置效能下降的原因以及如何避免這些原因的詳細資訊。

想要更快的 Gradle 建置嗎？在此註冊我們的建置快取訓練課程，瞭解 Develocity 如何將建置速度提升多達 90%。

檢查您的建置

在進行任何變更之前，請使用建置掃描或設定檔報告檢查您的建置。適當的建置檢查有助於您瞭解

建置專案所需的時間
建置中哪些部分較慢

檢查提供一個比較點，以便更了解此頁面建議的變更所造成的影響。

最佳使用此頁面的方式

檢查您的組建。
進行變更。
再次檢查您的組建。

如果變更改善了組建時間，請將其設為永久。如果您沒有看到改善，請移除變更並嘗試其他變更。

更新版本

Gradle

Gradle 團隊持續改善 Gradle 組建的效能。如果您使用的是舊版本的 Gradle，您將錯失這項工作的優點。持續更新 Gradle 版本升級的風險很低，因為 Gradle 團隊確保 Gradle 次要版本之間的向下相容性。保持最新狀態也會讓轉換到下一個主要版本更容易，因為您會及早收到不建議使用的警告。

Java

Gradle 在 Java 虛擬機器 (JVM) 上執行。Java 效能改善通常會對 Gradle 有利。若要獲得最佳的 Gradle 效能，請使用最新版本的 Java。

外掛程式

外掛程式撰寫者持續改善其外掛程式的效能。如果您使用的是舊版本的外掛程式，您將錯失這項工作的優點。尤其是 Android、Java 和 Kotlin 外掛程式會對組建效能造成重大影響。更新到這些外掛程式的最新版本以改善效能。

啟用平行執行

大多數專案包含多個子專案。通常，其中一些子專案彼此獨立；也就是說，它們不共用狀態。然而，Gradle 預設一次只執行一個工作。若要平行執行屬於不同子專案的工作，請使用 parallel 旗標

$ gradle <task> --parallel

若要預設平行執行專案工作，請將下列設定新增到專案根目錄或 Gradle 首頁中的 gradle.properties 檔案

gradle.properties

org.gradle.parallel=true

平行組建可以大幅改善組建時間；改善幅度取決於您的專案結構以及您在子專案之間有多少相依性。執行時間主要取決於單一子專案的組建不會有太多改善。有許多跨子專案相依性的專案也不會改善。但大多數多子專案組建會看到組建時間縮短。

使用建置掃描視覺化平行處理

建置掃描會提供任務執行時間軸的視覺化。在以下範例建置中，您可以在建置的開始和結束看到長時間執行的任務

圖 1. 平行執行中的瓶頸

調整建置設定，讓兩個緩慢的任務在早期並行執行，可將整體建置時間從 8 秒縮短至 5 秒

圖 2. 最佳化的平行執行

重新啟用 Gradle Daemon

Gradle Daemon 可透過以下方式縮短建置時間

在建置之間快取專案資訊
在背景中執行，因此每個 Gradle 建置不用等待 JVM 啟動
受益於 JVM 中持續的執行時間最佳化
監控檔案系統，以在執行建置之前精確計算需要重新建置的內容

Gradle 預設會啟用 Daemon，但有些建置會覆寫此偏好設定。如果您的建置停用 Daemon，啟用 Daemon 可以大幅提升效能。

您可以在建置時使用 daemon 旗標啟用 Daemon

$ gradle <task> --daemon

要在較舊的 Gradle 版本中預設啟用 Daemon，請將下列設定新增至專案根目錄或 Gradle 首頁的 gradle.properties 檔案

gradle.properties

org.gradle.daemon=true

在開發人員電腦上，您應該會看到大幅的效能提升。在 CI 電腦上，長駐代理程式會受益於 Daemon。但短暫的電腦不會受益太多。在 Gradle 3.0 以上版本中，Daemon 會在記憶體壓力下自動關閉，因此永遠可以安全地保持 Daemon 啟用。

啟用設定快取

此功能有下列限制

設定快取不支援所有核心 Gradle 外掛和功能。完整的支援仍在進行中。
您的建置和您依賴的外掛可能需要變更才能符合需求。
IDE 匯入和同步不會使用設定快取。

您可以透過啟用設定快取來快取設定階段的結果。當建置設定輸入在建置之間保持不變時，設定快取會讓 Gradle 完全略過設定階段。

建置設定輸入包括

初始化指令碼
設定指令碼
建置指令碼
組態階段使用的系統屬性
組態階段使用的 Gradle 屬性
組態階段使用的環境變數
使用值供應器（例如提供者）存取的組態檔案
buildSrc 輸入，包括建置組態輸入和原始檔

預設情況下，Gradle 不會使用組態快取。若要在建置時啟用組態快取，請使用 configuration-cache 旗標

$ gradle <task> --configuration-cache

若要預設啟用組態快取，請將下列設定新增至專案根目錄或 Gradle 首頁中的 gradle.properties 檔案

gradle.properties

org.gradle.configuration-cache=true

如需有關組態快取的更多資訊，請查看組態快取文件。

其他組態快取優點

組態快取也提供其他優點。啟用時，Gradle 會

平行執行所有工作，即使它們在同一個子專案中。
快取相依性解析結果。

為自訂工作啟用增量建置

增量建置是 Gradle 的最佳化，會略過先前使用相同輸入執行的工作。如果工作的輸入和輸出自上次執行後沒有變更，Gradle 會略過該工作。

Gradle 提供的大部分內建工作都適用於增量建置。若要讓自訂工作相容於增量建置，請指定輸入和輸出

build.gradle.kts

tasks.register("processTemplatesAdHoc") {
    inputs.property("engine", TemplateEngineType.FREEMARKER)
    inputs.files(fileTree("src/templates"))
        .withPropertyName("sourceFiles")
        .withPathSensitivity(PathSensitivity.RELATIVE)
    inputs.property("templateData.name", "docs")
    inputs.property("templateData.variables", mapOf("year" to "2013"))
    outputs.dir(layout.buildDirectory.dir("genOutput2"))
        .withPropertyName("outputDir")

    doLast {
        // Process the templates here
    }
}

build.gradle

tasks.register('processTemplatesAdHoc') {
    inputs.property('engine', TemplateEngineType.FREEMARKER)
    inputs.files(fileTree('src/templates'))
        .withPropertyName('sourceFiles')
        .withPathSensitivity(PathSensitivity.RELATIVE)
    inputs.property('templateData.name', 'docs')
    inputs.property('templateData.variables', [year: '2013'])
    outputs.dir(layout.buildDirectory.dir('genOutput2'))
        .withPropertyName('outputDir')

    doLast {
        // Process the templates here
    }
}

如需有關增量建置的更多資訊，請查看增量建置文件。

使用建置掃描時間軸視覺化增量建置

查看建置掃描時間軸檢視，以找出可從增量建置中受益的工作。這也可以幫助您了解在您期望 Gradle 略過工作時，工作為何會執行。

圖 3. 時間軸檢視有助於增量建置檢查

如您在上述建置掃描中所見，工作並非最新，因為其中一個輸入（「時間戳記」）已變更，導致工作必須重新執行。

依據持續時間排序工作，以找出專案中最慢的工作。

啟用建置快取

建置快取是 Gradle 的最佳化，會儲存特定輸入的工作輸出。當您稍後使用相同輸入執行同一工作時，Gradle 會從建置快取中擷取輸出，而不是再次執行工作。預設情況下，Gradle 不會使用建置快取。若要在建置時啟用建置快取，請使用 build-cache 旗標

$ gradle <task> --build-cache

如要預設啟用建置快取，請將下列設定新增至專案根目錄或 Gradle 首頁中的 gradle.properties 檔案

gradle.properties

org.gradle.caching=true

您可以使用本機建置快取來加速單一電腦上的重複建置。您也可以使用共用建置快取來加速多台電腦上的重複建置。Develocity 提供一個。共用建置快取可以縮短 CI 和開發人員建置的建置時間。

如需建置快取的更多資訊，請查看建置快取文件。

使用建置掃描視覺化建置快取

建置掃描可以協助您調查建置快取的效能。在效能畫面中，「建置快取」索引標籤會顯示下列統計資料

有多少工作與快取互動
使用哪一個快取
這些快取條目的傳輸和封裝/解封裝比率

圖 4. 檢查建置的建置快取效能

「工作執行」索引標籤會顯示工作快取性的詳細資料。按一下類別，即可看到強調該類別工作的時間軸畫面。

圖 5. 以工作為導向的效能檢視

圖 6. 僅顯示「不可快取」工作的時間軸畫面

在時間軸畫面中依工作持續時間排序，以強調具有大幅節省時間潛力的工作。上述建置掃描顯示 :task1 和 :task3 可以改善並變成可快取，並顯示 Gradle 未快取它們的原因。

為特定開發人員工作流程建立建置

最快的任務是不執行的任務。如果您能找到略過不需要執行的任務的方法，您最終將會得到整體更快的建置。

如果您的建置包括多個子專案，請建立工作來獨立建置這些子專案。這有助於您充分利用快取，因為變更一個子專案不會強制重建不相關的子專案。這也有助於縮短處理不相關子專案的團隊的建置時間：前端開發人員無需在每次變更前端時建置後端子專案。文件撰寫人員無需建置前端或後端程式碼，即使文件與該程式碼位於同一個專案中。

相反地，建立符合開發人員需求的任務。你仍然會有一個針對整個專案的單一任務圖表。每一組使用者建議任務圖表的受限檢視：將該檢視轉換為排除不必要任務的 Gradle 工作流程。

Gradle 提供了幾個功能來建立這些工作流程

將任務指定給適當的群組
建立彙總任務：沒有動作且僅依賴於其他任務的任務，例如 assemble
透過 gradle.taskGraph.whenReady() 和其他方式延後設定，以便你僅在必要時執行驗證

增加堆積大小

預設情況下，Gradle 會為你的建置保留 512MB 堆積空間。這對大多數專案來說已經足夠了。但是，某些非常大型的建置可能需要更多記憶體來儲存 Gradle 的模型和快取。如果是這樣的話，你可以指定更大的記憶體需求。在專案根目錄或 Gradle 主目錄中的 gradle.properties 檔案中指定下列屬性

gradle.properties

org.gradle.jvmargs=-Xmx2048M

若要深入了解，請查看 JVM 記憶體設定文件。

最佳化設定

如建置生命週期章節中所述，Gradle 建置會經歷 3 個階段：初始化、設定和執行。設定程式碼會在不論執行哪些任務的情況下執行。因此，在設定期間執行的任何昂貴工作都會減慢每次呼叫的速度。即使是像 gradle help 和 gradle tasks 這樣的簡單指令。

接下來的幾個小節介紹了可以減少在設定階段花費時間的技術。

你也可以啟用設定快取以減少慢速設定階段的影響。但是，即使是使用快取的機器偶爾也會執行你的設定階段。因此，你應該使用這些技術讓設定階段盡可能快。

避免昂貴或封鎖的工作

您應避免在組態階段進行耗時的作業。但有時會在不顯眼的地方偷偷潛入您的建置中。如果該程式碼在建置檔案中，通常在組態期間加密資料或呼叫遠端服務時會很明顯。但此類邏輯通常會在外掛程式中找到，偶爾也會在自訂任務類別中找到。外掛程式的 apply() 方法或任務的建構函式中的任何昂貴作業都是一個警訊。

僅在需要的地方套用外掛程式

套用至專案的每個外掛程式和指令碼都會增加整體組態時間。有些外掛程式的影響大於其他外掛程式。這並不表示您應避免使用外掛程式，但您應注意僅在需要的地方套用外掛程式。例如，即使並非每個專案都需要，也很容易透過 allprojects {} 或 subprojects {} 將外掛程式套用至所有子專案。

在上述建置掃描範例中，您會看到根建置指令碼將 script-a.gradle 指令碼套用至建置中的 3 個子專案

圖 7. 顯示將 script-a.gradle 套用至建置

此指令碼執行需要 1 秒。由於它套用至 3 個子專案，因此此指令碼會累計延遲組態階段 3 秒。在這種情況下，有數種方法可減少延遲

如果只有一個子專案使用指令碼，您可以從其他子專案移除指令碼套用。這會在每次 Gradle 呼叫中減少兩秒的組態延遲。
如果多個子專案（但並非全部）使用指令碼，您可以將指令碼和所有周圍邏輯重構為位於 buildSrc 中的自訂外掛程式。僅將自訂外掛程式套用至相關子專案，以減少組態延遲並避免程式碼重複。

靜態編譯任務和外掛程式

外掛程式和任務作者經常撰寫 Groovy，以取得其簡潔的語法、對 JDK 的 API 延伸，以及使用閉包的函數方法。但 Groovy 語法會帶來動態詮釋的成本。因此，Groovy 中的方法呼叫會花費更多時間，並使用比 Java 或 Kotlin 中的方法呼叫更多的 CPU。

您可以使用靜態 Groovy 編譯來降低此成本：當您不需要動態功能時，請將 @CompileStatic 註解新增至您的 Groovy 類別。如果您在方法中需要動態 Groovy，請將 @CompileDynamic 註解新增至該方法。

或者，您可以使用靜態編譯語言（例如 Java 或 Kotlin）撰寫外掛程式和任務。

警告：Gradle 的 Groovy DSL 大量依賴 Groovy 的動態功能。如要在外掛程式中使用靜態編譯，請切換為類似 Java 的語法。

下列範例定義一個複製檔案的任務，不含動態功能

src/main/groovy/MyPlugin.groovy

project.tasks.register('copyFiles', Copy) { Task t ->
    t.into(project.layout.buildDirectory.dir('output'))
    t.from(project.configurations.getByName('compile'))
}

此範例使用所有 Gradle「網域物件容器」中可用的 register() 和 getByName() 方法。網域物件容器包括任務、組態、相依性、擴充功能等等。有些集合（例如 TaskContainer）具有專用類型，並附有額外方法，例如 create，它會接受一個任務類型。

當您使用靜態編譯時，IDE 可以

快速顯示與無法辨識的類型、屬性和方法相關的錯誤
自動完成方法名稱

最佳化相依性解析

相依性解析可簡化將第三方程式庫和其他相依性整合至專案中。Gradle 會連絡遠端伺服器來找出並下載相依性。您可以最佳化您參照相依性的方式，以減少這些遠端伺服器呼叫。

避免不必要且未使用的相依性

管理第三方程式庫及其傳遞相依性會大幅增加專案維護和建置時間。

注意未使用的相依性：當一個第三方程式庫不再被使用，但並未從相依性清單中移除時。這在重構期間經常發生。您可以使用 Gradle Lint 外掛程式來找出未使用的相依性。

如果您只在第三方程式庫中使用少數方法或類別，請考慮

在您的專案中自行實作所需的程式碼
從程式庫中複製所需的程式碼（並註明出處！）如果它是開源的

最佳化儲存庫順序

當 Gradle 解析相依性時，它會依據宣告順序搜尋每個儲存庫。如要減少搜尋相依性所花的時間，請先宣告存放最多相依性的儲存庫。這會將解析所有相依性所需的網路要求次數降至最低。

將儲存庫數量降至最低

將宣告的儲存庫數量限制在建置運作所需的最低數量。

如果您使用自訂儲存庫伺服器，請建立一個虛擬儲存庫，將多個儲存庫彙整在一起。然後，只將該儲存庫新增至您的建置檔案。

將動態和快照版本降至最低

動態版本（例如「2.+」）和變更版本（快照）會強制 Gradle 連絡遠端儲存庫以尋找新版本。預設情況下，Gradle 每 24 小時只檢查一次。但您可以使用下列設定以程式方式變更這個設定

cacheDynamicVersionsFor
cacheChangingModulesFor

如果建置檔案或初始化指令碼降低這些值，Gradle 會更頻繁地查詢儲存庫。當您不需要每次建置時都使用相依項的最新版本時，請考慮移除這些設定的客製化值。

使用建置掃描尋找動態和變更的版本

您可以透過建置掃描找到所有具有動態版本的相依項

圖 8. 尋找具有動態版本的相依項

您可能可以使用「1.2」和「3.0.3.GA」等固定版本，讓 Gradle 能夠快取版本。如果您必須使用動態和變更的版本，請調整快取設定以最符合您的需求。

在組態期間避免相依項解析

相依項解析是一個昂貴的程序，無論是在 I/O 或運算方面。Gradle 透過快取來減少所需的網路流量。但仍然有成本。Gradle 在每次建置時執行組態階段。如果您在組態階段觸發相依項解析，每次建置都會付出這種代價。

切換到宣告式語法

如果您評估組態檔，您的專案會在組態期間付出相依項解析的代價。通常，由於您不需要這些檔案，直到您準備好使用工作項動作對它們進行某些操作，因此工作項會評估這些檔案。想像一下，您正在進行一些除錯，並想要顯示組成組態的檔案。若要實作此功能，您可以插入列印陳述式

build.gradle.kts

tasks.register<Copy>("copyFiles") {
    println(">> Compilation deps: ${configurations.compileClasspath.get().files.map { it.name }}")
    into(layout.buildDirectory.dir("output"))
    from(configurations.compileClasspath)
}

build.gradle

tasks.register('copyFiles', Copy) {
    println ">> Compilation deps: ${configurations.compileClasspath.files.name}"
    into(layout.buildDirectory.dir('output'))
    from(configurations.compileClasspath)
}

files 屬性會強制 Gradle 解析相依項。在此範例中，這會在組態階段發生。由於組態階段會在每次建置時執行，因此現在所有建置都會付出相依項解析的效能代價。您可以使用 doFirst() 動作來避免這種代價

build.gradle.kts

tasks.register<Copy>("copyFiles") {
    into(layout.buildDirectory.dir("output"))
    // Store the configuration into a variable because referencing the project from the task action
    // is not compatible with the configuration cache.
    val compileClasspath: FileCollection = configurations.compileClasspath.get()
    from(compileClasspath)
    doFirst {
        println(">> Compilation deps: ${compileClasspath.files.map { it.name }}")
    }
}

build.gradle

tasks.register('copyFiles', Copy) {
    into(layout.buildDirectory.dir('output'))
    // Store the configuration into a variable because referencing the project from the task action
    // is not compatible with the configuration cache.
    FileCollection compileClasspath = configurations.compileClasspath
    from(compileClasspath)
    doFirst {
        println ">> Compilation deps: ${compileClasspath.files.name}"
    }
}

請注意，from() 宣告不會解析相依項，因為您使用相依項組態本身作為引數，而不是檔案。Copy 工作項會在工作項執行期間解析組態本身。

使用建置掃描視覺化相依項解析

建置掃描效能頁面上的「相依項解析」標籤會顯示組態和執行階段期間的相依項解析時間

圖 9. 組態時間的相依性解析

建置掃描提供了另一種識別此問題的方法。您的建置應在「專案組態」期間花費 0 秒來解析相依性。此範例顯示建置在生命週期中過早解析相依性。您還可以在「效能」頁面上找到「設定和建議」標籤。這會顯示在組態階段解析的相依性。

移除或改善自訂相依性解析邏輯

Gradle 允許使用者以最適合自己的方式建模相依性解析。簡單的自訂，例如強制使用特定版本的相依性或將一個相依性替換為另一個相依性，不會對相依性解析時間造成重大影響。較複雜的自訂，例如下載和剖析 POM 的自訂邏輯，可能會大幅降低相依性解析速度。

使用建置掃描或剖析報告檢查自訂相依性解析邏輯是否對相依性解析時間造成負面影響。這可能是您自己撰寫的自訂邏輯，或可能是外掛程式的一部分。

移除緩慢或意外的相依性下載

緩慢的相依性下載可能會影響您的整體建置效能。造成此問題的原因有很多，包括網際網路連線緩慢或儲存庫伺服器過載。在建置掃描的「效能」頁面上，您會找到「網路活動」標籤。此標籤會列出包括以下資訊在內的資訊

下載相依性所花費的時間
相依性下載的傳輸速率
依下載時間排序的下載清單

在以下範例中，兩個緩慢的相依性下載花了 20 秒和 40 秒，並降低了建置的整體效能

圖 10. 識別緩慢的相依性下載

檢查下載清單是否有意外的相依性下載。例如，您可能會看到由使用動態版本的相依性所造成的下載。

切換到不同的儲存庫或相依性，以消除這些緩慢或意外的下載。

最佳化 Java 專案

下列各節僅適用於使用 java 外掛程式或其他 JVM 語言的專案。

最佳化測試

專案通常會花費大量建置時間在測試上。這些測試可能是單元測試和整合測試的組合。整合測試通常需要較長的時間。建置掃描可以協助您找出最慢的測試。然後，您可以專注於加速這些測試。

圖 11. 測試畫面，依專案顯示測試，並依持續時間排序

上述建置掃描顯示所有執行測試的專案的互動式測試報告。

Gradle 有好幾種方法可以加速測試

並行執行測試
將測試分岔到多個處理程序
停用報告

讓我們逐一檢視這些方法。

並行執行測試

Gradle 可以並行執行多個測試案例。若要啟用此功能，請覆寫相關 Test 任務中 maxParallelForks 的值。若要獲得最佳效能，請使用小於或等於可用 CPU 核心數的數字

build.gradle.kts

tasks.withType<Test>().configureEach {
    maxParallelForks = (Runtime.getRuntime().availableProcessors() / 2).coerceAtLeast(1)
}

build.gradle

tasks.withType(Test).configureEach {
    maxParallelForks = Runtime.runtime.availableProcessors().intdiv(2) ?: 1
}

並行執行的測試必須是獨立的。它們不應共用檔案或資料庫等資源。如果您的測試共用資源，它們可能會隨機且無法預測地互相干擾。

將測試分岔到多個處理程序

預設情況下，Gradle 會在單一分岔的 VM 中執行所有測試。如果測試數量很多，或某些測試會消耗大量記憶體，您的測試執行時間可能會比您預期的還要長。您可以增加堆積大小，但垃圾回收可能會讓您的測試變慢。

或者，您可以在執行一定數量的測試後，透過 forkEvery 設定分岔一個新的測試 VM

build.gradle.kts

tasks.withType<Test>().configureEach {
    forkEvery = 100
}

build.gradle

tasks.withType(Test).configureEach {
    forkEvery = 100
}

分岔 VM 是一項昂貴的操作。在此設定過小的值會讓測試變慢。

停用報告

Gradle 會自動建立測試報告，不論您是否想要檢視這些報告。產生報告會讓整體建置變慢。如果您

只關心測試是否成功（而不是原因）
使用建置掃描，它提供的資訊比本機報告更多

您可能不需要報告。若要停用測試報告，請在 Test 任務中將 reports.html.required 和 reports.junitXml.required 設定為 false

build.gradle.kts

tasks.withType<Test>().configureEach {
    reports.html.required = false
    reports.junitXml.required = false
}

build.gradle

tasks.withType(Test).configureEach {
    reports.html.required = false
    reports.junitXml.required = false
}

有條件地啟用報告

您可能想要有條件地啟用報告，這樣您就不必編輯建置檔案才能看到報告。若要根據專案屬性啟用報告，請在停用報告之前檢查屬性是否存在

build.gradle.kts

tasks.withType<Test>().configureEach {
    if (!project.hasProperty("createReports")) {
        reports.html.required = false
        reports.junitXml.required = false
    }
}

build.gradle

tasks.withType(Test).configureEach {
    if (!project.hasProperty("createReports")) {
        reports.html.required = false
        reports.junitXml.required = false
    }
}

然後，在命令列上傳遞 -PcreateReports 屬性以產生報告。

$ gradle <task> -PcreateReports

或在專案根目錄或 Gradle 首頁中的 gradle.properties 檔案中設定屬性

gradle.properties

createReports=true

最佳化編譯器

Java 編譯器很快。但是，如果您正在編譯數百個 Java 類別，即使編譯時間很短，也會累積起來。Gradle 提供了多項最佳化，以進行 Java 編譯

將編譯器執行為獨立處理程序
將內部專屬相依項切換為實作可見性

將編譯器執行為獨立處理程序

您可以使用下列設定，將編譯器執行為任何 JavaCompile 任務的獨立處理程序

build.gradle.kts

<task>.options.isFork = true

build.gradle

<task>.options.fork = true

若要將設定套用至所有 Java 編譯任務，您可以 configureEach java 編譯任務

build.gradle.kts

tasks.withType<JavaCompile>().configureEach {
    options.isFork = true
}

build.gradle

tasks.withType(JavaCompile).configureEach {
    options.fork = true
}

Gradle 會在建置期間重複使用此處理程序，因此分岔的開銷很小。透過將記憶體密集型編譯分岔到獨立處理程序，我們可以將主 Gradle 處理程序中的垃圾回收降至最低。垃圾回收次數減少表示 Gradle 的基礎架構可以執行得更快，特別是在您也使用並行建置時。

分岔編譯很少會影響小型專案的效能。但如果你有一個單一任務編譯超過一千個原始檔，你應該考慮使用分岔編譯。

將僅限內部的相依性切換到實作可視性

只有函式庫可以定義 api 相依性。使用 java-library 外掛程式在你的函式庫中定義 API 相依性。使用 java 外掛程式的專案無法宣告 api 相依性。

在 Gradle 3.4 之前，專案使用 compile 設定宣告相依性。這會將所有這些相依性公開給下游專案。在 Gradle 3.4 及以上版本中，你可以將面向下游的 api 相依性與僅限內部的 implementation 詳細資料分開。實作相依性不會外洩到下游專案的編譯類別路徑中。當實作詳細資料變更時，Gradle 只會重新編譯 api 相依性。

build.gradle.kts

dependencies {
   api(project("my-utils"))
   implementation("com.google.guava:guava:21.0")
}

build.gradle

dependencies {
   api project('my-utils')
   implementation 'com.google.guava:guava:21.0'
}

這可以大幅減少大型多專案建置中單一變更所造成的重新編譯「漣漪效應」。

改善舊版 Gradle 的效能

有些專案無法輕易升級到目前的 Gradle 版本。雖然你應該盡可能將 Gradle 升級到最新版本，但我們了解在某些特殊情況下這並不可行。在這些特定情況下，請查看這些建議來最佳化舊版 Gradle。

啟用 Daemon

Gradle 3.0 及以上版本預設啟用 Daemon。如果你使用舊版，你應該更新到最新版本的 Gradle。如果你無法更新你的 Gradle 版本，你可以手動啟用 Daemon。

使用增量編譯

Gradle 可以分析相依性到個別類別層級，以重新編譯只受變更影響的類別。Gradle 4.10 及以上版本預設啟用增量編譯。要在舊版 Gradle 中預設啟用增量編譯，請將以下設定新增到你的 build.gradle 檔案

build.gradle.kts

tasks.withType<JavaCompile>().configureEach {
    options.isIncremental = true
}

build.gradle

tasks.withType(JavaCompile).configureEach {
    options.incremental = true
}

使用編譯避免

通常，更新只會變更程式碼的內部實作詳細資料，例如方法的主體。這些更新稱為ABI 相容變更：它們不會影響專案的二進位介面。在 Gradle 3.4 及更新版本中，ABI 相容變更不再觸發下游專案的重新編譯。這特別改善了具有深度相依性鏈的大型多專案建置的建置時間。

升級到 Gradle 3.4 以上版本以受益於編譯避免。

如果您使用註解處理器，您需要明確宣告它們才能讓編譯避免運作。若要深入了解，請查看編譯避免文件。

最佳化 Android 專案

此頁面上的所有內容都適用於 Android 建置，因為 Android 建置使用 Gradle。然而，Android 引入了獨特的最佳化機會。如需更多資訊，請查看Android 團隊效能指南。您也可以觀看 Google IO 2017 的相關演講。

此頁面有幫助嗎？