比較 Compose 和 View 指標

Jetpack Compose 可加快 UI 開發作業，並改善 Android 開發作業。不過，請考量在現有應用程式中加入 Compose 可能會對哪些指標造成影響，例如應用程式的 APK 大小、建構和執行階段效能。

APK 尺寸 和 建構 時間

本節將探討 APK 大小和建構時間的影響，方法是查看 Sunflower 範例應用程式，這個應用程式可展示將以 View 為基礎的應用程式遷移至 Compose 的最佳做法。

APK 尺寸

在專案中加入程式庫會增加 APK 大小。下列結果適用於各個專案的已縮小釋出 APK，這些專案已啟用資源和程式碼縮減功能，並使用 R8 完整模式，且測量結果使用 APK 分析工具。

僅限觀看次數 混合使用 View 和 Compose 僅限 Compose
下載大小 2,252 KB 3,034 KB 2,966 KB

第一次將 Compose 新增至 Sunflower 時，APK 大小從 2,252 KB 增加到 3,034 KB，增加了 782 KB。產生的 APK 包含使用 View 和 Compose 的 UI 建構作業。Sunflower 新增了其他依附元件，因此預期會增加。

相反地，當 Sunflower 遷移至僅使用 Compose 的應用程式時，APK 大小從 3,034 KB 降至 2,966 KB，減少了 68 KB。這項減少幅度是因為移除了未使用的 View 依附元件，例如 AppCompat 和 ConstraintLayout。

建構時間

由於 Compose 編譯器會處理應用程式中的可組合項，因此新增 Compose 會增加應用程式的建構時間。以下結果是使用獨立的 gradle-profiler 工具取得，該工具會執行多次建構作業，以便取得 Sunflower 偵錯建構作業時間的平均建構時間：

gradle-profiler --benchmark --project-dir . :app:assembleDebug
僅限觀看次數 混合使用 View 和 Compose 僅限 Compose
平均建構時間 299.47 毫秒 399.09 毫秒 342.16 毫秒

第一次將 Compose 新增至 Sunflower 時，平均建構時間從 299 毫秒增加到 399 毫秒，增加了 100 毫秒。這是因為 Compose 編譯器會執行額外工作，以轉換專案中定義的 Compose 程式碼。

反之，在 Sunflower 遷移至 Compose 完成後，平均建構時間下降至 342 毫秒，減少了 57 毫秒。這項縮短時間可歸因於多項因素，這些因素共同縮短了建構時間，例如移除資料繫結、將使用 kapt 的依附元件遷移至 KSP，以及將多個依附元件更新至最新版本。

摘要

採用 Compose 後，由於 Compose 程式碼的編譯程序，應用程式的 APK 大小和建構時間效能都會有效增加。不過，您必須權衡這些取捨與 Compose 的優點，特別是採用 Compose 時，開發人員的生產力是否會因此提升。舉例來說，Play 商店團隊發現撰寫 UI 所需的程式碼量大幅減少，有時甚至可減少 50%，進而提升程式碼的生產力和可維護性。

如要進一步瞭解個案研究，請參閱「採用 Compose for Teams」。

執行階段效能

本節會說明 Jetpack Compose 執行階段效能的相關主題，讓您瞭解 Jetpack Compose 與 View 系統之間的效能差異，以及如何評估效能。

智慧 重組

當部分 UI 無效時，Compose 會嘗試只重新編譯需要更新的部分。如要進一步瞭解這項功能，請參閱「可組合項的生命週期」和「Jetpack Compose 階段」說明文件。

基準設定檔

基準設定檔是加快常見使用者歷程的絕佳方法。在應用程式中加入基準設定檔，可避免對內含的程式碼路徑進行解釋和及時 (JIT) 編譯步驟，因此從首次啟動後，程式碼執行速度可提高約 30%。

Jetpack Compose 程式庫包含自己的基準設定檔，因此在應用程式中使用 Compose 時，系統會自動套用這些最佳化功能。不過，這些最佳化功能只會影響 Compose 程式庫中的程式碼路徑，因此建議您在應用程式中新增基準設定檔，以涵蓋 Compose 以外的程式碼路徑。

與 「視野」 系統 進行比較

Jetpack Compose 相較於 View 系統有許多改良之處。以下各節將說明這些改善項目。

所有 擴展 視野

在畫面上繪製的每個 View (例如 TextView、Button 或 ImageView) 都需要記憶體配置、明確的狀態追蹤和各種回呼，才能支援所有用途。此外，自訂 View 擁有者需要實作明確的邏輯，避免在不需要時重新繪製，例如重複資料處理。

Jetpack Compose 有幾種方式 可以 解決 這個 問題， Compose 沒有用於繪製檢視畫面的明確可更新物件。UI 元素是簡單的可組合函式，其資訊會以可重複使用的方式寫入組合。這有助於將明確的狀態追蹤、記憶體分配和回呼縮減至需要上述功能的元件，而非所有指定 View 類型的擴充功能。

此外，Compose 會提供智慧重組功能，在您不需要進行變更的情況下，重播先前繪製的結果。

多重 配置 通行證

傳統的 ViewGroups 在評估和配置 API 方面具有充分的表現力，因此容易產生多個配置。如果 是在 檢視 表階層的 特定 巢狀 點 執行， 這些 多重 配置 通行證 可能 會導致 指數的 工作。

Jetpack Compose 會根據其 API 合約，為所有版面配置可組合項強制實施單一版面配置通行證。這可讓 Compose 有效處理深層 UI 樹狀結構。如果需要多次測量，Compose 有內建函式測量。

查看 啟動 效能

當 首次 顯示 特定 配置時， View 系統 需要 加載 XML 配置。由於 Jetpack Compose 中的版面配置是採用 Kotlin 進行編寫，而編譯方式則與應用程式的其餘部分相同，因此可以省下這筆費用。

Compose 基準

在 Jetpack Compose 1.0 中， 應用程式 在 debug 和 release 模式下的 效能 有顯著 差異。 為了 代表 時間， 在 剖析 應用程式時， 一律使用 release 建構 作業， 而非 debug。

如要查看 Jetpack Compose 程式碼的執行效能，可以使用 Jetpack Macrobenchmark 程式庫。如要瞭解如何將該程式庫與 Jetpack Compose 搭配使用，請參閱 MacrobenchmarkSample 專案。

Jetpack Compose 團隊也會透過 Macrobenchmark 偵測可能發生的任何迴歸問題，例如使用延遲資料欄基準和資訊主頁追蹤迴歸情形。

安裝 Compose 設定檔

由於 Jetpack Compose 是未封裝的程式庫，因此無法從Zygote 中受益，因為 Zygote 會預先載入 View 系統的 UI 工具包類別和可繪圖。Jetpack Compose 1.0 會使用 檔案 安裝 來進行 版本 建構作業。設定檔安裝程式可讓應用程式指定重要程式碼，在安裝時進行預先 (AOT) 編譯。Compose 運輸 檔案 設定檔 規則， 以 減少 Compose 應用程式 中的 啟動時間 和 jank。