在這個頁面中,您將瞭解可組合項的生命週期,並 Compose 如何決定可組合項是否需要重組。
生命週期總覽
如管理狀態說明文件中所述, 組合描述應用程式的使用者介面,可透過執行可組合函式產生。 Composition是描述您的UI的composable的樹狀結構。
當 Jetpack Compose 首次執行您的composable時,在初始composition期間,系統會追蹤您呼叫的composable,以在Composition內容中描述您的 UI。等到應用程式的狀態變更時,Jetpack Compose 就會安排重新composition。重新安排時,Jetpack Compose 重新執行可能為改變狀態而變更的composable,然後更新Composition以反映任何變更。
組成只能由初始組成產生,並由 重組。重組是修改組合的唯一方式。
圖 1。 Composition內Composable的生命週期。而這會進入Composition狀態,被compose 0 次以上,然後留下Composition的內容。
一般而言,您更改 State<T>
物件後才會觸發重新composition。然後Compose追蹤這些composable,並在Composition內容中讀取這個特定 State<T>
的composable,以及無法呼叫的可略過內容。
如果多次呼叫某個可組合項,系統就會將多個執行個體 樂曲。每個呼叫在Composition內容中都有各自的生命週期。
@Composable fun MyComposable() { Column { Text("Hello") Text("World") } }
圖 2. 代表Composition的 MyComposable
。如果
系統會多次呼叫可組合函式,將多個執行個體
樂曲。不同顏色的元素代表
不同執行個體。
Composition的composable的解剖
Composition的例項是由其呼叫網站識別。Compose 編譯器會將每個呼叫網站視為具有差異。呼叫多個呼叫網站的composable,用於建立Composition的多個composable執行個體。
如果在重組期間,可組合函式呼叫的可組合函式與以往不同 在上一個組合期間,Compose 會識別 呼叫 (或未呼叫),且對於在兩個位置中呼叫的可組合函式 樂曲時,Compose 會避免在輸入內容沒有內容的情況下重組 已變更。
保留身分是將副作用與composable建立關聯在一起的重要關係,這樣使用者才能順利完成工作,不必每次都開始重新composition。
請參考以下範例:
@Composable fun LoginScreen(showError: Boolean) { if (showError) { LoginError() } LoginInput() // This call site affects where LoginInput is placed in Composition } @Composable fun LoginInput() { /* ... */ } @Composable fun LoginError() { /* ... */ }
在上方的程式碼片段中,LoginScreen
會以條件方式呼叫 LoginError
composable,並且一律呼叫 LoginInput
composable。每個呼叫都有專屬的呼叫網站和來源位置,編譯器將會用來識別該網路。
圖 3。 當狀態發生變更和重新composition時,composable中的 LoginScreen
代表。相同顏色則表示未經過重新composition。
雖然系統會優先呼叫 LoginInput
,但第二個呼叫仍會保留,但 LoginInput
執行個體會留存在composition中。此外,由於 LoginInput
的整個參數在整個參數中都發生過變更,因此 Compose 會略過對 LoginInput
的呼叫。
新增其他資訊以協助智慧重新設定
多次呼叫合成composition也會多次加到composition中。如果是從同一呼叫網站多次呼叫可組合項,Compose 沒有任何資訊可明確識別該可組合函式的每次呼叫 所以,執行順序和呼叫網站將會分開運作,以便 執行個體這類行為有時是必要的,但在某些情況下可能會產生不必要的行為。
@Composable fun MoviesScreen(movies: List<Movie>) { Column { for (movie in movies) { // MovieOverview composables are placed in Composition given its // index position in the for loop MovieOverview(movie) } } }
在上述範例中,除了呼叫網站之外,Compose 還會使用執行順序,讓執行個體在composable中保持不同。如果新增了 movie
加到清單底部,Compose 就能重複使用
組合在清單中的位置並未變更,因此
這些執行個體的 movie
輸入內容相同。
圖 4。. 在清單底部加入新元素時,代表composition中的 MoviesScreen
。Composition中的 MovieOverview
composable可以重複使用。在 MovieOverview
中使用相同的顏色,表示可組合的未重新composable。
不過,如果 movies
清單藉由加入頂端或
清單的「中間」、移除或重新排序項目,都會造成重新組成
在所有 MovieOverview
呼叫中,但輸入參數已變更在
請參考閱讀清單,進一步瞭解
如何選擇 Kubeflow Pipelines SDK 或 TFX舉例來說,如果 MovieOverview
使用副作用擷取電影圖片非常重要如果在動作執行期間進行重組,系統就會取消並重新開始。
@Composable fun MovieOverview(movie: Movie) { Column { // Side effect explained later in the docs. If MovieOverview // recomposes, while fetching the image is in progress, // it is cancelled and restarted. val image = loadNetworkImage(movie.url) MovieHeader(image) /* ... */ } }
圖 5。在清單中加入新元素時,代表compose中的 MoviesScreen
。無法重複使用 MovieOverview
composable,且所有副作用都會重新啟動。MovieOverview
中的不同顏色表示composable的compose。
在理想情況下,我們希望將 MovieOverview
的執行個體視為連結至該執行個體的 movie
身分。如果我們重新排序電影清單,最好會重新排列composition樹狀結構中的執行個體,而不是將不同的 MovieOverview
composable組成不同的電影執行個體。Compose 可讓您向執行階段指明您要用來識別樹狀結構中特定部分的值:key
composable的值。
透過呼叫由可傳入的一或多個值所發出的鍵來包裝程式碼區塊,系統會將這些值合併,以在composable中識別該執行個體。key
的值不必「全域」重複,因為在呼叫網站的元件組合中,該值可以重複。在這個範例中,movie
必須設有key
這個數字在movies
;同意分享key
其他一些元件組合
@Composable fun MoviesScreenWithKey(movies: List<Movie>) { Column { for (movie in movies) { key(movie.id) { // Unique ID for this movie MovieOverview(movie) } } } }
如上所述,即使清單上的元素發生變更,Compose 也會辨識對 MovieOverview
的個別呼叫,且可以重複使用。
圖 6。在清單中加入新元素時,代表compose中的 MoviesScreen
。由於 MovieOverview
元件含有專屬金鑰,因此 Compose 可辨識哪些 MovieOverview
執行個體並未變更,且可重複使用。他們的副作用會繼續執行。
某些composable已內建 key
composable。舉例來說,LazyColumn
接受在 items
DSL 中指定自訂 key
。
@Composable fun MoviesScreenLazy(movies: List<Movie>) { LazyColumn { items(movies, key = { movie -> movie.id }) { movie -> MovieOverview(movie) } } }
如果輸入內容未變更,則可略過
在重組期間,部分符合資格的可組合函式可以 如果輸入內容維持不變 樂曲。
除非:
- 這個函式的傳回類型非
Unit
- 這個函式會加上
@NonRestartableComposable
或@NonSkippableComposable
- 必要參數屬於不可穩定類型
我們提供實驗性編譯器模式強式略過, 這可放寬最後一個要求
類型必須符合下列規定,才算穩定 合約:
- 兩個執行個體的
equals
結果「一律」會與 同一個兩個執行個體 - 如果類型的公開資源有所異動,系統會通知Composition。
- 所有公開資源類型的類型都是穩定版本。
合約中有一些重要的常見類型
Compose 編譯器會視為穩定,即使未明確指定
方法是使用 @Stable
註解:
- 所有原始值類型:
Boolean
、Int
、Long
、Float
、Char
等。 - 字串
- 所有函式類型 (lambda)
所有這類型均能遵循穩定版的合約,因為這些變更無法變更。由於不可變更的類型一律不會改變,因此他們不用費心告知變更內容,因此您可以輕鬆遵循合約內容。
其中一個固定類型是穩定版,但可以成為 Compose 的 MutableState
類型。如果將值保存在MutableState
,整體狀態物件會視為穩定,因為當使用者撰寫程式碼變更時,
.value
屬性State
的 Google Ads 新帳戶重新申請驗證。
當所有已傳遞為組合的參數類型保持穩定時,系統會根據 UI 樹狀結構中的composable位置,比較參數值。如果上次呼叫後所有值都未變更,則系統會略過重新 composition。
只有在能夠證明類型時,Compose 才會認定其類型穩定。舉例來說,介面通常被視為不穩定,而包含可變動公開屬性的類型,在實作中可能無法變更。
如果 Compose 無法推論類型穩定,但您想強制 Compose 判定為穩定,請使用 @Stable
註解標記。
// Marking the type as stable to favor skipping and smart recompositions. @Stable interface UiState<T : Result<T>> { val value: T? val exception: Throwable? val hasError: Boolean get() = exception != null }
在上方的程式碼片段中,由於 UiState
是介面,因此 Compose 通常可能會判定此類型不穩定。新增 @Stable
註解即表示 Compose 這個類型很穩定,以便 Compose 支援智慧重新composition。也就是說,當介面做為參數類型使用時,Compose 會將所有實作項目視為穩定版。
為您推薦
- 注意:系統會在 JavaScript 關閉時顯示連結文字
- 狀態和 Jetpack Compose
- Compose 中的連帶效果
- 在 Compose 中儲存 UI 狀態