我想完全了解这里发生了什么。
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.
从我的Angular 来看,我是将订阅sharedflow
延迟了250L
毫秒,还是仅在每250L
及之后订阅值?
在每个
* Returns a flow that invokes the given [action] **before** each value of the upstream flow is emitted downstream.
从我的Angular 来看,挺不理解的,先返流再开始订阅,给它赋值?
.共享
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).
从我的Angular 来看,在没有更多的用户后,我等待5000L
毫秒,然后我采取行动?重放我不明白。
1条答案
按热度按时间63lcw9qa1#
每个Flow操作符(除了
stateIn
和shareIn
之外)创建一个新的cold流,该流 Package 它所调用的流。当下游流被收集时,它将运行其上游操作符的操作。debounce
* 立即 * 在收集时从上游收集,但会将重新发出值的下游延迟您指定的时间。如果在延迟期间有新值到达,则会丢弃待定值。其目的是筛选出快速更改,以简化下游收集器必须处理的内容。您的上游共享流将在收集下游流时立即看到订阅者。onEach
增加了每次上游流发射时发生的副作用。shareIn
使流变热,但WhileSubscribed
限制流量为热流量时,仅当至少有一个用户时。这样,我们就不会浪费资源来获取或监控没有使用的数据。5000L
意味着它在失去最后一个用户后关闭之前等待5000ms。这避免了当我们失去最后一个订阅者时不必要地关闭流,但很快又得到了一个新的订阅者。在Android上,这是屏幕旋转时经常发生的事情,因为订阅者会被破坏,但是在新的方向上重新创建Activity后,将创建相同内容的新订阅者。我们希望避免从头开始重新启动流,以便它可以快速显示最新的数据。