LiveData ，是Android 2017推出的一個東西，配合MVVM使用。觀察者模式，的確簡化了我們的工作方式，但 RxJava 等選項，對於當時的初學者來說實在是太複雜了。因此 Architecture Components 團隊建立了 LiveData ：這是個非常 “有主見的” 可觀察資料持有者類，並且是專門為 Android 設計的。它保持簡單明瞭，這讓它易於上手，建議是將 RxJava 用於更復雜的 響應流 案例，以充分利用這兩者之間的整合。
一、死資料
LiveData 仍然是我們 針對 Java 開發人員、初學者和簡單情況的解決方案。對於其餘部分，一個不錯的選擇是遷移到 Kotlin Flows。Flows 仍然有一個陡峭的學習曲線，但它們是 Kotlin 語言的一部分，由 Jetbrains 提供支援；Compose 即將到來（已到來），它非常適合響應式模型。
一段時間以來，我們一直在討論使用 Flows 連線 app 的不同部分，但 view 和 ViewModel 除外。現在我們有了更安全的方法從 Android UI 收集 flows，我們可以建立一個完整的遷移指南。
在這篇文章中，您將學習如何將 Flows 暴露給view、如何收集它們，以及如何對其進行微調，以滿足特定需求。
二、Flow
支援佈局動態化和邏輯動態化開源社群活躍LiveData 做了一件很漂亮的事兒：它 公開資料，同時快取最新值，並知曉 Android 的生命週期。後來我們瞭解到它也可以 啟動協程，並 建立複雜的轉換，但這就有點複雜了。
讓我們看一些 LiveData 模式及其 Flow 等效程式碼：
2.1 使用Mutable，公開 一次性操作 結果
使用 Mutable（可變）資料持有者，公開一次性操作的結果。這是經典模式，在這種模式中，你能用 協程的結果 來改變 狀態持有者，工作示意圖如下。
使用 Mutable（可變）資料持有者 （LiveData），公開 一次性操作 的結果。
<!-- Copyright 2020 Google LLC.
SPDX-License-Identifier: Apache-2.0 -->
class MyViewModel {
private val _myUiState = MutableLiveData<Result<UiState>>(Result.Loading)
val myUiState: LiveData<Result<UiState>> = _myUiState
// 從 suspend fun 載入資料並轉變狀態
init {
viewModelScope.launch {
val result = ...
_myUiState.value = result
}
}
}為了對 Flows 執行同樣的操作，我們可以使用（Mutable 可變的）StateFlow。
然後，使用 可變資料容器（StateFlow），公開 一次性操作 的結果。
class MyViewModel {
private val _myUiState = MutableStateFlow<Result<UiState>>(Result.Loading)
val myUiState: StateFlow<Result<UiState>> = _myUiState
// 從 suspend fun 載入資料並轉變狀態
init {
viewModelScope.launch {
val result = ...
_myUiState.value = result
}
}
}StateFlow 是一種特殊型別的SharedFlow（這是一種特定型別的 Flow），最接近 LiveData：
- 它總有一個值。
- 它只有一個值。
- 它支援多個觀察者（因此 flow 是 共享的）。
- 它總是在訂閱時，replay 最新的值，與 活躍觀察者 的數量無關。
需要說明的是，向 view 公開 UI 狀態時，請使用 StateFlow。它是一個安全高效的觀察者，旨在持有 UI 狀態。
2.2 公開 一次性操作 的結果
這等效於前面的程式碼段，在沒有可變的 後備屬性 的情況下，公開協程呼叫的結果。對於 LiveData，我們使用了 liveData 協程 builder：
公開 一次性操作 的結果（LiveData）示例程式碼：
class MyViewModel(...) : ViewModel() {
val result: LiveData<Result<UiState>> = liveData {
emit(Result.Loading)
emit(repository.fetchItem())
}
}由於狀態持有者總是有一個值，所以最好將 UI狀態 封裝在某種支援 Loading、Success 和 Error 等狀態的 Result 類中。由於必須進行一些 配置，因此等效的 Flow 程式碼涉及的內容會更多：
公開 一次性操作 的結果 (StateFlow)示例程式碼：
class MyViewModel(...) : ViewModel() {
val result: StateFlow<Result<UiState>> = flow {
emit(repository.fetchItem())
}.stateIn(
scope = viewModelScope,
started = WhileSubscribed(5000), // 或者 Lazily，因為它是一次性的
initialValue = Result.Loading
)
}stateIn 是一個 Flow 運算子，它將 Flow 轉換為 StateFlow。讓我們暫時完全信任這些引數，因為我們需要更多的複雜性（知識），才能在以後正確解釋它。
2.3: 帶參一次性資料載入
假設，你想載入一些依賴於使用者 ID 的資料，並且你從公開 Flow 的 AuthManager 獲得這些資訊：
帶參的 一次性資料 載入（LiveData）使用LiveData，您可以執行類似的操作：
class MyViewModel(authManager..., repository...) : ViewModel() {
private val userId: LiveData<String?> =
authManager.observeUser().map { user -> user.id }.asLiveData()
val result: LiveData<Result<Item>> = userId.switchMap { newUserId ->
liveData { emit(repository.fetchItem(newUserId)) }
}
}switchMap 是一個轉換，當 userId 改變時，它的主體將被執行，同時結果也會被訂閱。
如果沒理由讓 userId 成為 LiveData，那麼更好的替代方案是將 streams 與 Flow 結合起來，並最終將公開的結果，轉換為 LiveData。
class MyViewModel(authManager..., repository...) : ViewModel() {
private val userId: Flow<UserId> = authManager.observeUser().map { user -> user.id }
val result: LiveData<Result<Item>> = userId.mapLatest { newUserId ->
repository.fetchItem(newUserId)
}.asLiveData()
}使用 Flows 執行此操作，看起來非常相似：
帶參的 一次性資料 載入 (StateFlow)：
class MyViewModel(authManager..., repository...) : ViewModel() {
private val userId: Flow<UserId> = authManager.observeUser().map { user -> user.id }
val result: StateFlow<Result<Item>> = userId.mapLatest { newUserId ->
repository.fetchItem(newUserId)
}.stateIn(
scope = viewModelScope,
started = WhileSubscribed(5000),
initialValue = Result.Loading
)
}需要說明的是，如果您需要更大的靈活性，也可以使用 transformLatest 並顯式地 emit（發射） 條目。
val result = userId.transformLatest { newUserId ->
emit(Result.LoadingData)
emit(repository.fetchItem(newUserId))
}.stateIn(
scope = viewModelScope,
started = WhileSubscribed(5000),
initialValue = Result.LoadingUser // 注意不同的 Loading 狀態
)2.4: 觀察帶有引數的資料流
現在讓我們讓這個例子，更具 響應性。資料不是被獲取的，而是 被觀察的，因此我們將資料來源中的更改，自動傳播到 UI。
繼續我們的示例：我們不在資料來源上呼叫 fetchItem，而是使用一個假設的 observeItem 運算子來返回 Flow。使用 LiveData，您可以將流轉換為 LiveData，並 emitSource 所有更新：
觀察帶有引數的 stream（LiveData）:
class MyViewModel(authManager..., repository...) : ViewModel() {
private val userId: LiveData<String?> =
authManager.observeUser().map { user -> user.id }.asLiveData()
val result = userId.switchMap { newUserId ->
repository.observeItem(newUserId).asLiveData()
}
}或者，最好使用 flatMapLatest 組合兩個 flow，並僅將輸出轉換為 LiveData：
class MyViewModel(authManager..., repository...) : ViewModel() {
private val userId: Flow<String?> =
authManager.observeUser().map { user -> user?.id }
val result: LiveData<Result<Item>> = userId.flatMapLatest { newUserId ->
repository.observeItem(newUserId)
}.asLiveData()
}Flow 實現是類似的，但沒有 LiveData 轉換：
觀察帶有引數的 stream（StateFlow）
觀察帶有引數的 stream（StateFlow）：
class MyViewModel(authManager..., repository...) : ViewModel() {
private val userId: Flow<String?> =
authManager.observeUser().map { user -> user?.id }
val result: StateFlow<Result<Item>> = userId.flatMapLatest { newUserId ->
repository.observeItem(newUserId)
}.stateIn(
scope = viewModelScope,
started = WhileSubscribed(5000),
initialValue = Result.LoadingUser
)
}每當使用者更改，或儲存庫中的使用者資料更改時，公開的 StateFlow 都將收到更新。
2.5 合併多個資料來源
MediatorLiveData 讓您可以觀察一個或多個更新源（LiveData 可觀察物件）並在它們獲得新資料時做一些事情。 通常，我們可以使用下面的方式更新 MediatorLiveData 的值：
val liveData1: LiveData<Int> = ...
val liveData2: LiveData<Int> = ...
val result = MediatorLiveData<Int>()
result.addSource(liveData1) { value ->
result.setValue(liveData1.value ?: 0 + (liveData2.value ?: 0))
}
result.addSource(liveData2) { value ->
result.setValue(liveData1.value ?: 0 + (liveData2.value ?: 0))
}不過，改用Flow 後就要簡單許多，等效程式碼如下：
val flow1: Flow<Int> = ...
val flow2: Flow<Int> = ...
val result = combine(flow1, flow2) { a, b -> a + b }當然，我們還可以使用combineTransform 函式或 zip。
三、配置公開的 StateFlow
我們之前使用 stateIn 將常規 flow 轉換為 StateFlow，但它需要一些配置。如果你現在不想深入細節，只想複製貼上，那麼我推薦這種組合：
val result: StateFlow<Result<UiState>> = someFlow
.stateIn(
scope = viewModelScope,
started = WhileSubscribed(5000),
initialValue = Result.Loading
)可以看到，stateIn 有 3 個引數（來自文件）：
- @param scope ：開啟共享的 協程作用域。
- @param started ：控制共享 何時開始 和 何時停止 的策略。
- @param initialValue ：state Flow 的初始值。當使用帶有
replayExpirationMillis引數的 [SharingStarted.WhileSubscribed] 策略，重置 state flow 時，也會使用此值。
而started也有3個取值：
- Lazily：當第一個訂閱者出現時開始，當 scope 被取消時停止。
- Eagerly：立即開始，並在 scope 被取消時停止
- WhileSubscribed: 比較複雜了
對於 一次性操作，您可以使用 Lazily 或 Eagerly。但是，如果您正在觀察其他 flow，則應該使用 WhileSubscribed 來進行小而重要的最佳化，如下所述。
四、WhileSubscribed 策略
WhileSubscribed 在沒有收集者時，會取消 上游 flow。使用 stateIn 建立的 StateFlow 將資料公開給 view，但它也會觀察來自 其他層 或 app（上游） 的 flow。保持這些 flow 處於活躍的狀態，可能會導致資源浪費，例如，假如它們持續從資料庫連線、硬體感測器等其他來源讀取資料（的話，就會導致資源浪費）。當您的 app 進入後臺時，您應該做個良好市民，停止這些協程。
WhileSubscribed 需要兩個引數：
public fun WhileSubscribed(
stopTimeoutMillis: Long = 0,
replayExpirationMillis: Long = Long.MAX_VALUE
)4.1 Stop 超時
stopTimeoutMillis 是用來配置 最後一個訂閱者消失 和 上游flow停止 之間的延遲（以毫秒為單位）的。它預設為零（也就是 立即停止）。
事實上，stopTimeoutMillis在Android開發中的用處很大，因為如果 view 在幾分之一秒內就停止監聽的話，你肯定不想取消上游 flow。這種情況總是發生——例如，當使用者旋轉裝置時，view 會被快速連續地銷燬和重新建立。
liveData 協程 builder 中的解決方案，是 新增 5 秒的延遲，之後如果沒有訂閱者，那麼協程將停止。 WhileSubscribed(5000) 就是這麼幹的：
class MyViewModel(...) : ViewModel() {
val result = userId.mapLatest { newUserId ->
repository.observeItem(newUserId)
}.stateIn(
scope = viewModelScope,
started = WhileSubscribed(5000),
initialValue = Result.Loading
)
}這種方法包含下面這幾條內容：
- 當使用者將您的 app 傳送到後臺時，來自其他層的更新，將在五秒後停止，以節省電池電量。
- 最新的值仍將被快取，以便當使用者返回它時，view 立即就能有一些資料。
- 訂閱將重新啟動，新值將出現，並在可用時重新整理螢幕。
4.2 Replay 到期時間
如果您不希望使用者在離開太久時，看到過時的資料，並且您更喜歡顯示 loading 畫面，請檢視 WhileSubscribed 中的 replayExpirationMillis 引數。在這種情況下它非常方便並且還節省了一些記憶體，因為快取的值將被恢復為 stateIn 中定義的初始值。返回 app 不會那麼快，但卻不會顯示舊的資料。
replayExpirationMillis -配置 共享協程的停止 和 replay快取的重置 之間的延遲（以毫秒為單位）（這將使 shareIn 運算子的快取為空，並將快取值重置為 stateIn 運算子的原始 initialValue）。它預設為 Long.MAX_VALUE（永遠保留replay快取，從不重置緩衝區）。使用零值可使快取立即過期。
五、從 view 觀察 StateFlow
正如我們到目前為止所看到的，讓 ViewModel 中的 StateFlow 知道他們不再監聽了，對 view 來說是非常重要的。然而，就像所有與生命週期相關的事情一樣，事情並沒有那麼簡單。
為了收集 flow，您需要一個協程。 Activities 和 fragments 提供了一堆協程 builder：
- Activity.lifecycleScope.launch：立即啟動協程，並在 activity 被銷燬時取消它。
- Fragment.lifecycleScope.launch：立即啟動協程，並在 fragment 被銷燬時取消它。
- Fragment.viewLifecycleOwner.lifecycleScope.launch：立即啟動協程，並在 fragment 的 view lifecycle 被銷燬時取消協程。如果你正在修改 UI，你應該使用 view lifecycle。
六、LaunchWhenStarted, launchWhenResumed…
名為 launchWhenX 的，即launch 的特殊版本，將一直等待，直到 lifecycleOwner 處於 X 狀態，並在 lifecycleOwner 低於 X 狀態時，掛起協程。需要注意的是，在它們的生命週期所有者被銷燬之前，它們是不會取消協程的。
使用 launch/launchWhenX 收集 Flow，是不安全的。在 app 處於後臺時接收更新，可能會導致崩潰，可以透過在檢視中掛起 collection，來解決這個問題。但是，當 app 處於後臺時，上游 flow 仍處於活躍狀態，這可能會浪費資源。
這意味著，到目前為止，我們為配置 StateFlow 所做的一切都將毫無用處；但是，眼下有一個新的 API 登場了。
七、lifecycle.repeatOnLifecycle
這個新的協程 builder（可從 lifecycle-runtime-ktx 2.4.0-alpha01 獲得）正是我們所需要的：它在特定狀態下啟動協程，並在生命週期所有者低於該狀態時停止協程。
以下是不同的 Flow 收集方法。例如，在 Fragment 中：
onCreateView(...) {
viewLifecycleOwner.lifecycleScope.launch {
viewLifecycleOwner.lifecycle.repeatOnLifecycle(STARTED) {
myViewModel.myUiState.collect { ... }
}
}
}這將在 Fragment 的 view STARTED 的時候 ，開始收集，並在返回到 STOPPED 時停止。閱讀以更安全的方式從 Android UI 收集 flow 的全部內容。
將 repeatOnLifecycle API，與上述 StateFlow 指南混合使用，可以在充分利用裝置資源的同時，獲得最佳效能。
StateFlow 透過 WhileSubscribed(5000) 公開，並透過 repeatOnLifecycle(STARTED) 收集。
警告：最近新增到 Data Binding 的 StateFlow 支援 使用 launchWhenCreated 來收集更新，當達到穩定狀態時，將開始使用 repeatOnLifecycle 來代替。
對於 Data Binding 來說，你應該隨處使用 Flow，並簡單地新增 asLiveData()，將其公開給 view。當 lifecycle-runtime-ktx 2.4.0 變得穩定時，Data Binding 也會被更新。
八、總結
從 ViewModel 公開資料，並從 view 中收集資料的最佳方式是：
- 使用 WhileSubscribed 策略，公開一個帶有超時的 StateFlow。[[示例]](https://gist.github.com/JoseAlcerreca/4eb0be817d8f94880dab279d1c27a4af)
- 使用 repeatOnLifecycle 收集。[示例]
任何其他組合，都將使上游 flow 保持活躍狀態，從而浪費資源：
- 使用 WhileSubscribed 公開，並在 lifecycleScope.launch/launchWhenX 中收集
- 使用 Lazily/Eagerly 公開，並使用repeatOnLifecycle 收集