比較 Compose 和 View 指標

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

Jetpack Compose 可加快 UI 開發作業，並改善 Android 開發作業。不過，請將 Compose 新增至現有應用程式，可能對應用程式的 APK 大小、建構和執行階段效能等指標造成影響。

APK 尺寸 和 建構 時間

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

APK 尺寸

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

第一次將 Compose 新增至 Sunflower 時，APK 大小從 2,252 KB 增加到 3,034 KB，增加了 782 KB。產生的 APK 是由 UI 版本、View 和 Compose 的組合所組成。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

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

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

摘要

採用 Compose 可有效增加應用程式的 APK 大小，並且因為 Compose 程式碼的編譯程序而提高應用程式的建構時間效能。不過，您必須權衡這些取捨與 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。