Jetpack Compose 旨在提供拆箱即用的效能。本頁面說明如何編寫及設定應用程式以獲得最佳效能，並指出一些應避免的模式。
閱讀本文前，建議您先熟悉在 Compose 的程式設計概念中提到的核心 Compose 概念。
正確設定應用程式
如果您的應用程式效能不佳，可能表示設定有問題。第一步是查看下列設定選項。
在版本模式中建構並使用 R8
如果您發現效能問題，請務必在版本模式中執行應用程式。偵錯模式有助於找出許多問題，但這需要投入大量效能，而且可能會難以找出其他可能影響效能的程式碼問題。另外，您還應該使用 R8 編譯器從應用程式中移除不必要的程式碼。根據預設，在版本模式中進行建構會自動使用 R8 編譯器。
使用基準設定檔
Compose 是以程式庫的形式發布，本身不屬於 Android 平台，這讓我們得以經常更新 Compose 並支援較早的 Android 版本。然而，將 Compose 發布為程式庫會產生費用。這是因為，Compose 不像 Android 平台程式碼那般，早已經過編譯並安裝在裝置上； 程式庫必須在應用程式啟動時載入，並在需要函式時及時解釋。如此一來，應用程式在啟動之際和在首次使用程式庫功能時，執行速度都可能變得較慢。
您可以定義基準設定檔來改善效能。這些設定檔會定義關鍵使用者旅程中所需的類別和方法，並與應用程式的 APK 一起發布。在安裝應用程式期間，ART 會預先編譯這些重要的程式碼，以便在應用程式啟動時即可開始使用。
定義良好的基準設定檔並不容易，因此我們在交貨時便已直接為 Compose 備妥這個設定檔，您可能直接就能享受預設設定檔的好處，不必特別進行什麼操作。不過，您當然也可以選擇定義自己的設定檔，只是產生的設定檔未必能實際改善您的應用程式效能。建議您測試自己定義的設定檔，驗證是否能發揮預期效用。有個理想的做法是撰寫應用程式的巨集基準測試，並在寫入及修改基準設定檔時查看測試結果。請參閱 Macrobenchmark Compose 範例，瞭解如何編寫 Compose UI 的 Macrobenchmark 測試。
如需版本模式、R8 和基準設定檔的效果詳細分析資料，請參閱「Why should you always test Compose performance in release?」(為什麼應該只在版本中測試 Compose 效能？) 這篇網誌文章。
三個 Compose 階段對效能的影響
如 Jetpack Compose 階段 中所述，當 Compose 更新頁框時，會經過三個階段：
- 組成：Compose 可以決定顯示內容– 這個程式庫會執行可組合函式並建構 UI 樹狀結構。
- 版面配置：Compose 會決定 UI 樹狀結構中每個元素的大小和位置。
- 繪圖：Compose 實際上會算繪個別 UI 元素。
Compose 可以視需求有意略過任何階段。舉例來說，假設單一圖形元素會在相同大小的兩個圖示之間進行切換。由於該元素不會改變大小，且不會新增或移除 UI 樹狀結構中的元素，因此 Compose 可以略過可組合項及版面配置階段，只重新繪製該單獨元素。
但是有些程式設計錯誤可能會讓 Compose 難以得知哪些階段可以安全略過。如有任何疑慮，Compose 會結束執行全部三個階段，這將使 UI 速度慢於預期速度。因此，許多效能最佳做法都涉及到協助 Compose 略過不需要的階段。
一般來說，改善效能時需遵守幾項通用原則。
首先，請盡可能將計算結果從可組合函式中移出。 只要有 UI 發生變更，就可能需要重新執行可組合函式；您放入可組合項中的任何程式碼都會重新執行，可能是針對動畫的每一個畫面重新執行。因此，您應該將可組合項的程式碼限制在建構 UI 所實際需要的範圍。
其次，盡可能延遲狀態讀取。 將狀態讀取移至子項可組合項或後續階段，即可最小化重新組合或完全略過組合階段。為此，您可以傳遞 lambda 函式（而不是頻繁變更狀態的狀態值），以及在傳遞頻繁變更的狀態時首選 lambda 輔助鍵。您可以在「盡可能延遲讀取時間」一節，查看這項技巧的範例。