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 輔助鍵。您可以在「盡可能延遲讀取時間」一節,查看這項技巧的範例。