基本上，狀態產生是逐步將變更套用至 UI 狀態的過程。狀態一直存在，而且會因事件而變更。下表匯總了事件與狀態之間的差異：
事件 |
狀態 |
短暫、無法預測，且存在於有限期間內。 |
一直存在。 |
狀態產生的輸入內容。 |
狀態產生的輸出內容。 |
UI 或其他來源的產物。 |
供 UI 取用。 |
事件可能來自：
- 使用者：在使用者與應用程式的 UI 互動時。
- 其他狀態變更來源：透過 UI 顯示應用程式資料的 API、網域，或是 Snackbar 逾時事件、用途或存放區等各資料層。
狀態產生 API
狀態產生有兩個主要 API 可用，視您目前處於哪個管道階段而定：
Pipeline Stage |
API |
輸入 |
您應使用非同步 API 來執行 UI 執行緒以外的工作，以免發生 UI 卡頓的情形。例如，Kotlin 中的 Coroutine 或 Flows，以及 Java 程式設計語言中的 RxJava 或回呼。 |
輸出 |
您應使用可觀測的資料容器 API，在狀態變更時撤銷及重新轉譯 UI。例如 StateFlow 或 LiveData。可觀測的資料容器可保證 UI 一律會在畫面上顯示 UI 狀態。 |
這兩種方法當中，與選擇用於輸出的可觀測 API 相較，選擇用於輸入的非同步 API 對狀態產生管道的性質影響更大。這是因為輸入內容決定了可套用至管道的處理類型。
狀態產生管道組合
以下各節說明各種輸入內容最適用的狀態產生技術，以及相符的輸出 API。每個狀態產生管道都是輸入和輸出的組合，且應具有以下性質：
- 生命週期感知：在 UI 不可見或無效的情況下，狀態產生管道不應耗用任何資源，除非有明確要求。
- 易於取用：UI 應該能夠輕鬆轉譯產生的 UI 狀態。針對狀態產生管道輸出內容的注意事項，會因不同 View API (例如 View 系統或 Jetpack Compose) 而有所差異。
狀態產生管道的輸出類型
為 UI 狀態選擇輸出 API 以及其呈現性質，主要取決於應用程式用於轉譯 UI 的 API。在 Android 應用程式中，您可以選擇使用 Views 或 Jetpack Compose。需考量的事項包括：
下表匯總了使用 Views 框架時，狀態正式版群組管道應使用的 API：
輸入功率 |
輸出內容 |
一次性 API |
|
串流 API |
|
一次性 API 和串流 API |
|