美文网首页Android Kotlin
Kotlin协程之一文看懂StateFlow和SharedFlo

Kotlin协程之一文看懂StateFlow和SharedFlo

作者: 像程序那样去思考 | 来源:发表于2022-11-24 22:17 被阅读0次

    概述

    Android 架构经过多年的发展和迭代,目前最常用的应该是 MVVM 了,至于 MVI 架构,在实际开发中我看到的比较少,但无论是哪一款,都是使用分层的架构思想,引用一张官网的推荐架构图:

    对于 UI Layer, 我们一般有两个组件:

    • View: 处理 UI 展现,用户事件监听,页面跳转等,比如说 Activity 和 Fragment
    • ViewModel: 向 View 提供数据

    这二者通常通过响应式编程来处理它们之间的交互,View 订阅 ViewModel 暴露的响应式接口,接收到通知后进行相应逻辑,而 ViewModel 不再持有任何形式的 View 的引用。常用的响应式组件有 LiveData, RxJava, Flow 等:

    • RxJava: 个人很少使用,倒不是因为它不好,而是...一直傻傻不太会用 RxJava 的操作符,看不太懂,又一直没花时间(懒惰)去研究它那些操作符的原理,就不怎么敢用。
    • LiveData: 在很长一段时间里,这个组件简直是我(们大家)的宝贝,简单,上手快,又能满足大多数场景的需求,感恩。
    • Flow: 流传它想要取代 LiveData, 网上也有一些从 LiveData 迁移到 Flow 的文章。

    个人看来,LiveData 不至于真的被替换掉,因为它有很多优势,比如说使用简单,轻量级,可感知生命周期,可观察,粘性(优缺视使用场景而定)等;所以一般而言,对于 View 和 ViewModel 之间简单的响应式开发,使用 LiveData 就足够了,毕竟合适的才是最好的,而对于 UI Layer 之外的复杂场景,可以考虑使用 Flow 用来处理异步数据流。

    之前有分析过基础的 Flow 工作原理,这篇文章我们再看看 StateFlow 和 SharedFlow。

    Flow的三个角色

    Flow 数据流中有三个角色:

    • 生产者(Producer): 生产添加到数据流中的数据
    • 消费者(Consumer): 消费数据流中的数据
    • 中介(Intermediaries 可选): 可以修改发送到数据流的值,或修正数据流本身

    参考官方中的一段视频动画,可以很好地理解这个过程:

    不得不说,这些新知识点的学习,官方文档或者视频往往更直观易懂,网上很多文章写得也挺好的,可以用来加深理解,但建议官方文档也可以多看看。

    冷流与热流

    在前一篇文章 Flow 工作原理 中也有解析过 Flow 为什么是冷流,参考这个流程图:

    flow {} 方式(或flowOf, asFlow)创建的 Flow 实例是 SafeFlow 类型,当调用其 collect(FlowCollector) 方法时,首先会执行该 Flow 对象传入的 block 代码块,代码块中一般会有 emit 方法发射值,这个 emit 会调用到 collect 方法传入的 action 代码块。因为它在每次调用 collect 时才去触发发送数据的动作,所以说 Flow 是冷流

    即 Flow 是在消费者消费时才会生产数据,且冷流和消费者是一对一的关系,即当有多个消费者消费时,生产者是重新生产发送数据的。

    与之对应的是热流,Flow 有提供相关实现: StateFlow 和 SharedFlow 。

    StateFlow 和 SharedFlow 是热流,生产数据不依赖消费者消费,热流与消费者是一对多的关系,当有多个消费者时,它们之间的数据都是同一份。

    StateFlow

    类似 LiveData, StateFlow 也提供了 可读写只读 两个版本:

    public interface StateFlow<out T> : SharedFlow<T> {
        // StateFlow 当前的数据
        public val value: T
    }
    
    public interface MutableStateFlow<T> : StateFlow<T>, MutableSharedFlow<T> {
        public override var value: T
        public fun compareAndSet(expect: T, update: T): Boolean
    }
    

    StateFlow 与 LiveData 的定位比较类似,官方可能是想用它来取代 LiveData, 其共同点:

    • 都提供了 可读写只读 两个版本。
    • 值唯一,会把最新值重现给订阅者,即粘性。
    • 可被多个订阅者订阅(共享数据流)。
    • 子线程中多次发送数据可能会丢失数据。

    不同点:

    • StateFlow 必须传入初始值,保证值的空安全,永远有值。
    • StateFlow 可以防抖,即多次传入相同值,不会有响应(Setting a value that is [equal][Any.equals] to the previous one does nothing) 。
    • 当 View 进入 STOPPED 状态时,LiveData.observe() 会停止接收数据,而从 StateFlow 或其他 Flow collect 数据的操作并不会自动停止。如需实现相同的行为,需要从 Lifecycle.repeatOnLifecycle 块 collect 数据流。

    SharedFlow

    SharedFlow 也提供了 可读写只读 两个版本:

    public interface SharedFlow<out T> : Flow<T> {
        public val replayCache: List<T>
    }
    
    public interface MutableSharedFlow<T> : SharedFlow<T>, FlowCollector<T> {
        override suspend fun emit(value: T)
        public fun tryEmit(value: T): Boolean
        public val subscriptionCount: StateFlow<Int>
        public fun resetReplayCache()
    }
    

    与 StateFlow 的区别:

    • SharedFlow 没有初始值,StateFlow 必须传初始值。
    • SharedFlow 可以保留历史数据,新订阅者可以获取到之前发射过的一系列数据,StateFlow 只保留最新数据。
    • SharedFlow 可以传入一个 replay 参数,它表示可以对新订阅者重新发送 replay 个历史数据,默认值为 0, 即非粘性。
    • StateFlow 可以看成是一个 replay = 1 且没有缓冲区的 SharedFlow 。
    • SharedFlow 在子线程中多次 emit() 不会丢失数据。

    State 和 Event

    根据 Android developers 上的官方示例,可以看出 StateFlow 和 SharedFlow 分别是用来处理 状态(state)事件(event) 的,它称呼 StateFlow 是 a state-holder observable

    val uiState: StateFlow<LatestNewsUiState>
    
    val tickFlow: SharedFlow<Event<String>>
    
    • 对 UI 而言,state 是 UI 组件的状态,它应当始终都有一个值来表示其状态,且当有新的订阅者加入时,它也应知道当前的状态,即 StateFlow 的粘性。
    • 而 event 事件只有在发生某些动作后才会触发,不需要有初始值。SharedFlow 默认非粘性的,当新的订阅者加入时,它不会重复发生已经发生过的事件。
    • 对于状态而言,即使多次发送,我们只关注最新的状态;对于事件而言,如果多次发送,我们不想丢失任何一个前台的事件。

    SharedFlow 使用

    创建 SharedFlow

    看看 SharedFlow 的构造函数:

    public fun <T> MutableSharedFlow(
        replay: Int = 0,
        extraBufferCapacity: Int = 0,
        onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND
    ): MutableSharedFlow<T>
    

    主要有三个参数:

    • replay: 新订阅者 collect 时,发送 replay 个历史数据给它,默认新订阅者不会获取以前的数据。
    • extraBufferCapacity: MutableSharedFlow 缓存的数据个数为 replay + extraBufferCapacity; 缓存一方面用于粘性事件的发送,另一方面也为了处理背压问题,既下游的消费者的消费速度低于上游生产者的生产速度时,数据会被放在缓存中。
    • onBufferOverflow: 背压处理策略,缓存区满后怎么处理(挂起或丢弃数据),默认挂起。注意,当没有订阅者时,只有最近 replay 个数的数据会存入缓存区,不会触发 onBufferOverflow 策略。

    下面演示一下 MutableSharedFlow 的创建及其参数的作用。

    在 ViewModel 中发射数据

    class MainViewModel(): CoroutineScope by CoroutineScope(Dispatchers.IO + SupervisorJob()) {
        private val _data1: MutableSharedFlow<Int> = MutableSharedFlow(
            replay = 10
        )
        val data1: SharedFlow<Int> = _data1
    
        fun refresh() {
            var cur = 1
            launch {
                repeat(200) {
                    delay(20)
                    _data1.emit(cur)
                    println("emit data: ${cur++}")
                }
            }
        }
    }
    

    订阅数据

    class MainActivity : BaseActivity(), CoroutineScope by MainScope() {
        override fun onCreate(savedInstanceState: Bundle?) {
            job = launch { // 订阅 data1
                lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
                    viewModel.data1.collect {
                        delay(100) // 消费速度慢于生产速度
                        println("data: $it")
                    }
                }
            }
        }
    
        fun click(view: View) {
            launch {
                viewModel.refresh() // 触发数据生产
                delay(2000)
                job?.cancel() // 2s 后停止订阅
                delay(2000)
                lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
                    viewModel.data1.collect { // 2s 后继续订阅
                        delay(100)
                        println("data again: $it")
                    }
                }
            }
        }
    }
    

    看看输出

    // 首先消费速度慢于生产速度
    System.out: emit data: 1
    System.out: emit data: 2
    System.out: emit data: 3
    System.out: emit data: 4
    System.out: emit data: 5
    System.out: data: 1
    System.out: emit data: 6
    System.out: emit data: 7
    System.out: emit data: 8
    System.out: emit data: 9
    System.out: emit data: 10
    System.out: data: 2
    // 接着缓存区满了,消费了一个数据后,缓存区才够存储新的数据
    System.out: emit data: 11
    System.out: emit data: 12
    System.out: emit data: 13
    System.out: data: 3
    System.out: emit data: 14
    System.out: data: 4
    System.out: emit data: 15
    // ...
    // 2s 后取消了订阅,生产者发送数据就不受 onBufferOverflow 影响了,只会把最新的 10 条数据存入缓存区
    System.out: emit data: 29
    System.out: data: 19
    System.out: emit data: 30
    System.out: emit data: 31
    System.out: emit data: 32
    System.out: emit data: 33
    System.out: emit data: 34
    System.out: emit data: 35
    System.out: emit data: 36
    System.out: emit data: 37
    // ...
    // 接着 2s 后又继续订阅,订阅者消费的第一条数据是 113, 可以看到恰好是生产者生产的前 10 条数据
    System.out: emit data: 121
    System.out: emit data: 122
    System.out: emit data: 123
    System.out: data again: 113
    System.out: emit data: 124
    System.out: data again: 114
    System.out: emit data: 125
    System.out: data again: 115
    System.out: emit data: 126
    System.out: data again: 116
    System.out: emit data: 127
    

    shareIn 转换

    可以使用 shareIn 方法把普通 flow 冷流转化成 SharedFlow 热流。通过 shareIn 创建的 SharedFlow 会把数据供给 View 订阅,同时也会订阅上游的数据流:

    public fun <T> Flow<T>.shareIn(
        scope: CoroutineScope,
        started: SharingStarted,
        replay: Int = 0
    ): SharedFlow<T>
    

    有三个参数:

    • scope: 用于共享数据流的 CoroutineScope, 此作用域函数的生命周期应长于任何使用方,使共享数据流在足够长的时间内保持活跃状态。
    • started: 启动策略
    • replay: 同上 replay 含义

    started 有三种取值:

    • Eagerly: 立即启动,到 scope 作用域被结束时停止
    • Lazily: 当存在首个订阅者时启动,到 scope 作用域被结束时停止
    • WhileSubscribed: 在没有订阅者的情况下取消订阅上游数据流,避免不必要的资源浪费

    对于只执行一次的操作,可以使用 Lazily 或 Eagerly, 否则可以使用 WhileSubscribed 来实现一些优化。

    public fun WhileSubscribed(
        stopTimeoutMillis: Long = 0,
        replayExpirationMillis: Long = Long.MAX_VALUE
    ): SharingStarted
    

    它支持两个参数:

    • stopTimeoutMillis: 最后一个订阅者结束订阅后多久停止订阅上游流
    • replayExpirationMillis: 数据 replay 的过时时间,超出时间后,新订阅者不会收到历史数据

    简单示例

    Repository 层

    class MainRepository {
        private val _data: MutableSharedFlow<Int> = MutableSharedFlow()
        val data: SharedFlow<Int> = _data
    
        suspend fun request() {
            var cur = 1
            repeat(100) {
                delay(100)
                _data.emit(cur) // 模拟生产数据
                println("emit data: ${cur++}")
            }
        }
    }
    

    ViewModel 层

    class MainViewModel(
        private val repository: MainRepository
    ) : CoroutineScope by CoroutineScope(Dispatchers.IO + SupervisorJob()) {
        val data by lazy {
            repository.data.shareIn(
                scope = this,
                started = SharingStarted.WhileSubscribed(5000)
            ).onEach {
                println("repository data: $it")
            }.map {
                // 转换数据
                "UI Data-$it"
            }
        }
        private val _state = MutableStateFlow(MainState.INIT)
        val state: StateFlow<MainState> = _state
    
        fun refresh() {
            launch {
                _state.value = MainState.LOADING
                repository.request()
                _state.value = MainState.INIT
            }
        }
    }
    

    View 层

    jobData = launch {
        lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
            viewModel.data.collect {
                println("data: $it")
            }
        }
    }
    jobState = launch {
        lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
            viewModel.state.collect {
                println("state: $it")
            }
        }
    }
    

    StateFlow 使用

    创建 StateFlow

    看看 StateFlow 的构造函数:

    public fun <T> MutableStateFlow(value: T): MutableStateFlow<T>
    

    构造函数只需传入一个初始值,它本质上是一个 replay = 1 且没有缓冲区的 SharedFlow, 因此在第一次订阅时会先获取到初始值。

    stateIn 转换

    和 SharedFlow 类似,也可以用 stateIn 将普通流转化成 StateFlow:

    public fun <T> Flow<T>.stateIn(
        scope: CoroutineScope,
        started: SharingStarted,
        initialValue: T
    ): StateFlow<T>
    

    跟 shareIn 不同的是需要传入一个初始值。

    总结

    个人看来,LiveData 不至于真的被替换掉,因为它有很多优势,比如说使用简单,轻量级,可感知生命周期,可观察等。简单的组件可能功能不够强大,强大的组件用起来一般都比较复杂,二者不可兼得,然而无论是组件还是架构,合适的才是最好的,我们在选择某个组件或者某种架构的时候,需要结合自身项目和需求的特点,选择合适的即可。

    一般而言,对于 View 和 ViewModel 之间简单的响应式开发,使用 LiveData 就足够了,而对于一些复杂场景(切换线程,数据流变换等),可以考虑使用 Flow 来处理异步数据流。

    作者:苍耳叔叔
    链接:https://juejin.cn/post/7169843775240405022
    来源:稀土掘金

    相关文章

      网友评论

        本文标题:Kotlin协程之一文看懂StateFlow和SharedFlo

        本文链接:https://www.haomeiwen.com/subject/iooxfdtx.html