比較 Compose 和 View 指標

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

APK 尺寸 和 建構 時間

本節將介紹 Sunflower 範例應用程式，其中會示範如何將以 View 為基礎的應用程式遷移至 Compose 的最佳做法，藉此說明 APK 大小和建構時間的影響。

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 包含 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
僅限觀看 混合式 View 和 Compose 僅限 Compose
平均建構時間 299.47 毫秒 399.09 毫秒 342.16 毫秒

首次在 Sunflower 中新增 Compose 時，平均建構時間已從 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 以外的程式碼路徑。

與 「視野」 系統 進行比較

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

所有 擴展 視野

凡是在螢幕上繪製的 View (例如 TextView、Button 或 ImageView)，都需要記憶體配置、明確狀態追蹤和各種回呼，才能支援所有用途。此外，自訂 View 擁有者需要實作明確的邏輯，以防止在非必要的情況下 (例如重複處理資料) 重新繪製。

Jetpack Compose 有幾種方式 可以 解決 這個 問題， Compose 沒有用於繪製檢視畫面的明確可更新物件。UI 元素是簡單的可組合函式，會以可重播的方式將資訊寫入組合中。這有助於只針對需要特定功能的可組合項移除明確的狀態追蹤、記憶體配置和回呼，而不會要求特定 View 類型的所有擴充功能。

此外，Compose 提供智慧重組，如果不需要進行變更，則會重播先前繪製的結果。

多重 配置 通行證

傳統的 ViewGroup 在評估和版面配置 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 與 Jetpack Compose，請參閱 MacrobenchmarkSample 專案。

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

安裝 Compose 設定檔

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