較大型的專案或導入許多自訂建構邏輯的專案,您可能需要深入瞭解建構程序,以找出瓶頸。方法是剖析 Gradle 執行建構生命週期和每個建構工作各階段所需的時間長度。舉例來說,如果建構設定檔
顯示 Gradle 花費太多時間設定專案,
建議您
將自訂建構邏輯移出設定階段。
此外,如果 mergeDevDebugResources
工作耗用了大量建構時間,可能表示您必須將圖片轉換為 WebP 或 停用 PNG 壓縮功能。
如果您使用 Android Studio 4.0 或以上版本,建議您使用版本分析器調查建構效能問題。
此外,您可以透過下列兩種方式在 Android Studio 以外的位置剖析您的建構作業:
獨立的
gradle-profiler
工具,這項強大的工具可讓您深入分析建構作業。Gradle
--profile
選項,這是 Gradle 指令列提供的便利工具。
使用獨立的 gradle-profiler
工具
如要找出能提供最佳建構速度的專案設定, 建議您使用 Gradle 分析器。 這項工具,用於收集 Gradle 建構作業的剖析和基準化資訊。 Gradle 分析器可讓您建立建構情境,並執行多項 防止結果出現高落差,並確保可重現性 結果。
基準化模式 應用於收集簡潔和漸進式版本的相關資訊 在剖析模式時 可用來收集有關執行作業的詳細資訊,包括 CPU 快照
一些用於基準化專案設置設定包括:
- 外掛程式版本
- Gradle 版本
- JVM 設定 (堆積大小、permgen 大小、垃圾收集等)
- Gradle 工作站數量 (
org.gradle.workers.max
) - 多種外掛程式選項,進一步最佳化效能
開始使用
- 按照這些操作說明安裝 Gradle 分析器
- 執行:
gradle-profiler --benchmark --project-dir <root-project> :app:assembleDebug
這將對最新的建構進行基準化,因為 --benchmark
多次執行該工作,且不會在其間變更專案。這個指令會在 profile-out/
目錄下產生 HTML 報告,顯示建構時間。
還有其他場景可能對基準化更實用:
- 針對大部分作業的類別中,在方法的主體中變更程式碼。
- 可在專案中使用的模組中變更 API。少一點 比起變更自己的程式碼經常變動 這樣的效果會更大 評估時也很實用
- 透過版面配置編輯器以模擬 UI 工作的疊代。
- 字符串編輯以模擬處理翻譯工作。
- 清理建構作業,以模擬建構作業本身的變化 (例如,Android Gradle
外掛程式更新、Gradle 更新,或修改自己的建構程式碼
低於
buildSrc
)。
如要針對這些用途進行基準化,您可以建立情境以用於驅動 gradle-profiler
執行,並對來源資料進行適當變更。以下列舉一些常見的使用情境。
剖析不同的記憶體/CPU 設定
如要針對不同的記憶體和 CPU 設定進行基準化,您可以建立多種情境,讓 org.gradle.jvmargs
使用不同的值。例如,您可以建立情境:
# <root-project>/scenarios.txt
clean_build_2gb_4workers {
tasks = [":app:assembleDebug"]
gradle-args = ["--max-workers=4"]
jvm-args = ["-Xmx2048m"]
cleanup-tasks = ["clean"]
}
clean_build_parallelGC {
tasks = [":app:assembleDebug"]
jvm-args = ["-XX:+UseParallelGC"]
cleanup-tasks = ["clean"]
}
clean_build_G1GC_4gb {
tasks = [":app:assembleDebug"]
jvm-args = ["-Xmx4096m", "-XX:+UseG1GC"]
cleanup-tasks = ["clean"]
}
執行 gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt
會執行三個情境,而您可以比較 :app:assembleDebug
的每項設定所需時間。
剖析不同的 Gradle 外掛程式版本
如要瞭解變更 Gradle 外掛程式的版本對其有何影響 請建立用於基準化的情境。這需要一些準備工作,才能讓外掛程式版本可從場景植入。變更根目錄的 build.gradle:
# <root-project>/build.gradle
buildscript {
def agpVersion = providers.systemProperty("agpVersion").forUseAtConfigurationTime().orNull ?: '4.1.0'
ext.kotlin = providers.systemProperty('kotlinVersion').forUseAtConfigurationTime().orNull ?: '1.4.0'
dependencies {
classpath "com.android.tools.build:gradle:$agpVersion"
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin"
}
}
現在,您可以從情境檔案指定 Android Gradle 外掛程式和 Kotlin Gradle 外掛程式,並嘗試在來源檔案中新增方法:
# <root-project>/scenarios.txt
non_abi_change_agp4.1.0_kotlin1.4.10 {
tasks = [":app:assembleDebug"]
apply-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
"app/src/main/java/com/example/your_app/your_code_file.kt"]
System-properties {
"agpVersion" = "4.1.0"
"kotlinVersion" = "1.4.10"
}
non_abi_change_agp4.2.0_kotlin1.4.20 {
tasks = [":app:assembleDebug"]
apply-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
"app/src/main/java/com/example/your_app/your_code_file.kt"]
System-properties {
"agpVersion" = "4.2.0-alpha16"
"kotlinVersion" = "1.4.20"
}
剖析漸進式建構作業
大部分的建構作業都會逐步增加,而這是建構前最重要場景之一。Gradle 分析器有剖析漸進式建構作業的拓展支援。這項服務可以變更方法內容、新增方法或變更版面配置或字串資源,藉此自動將變更套用至來源檔案。例如,您可以建立像這樣的漸進式場景:
# <root-project>/scenarios.txt
non_abi_change {
tasks = [":app:assembleDebug"]
apply-non-abi-change-to = ["app/src/main/java/com/example/your_app/your_code_file.java,
"app/src/main/java/com/example/your_app/your_code_file.kt"]
}
abi_change {
tasks = [":app:assembleDebug"]
apply-abi-change-to = ["app/src/main/java/com/example/your_app/your_code_file.java,
"app/src/main/java/com/example/your_app/your_code_file.kt"]
}
layout_change {
tasks = [":app:assembleDebug"]
apply-android-layout-change-to = "app/src/main/res/your_layout_file.xml"
}
string_resource_change {
tasks = [":app:assembleDebug"]
apply-android-resource-value-change-to = "app/src/main/res/values/strings.xml"
}
執行 gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt
時,系統會產生包含基準化資料的 HTML 報表。
您可以將漸進式場景與其他設定結合,例如堆積大小、工作站數量或 Gradle 版本:
# <root-project>/scenarios.txt
non_abi_change_4g {
tasks = [":app:assembleDebug"]
apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
"app/src/main/java/com/example/your_app/your_code_file.kt"]
jvm-args = ["-Xmx4096m"]
}
non_abi_change_4g_8workers {
tasks = [":app:assembleDebug"]
apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
"app/src/main/java/com/example/your_app/your_code_file.kt"]
jvm-args = ["-Xmx4096m"]
gradle-args = ["--max-workers=8"]
}
non_abi_change_3g_gradle67 {
tasks = [":app:assembleDebug"]
apply-non-abi-change-to ["app/src/main/java/com/example/your_app/your_code_file.java,
"app/src/main/java/com/example/your_app/your_code_file.kt"]
jvm-args = ["-Xmx3072m"]
version = ["6.7"]
}
剖析簡潔式建構作業
如要為簡潔版本建構基準,您可以建立情境,創建用於驅動 Gradle 分析器執行的場景:
# <root-project>/scenarios.txt
clean_build {
tasks = [":app:assembleDebug"]
cleanup-tasks = ["clean"]
}
如要執行這個情境,請使用下列指令:
gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt
使用 Gradle --profile
選項
如要透過 Gradle 指令列產生和查看建構設定檔,請執行下列步驟:
- 開啟專案根目錄中的指令列終端機。
- 輸入下列指令,執行簡潔式建構作業。在計算建構時,您應該在設定檔的每個建構作業之間執行簡潔式建構作業,因為當工作的輸入 (例如原始碼) 沒有改變時,Gradle 會略過工作。因此,沒有輸入變更的第二次建構會執行得更快,因為
並未重新執行因此,在建構之間執行
clean
工作,可確保剖析完整的建構程序。// On Mac or Linux, run the Gradle wrapper using "./gradlew". gradlew clean
- 使用下列旗標,執行任一變種版本的偵錯版本 (例如「dev」(開發) 版本):
gradlew --profile --offline --rerun-tasks assembleFlavorDebug
-
--profile
:啟用剖析功能。 -
--offline
:禁止 Gradle 擷取線上依附元件。這可確保 Gradle 嘗試更新依附元件所造成的延遲情況不會干擾您的剖析資料。您應已建構過一次專案,以確保 Gradle 已下載並快取依附元件。 -
--rerun-tasks
:強制 Gradle 重新執行所有工作並忽略任何工作最佳化。
-
-
建構完成後,請透過「Project」視窗前往
project-root/build/reports/profile/
目錄 ( 如圖 1 所示)。 -
在
profile-timestamp.html
檔案上按一下滑鼠右鍵,然後選取 在瀏覽器中開啟 >預設。報表看起來應該會與 如圖 2 所示您可以查看報表中的每個分頁來瞭解您的建構作業,例如「Task Execution」(工作執行) 分頁會顯示 Gradle 執行每個建構工作所需的時間。 -
選用:變更專案或建構設定之前,請先重複步驟 3 中的指令,但省略
--rerun-tasks
旗標。因為 Gradle 會嘗試 重新執行輸入內容,但輸入內容維持不變 (這些工作會顯示為UP-TO-DATE
(如報表「Task Execution」分頁標籤) 圖 3),您就可以知道哪些工作正在執行時 。例如,如果:app:processDevUniversalDebugManifest
未標示為UP-TO-DATE
,則建議使用建構設定以動態方式更新資訊清單的每個版本。不過,部分工作必須在每個建構作業中執行,例如:app:checkDevDebugManifest
。
您已經取得了建構設定檔報表,可以開始檢查報表各分頁的資訊,找出最佳化商機。部分建構設定需要實驗,因為專案和工作站的福利可能各有不同。例如,程式碼集數量龐大的專案或許就能利用程式碼縮減機制,移除未使用的程式碼並縮減應用程式大小。但較小的專案可能會因為停用程式碼縮減而受益。此外,增加 Gradle 堆積大小 (使用 org.gradle.jvmargs
) 可能會對低記憶體機器的效能造成負面影響。
變更建構設定後,請重複上述步驟並建立新的建構設定檔,以觀察變更的結果。例如,圖 4 顯示的是應用本頁中描述的一些基本最佳化後,同一個範例應用程式的報表。