比較 Compose 和 View 指標

Jetpack Compose 可加快 UI 開發速度，並提升 Android 開發效率。不過，請考量在現有應用程式中加入 Compose，可能會對應用程式的 APK 大小、建構和執行階段效能等指標造成影響。

APK 尺寸 和 建構 時間

本節將以 Sunflower 範例應用程式為例，說明遷移至 Compose 後對 APK 大小和建構時間的影響。這款應用程式示範了將 View 應用程式遷移至 Compose 的最佳做法。

APK 尺寸

將程式庫加入專案會增加 APK 大小。下列結果適用於各個專案的已縮小發布 APK，有了資源與程式碼縮減，得以使用 R8 完整模式，並使用 APK 分析工具進行測量。

首次在 Sunflower 中新增 Compose 時，APK 大小從 2,252 KB 增加到 3,034 KB，增加了 782 KB。產生的 APK 包含以 Views 和 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

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

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

摘要

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

如要閱讀更多個案研究，請參閱「為團隊採用 Compose」。

執行階段效能

本節會說明 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，後者會預先載入 View 系統的 UI 工具包類別和可繪項目。Jetpack Compose 1.0 會使用設定檔安裝來進行版本建構作業。設定檔安裝程式可讓應用程式指定重要程式碼，在安裝時進行預先 (AOT) 編譯。Compose 運輸 檔案 設定檔 規則， 以 減少 Compose 應用程式 中的 啟動時間 和 jank。