我想完全了解這里發生的事情。
sharedFlow.debounce(250)
.onEach(::updateGroupingStrategy)
.shareIn(viewModelScope, SharingStarted.WhileSubscribed(5000L), replay = 1)
去抖動
Returns a flow that mirrors the original flow, but filters out values that are followed by the newer values within the given timeout. The latest value is always emitted.
debounce helps to detect the state when no new data is submitted for some time, effectively allowing you to process a data when the input is completed.
從我的角度來看，我延遲訂閱sharedflowms250L或者我只訂閱值250L？
在各個
* Returns a flow that invokes the given [action] **before** each value of the upstream flow is emitted downstream.
從我的角度來看，很不理解。先回流再開始訂閱，給它賦值？
.shareIn
Sharing is started when the first subscriber appears, immediately stops when the last subscriber disappears (by default), keeping the replay cache forever (by default).
It has the following optional parameters:
stopTimeoutMillis — configures a delay (in milliseconds) between the disappearance of the last subscriber and the stopping of the sharing coroutine. It defaults to zero (stop immediately).
replay - the number of values replayed to new subscribers (cannot be negative, defaults to zero).
從我的角度來看，在沒有更多訂閱者之后我等待5000L幾毫秒然后我采取行動？重播我不明白。
uj5u.com熱心網友回復：
每個 Flow 運算子（除了stateIn和shareIn）都會創建一個新的冷流來包裝它所呼叫的流。當收集到下游流量時，它會貫穿其上游操作員的操作。
debounce 收集時立即從上游收集，但延遲按您指定的時間重新向下游發送值。如果在延遲期間有新值到達，它會丟棄掛起值。其目的是過濾掉快速變化以簡化下游收集器必須處理的內容。您的上游共享流將在收集下游流時立即看到訂閱者。
onEach添加每次上游流發出時都會發生的副作用。
shareIn使流變熱，但將流變熱的WhileSubscribed時間限制為只有至少有一個訂閱者。這樣我們就不會浪費資源來獲取或監視沒有任何用處的資料。這5000L意味著它在失去最后一個訂閱者后等待 5000 毫秒才關閉。這避免了當我們失去最后一個訂閱者但快速獲得新訂閱者時不必要地關閉流程。在 Android 上，當螢屏旋轉時，這種情況經常發生，因為訂閱者將被銷毀，但是一旦 Activity 在新的方向上重新創建，就會創建相同事物的新訂閱者。我們希望避免從頭開始重新啟動流程，以便它可以快速顯示最新資料。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/533691.html