SharedFlow

1.SharedFlow-高配版LiveData

SharedFlow 和 StateFlow 都属于热流，无论是否有订阅者（collect），都可以生产数据并且缓存在内部的链表中。 它们都有一个可变的版本 MutableSharedFlow 和 MutableStateFlow，这与 LiveData 和 MutableLiveData 类似，对外暴露接口时，应该使用不可变的版本。

1.1 SharedFlow与MutableSharedFlow接口

public interface SharedFlow : Flow {
    // 缓存的重放数据的快照
    public val replayCache: List
}

public interface MutableSharedFlow : SharedFlow, FlowCollector {
    
    // 发射数据（注意这是个挂起函数）
    override suspend fun emit(value: T)

    // 尝试发射数据（如果缓存溢出策略是 SUSPEND，则溢出时不会挂起而是返回 false）
    public fun tryEmit(value: T): Boolean

    // 活跃订阅者数量
    public val subscriptionCount: StateFlow

    // 重置重放缓存，新订阅者只会收到注册后新发射的数据
    public fun resetReplayCache()
}

1.2构造一个ShareFlow

我会把 SharedFlow 理解为一个高配版的 LiveData，这点首先在构造函数就可以体现出来。SharedFlow 的构造函数允许我们配置三个参数：

public fun  MutableSharedFlow(
    // 重放数据个数
    replay: Int = 0,
    // 额外缓存容量
    extraBufferCapacity: Int = 0,
    // 缓存溢出策略
    onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND
): MutableSharedFlow {
    val bufferCapacity0 = replay + extraBufferCapacity
    val bufferCapacity = if (bufferCapacity0 < 0) Int.MAX_VALUE else bufferCapacity0 // coerce to MAX_VALUE on overflow
    return SharedFlowImpl(replay, bufferCapacity, onBufferOverflow)
}

public enum class BufferOverflow {
    // 挂起
    SUSPEND,
    // 丢弃最早的一个
    DROP_OLDEST,
    // 丢弃最近的一个
    DROP_LATEST
}

reply:重放数据个数，当新订阅者注册时会重放缓存replay个数。
extraBufferCapacity：额外缓存容量，在 replay 之外的额外容量，ShareFlow 的缓存容量 capacity = replay + extraBufferCapacity。
onBufferOverflow 缓存溢出策略，即缓存容量 capacity 满时的处理策略（SUSPEND、DROP_OLDEST、DROP_LAST）。

SharedFlow 默认容量 capacity 为 0，重放 replay 为 0，缓存溢出策略是 SUSPEND，意味着发射数据时会直接丢弃数据并挂起（阅读 emit 的源码），而订阅者订不会受到任何数据。

为什么我们可以把 SharedFlow 理解为 “高配版” LiveData，拿 SharedFlow 和 LiveData 做个简单的对比就知道了：

• 容量问题： LiveData 容量固定为 1 个，而 SharedFlow 容量支持配置 0 个到 多个；
• 背压问题： LiveData 无法应对背压问题，而 SharedFlow 有缓存空间能应对背压问题；
• 重放问题： LiveData 固定重放 1 个数据，而 SharedFlow 支持配置重放 0 个到多个；
• 线程问题： LiveData 只能在主线程订阅，而 SharedFlow 支持在任意线程（通过协程的 Dispatcher）订阅。

当然 SharedFlow 也并不是完胜，LiveData 能够处理生命周期安全问题，而 SharedFlow 不行（因为 Flow 本身就不是纯 Android 生态下的组件），不合理的使用会存在不必要的操作和资源浪费，以及在错误的状态更新 View 的风险。不过别担心，这个问题可以通过 Lifecycle API 来解决。

1.3 普通Flow转换为ShareFlow

前面提到过，冷流是不共享的，也没有缓存机制。使用 Flow.shareIn或 Flow.stateIn可以把冷流转换为热流，一来可以将数据共享给多个订阅者，二来可以增加缓冲机制。

public fun  Flow.shareIn(
    // 协程作用域范围
    scope: CoroutineScope,
    // 启动策略
    started: SharingStarted,
    // 控制数据重放的个数
    replay: Int = 0
): SharedFlow {
  val config = configureSharing(replay)
  val shared = MutableSharedFlow(
      replay = replay,
      extraBufferCapacity = config.extraBufferCapacity,
      onBufferOverflow = config.onBufferOverflow
  )
  @Suppress("UNCHECKED_CAST")
  scope.launchSharing(config.context, config.upstream, shared, started, NO_VALUE as T)
  return shared.asSharedFlow()
}
public companion object {
    // 热启动式：立即开始，并在 scope 指定的作用域结束时终止
    public val Eagerly: SharingStarted = StartedEagerly()
    // 懒启动式：在注册首个订阅者时开始，并在 scope 指定的作用域结束时终止
    public val Lazily: SharingStarted = StartedLazily()
 
    public fun WhileSubscribed(
        stopTimeoutMillis: Long = 0,
        replayExpirationMillis: Long = Long.MAX_VALUE
    ): SharingStarted =
        StartedWhileSubscribed(stopTimeoutMillis, replayExpirationMillis)
}

sharedIn 的参数 scope 和 replay 不需要过多解释，主要介绍下 started: SharingStarted 启动策略，分为三种：

• Eagerly（热启动式）： 立即启动数据流，并保持数据流（直到 scope 指定的作用域结束）；

• Lazily（懒启动式）： 在首个订阅者注册时启动，并保持数据流（直到 scope 指定的作用域结束）；

• WhileSubscribed()： 在首个订阅者注册时启动，并保持数据流直到在最后一个订阅者注销时结束（或直到 scope 指定的作用域结束）。通过 WhildSubscribed() 策略能够在没有订阅者的时候及时停止数据流，避免引起不必要的资源浪费，例如一直从数据库、传感器中读取数据。

whileSubscribed() 还提供了两个配置参数：

• stopTimeoutMillis 超时时间（毫秒）： 最后一个订阅者注销订阅后，保留数据流的超时时间，默认值 0 表示立刻停止。这个参数能够帮助防抖，避免订阅者临时短时间注销就马上关闭数据流。例如希望等待 5 秒后没有订阅者则停止数据流，可以使用 whileSubscribed(5000)。
• replayExpirationMillis 重放过期时间（毫秒）： 停止数据流后，保留重放数据的超时时间，默认值 Long.MAX_VALUE 表示永久保存（replayExpirationMillis 发生在停止数据流后，说明 replayExpirationMillis 时间是在 stopTimeoutMillis 之后发生的）。例如希望希望等待 5 秒后停止数据流，再等待 5 秒后的数据视为无用的陈旧数据，可以使用 whileSubscribed(5000, 5000)。

2.StateFlow-LiveData的替代品

StateFlow 是 SharedFlow 的子接口，可以理解为一个特殊的 SharedFlow。不过它们的继承关系只是接口上有继承关系，内部的实现类 SharedFlowImpl 和 StateFlowImpl 其实是分开的，这里要留个印象就好。

2.1 StateFlow 与 MutableStateFlow 接口

这里先放出这两个接口方便查看：

public interface StateFlow : SharedFlow {
    // 当前值
    public val value: T
}

public interface MutableStateFlow : StateFlow, MutableSharedFlow {
    // 当前值
    public override var value: T

    // 比较并设置（通过 equals 对比，如果值发生真实变化返回 true）
    public fun compareAndSet(expect: T, update: T): Boolean
}

2.2 构造一个StateFlow

StateFlow 的构造函数就简单多了，有且仅有一个必选的参数，代表初始值：

public fun  MutableStateFlow(value: T): MutableStateFlow = StateFlowImpl(value ?: NULL)

2.3 特殊的SharedFlow

StateFlow是SharedFlow的一种特殊配置，MutableStateFlow(initialValue) 这样一行代码本质上和下面使用 SharedFlow 的方式是完全相同的：

val shared = MutableSharedFlow(
    replay = 1,
    onBufferOverflow = BufferOverflow.DROP_OLDEST
)
shared.tryEmit(initialValue) // emit the initial value
val state = shared.distinctUntilChanged() // get StateFlow-like behavior

• 有初始值： StateFlow 初始化时必须传入初始值；
• 容量为 1： StateFlow 只会保存一个值；
• 重放为 1： StateFlow 会向新订阅者重放最新的值；
• 不支持 resetReplayCache 重置重放缓存： StateFlow 的 resetReplayCache() 方法抛出 UnsupportedOperationException
• 缓存溢出策略为 DROP_OLDEST： 意味着每次发射的新数据会覆盖旧数据；
  总的来说，StateFlow 要求传入初始值，并且仅支持保存一个最新的数据，会向新订阅者会重放一次最新值，也不允许重置重放缓存。说 StateFlow 是 LiveData 的替代品一点不为过。除此之外，StateFlow 还额外支持一些特性：
• 数据防抖： 意味着仅在更新值并且发生变化才会回调，如果更新值没有变化不会回调 collect，其实就是在发射数据时加了一层拦截：

public override var value: T
    get() = NULL.unbox(_state.value)
    set(value) { updateState(null, value ?: NULL) }

override fun compareAndSet(expect: T, update: T): Boolean =
    updateState(expect ?: NULL, update ?: NULL)

private fun updateState(expectedState: Any?, newState: Any): Boolean {
    var curSequence = 0
    var curSlots: Array? = this.slots // benign race, we will not use it
    synchronized(this) {
        val oldState = _state.value
        if (expectedState != null && oldState != expectedState) return false // CAS support
        if (oldState == newState) return true // 如果新值 equals 旧值则拦截, 但 CAS 返回 true
        _state.value = newState
        ...
        return true
    }
}

• CAS 操作： 原子性的比较与设置操作，只有在旧值与 expect 相同时返回 ture。

2.4 普通Flow转换为StateFlow

跟SharedFlow一样，普通Flow也可以转换为StateFlow

public fun  Flow.stateIn(
    // 共享开始时所在的协程作用域范围
    scope: CoroutineScope,
    // 共享开始策略
    started: SharingStarted,
    // 初始值
    initialValue: T
): StateFlow {
    val config = configureSharing(1)
    val state = MutableStateFlow(initialValue)
    scope.launchSharing(config.context, config.upstream, state, started, initialValue)
    return state.asStateFlow()
}

3.安全地观察 Flow 数据流

前面也提到了，Flow 不具备 LiveData 的生命周期感知能力，所以订阅者在监听 Flow 数据流时，会存在生命周期安全的问题。Google 推荐的做法是使用 Lifecycle#repeatOnLifecycle API：

// 从 2.4.0 开始支持 Lifecycle#repeatOnLifecycle API
implementation "androidx.lifecycle:lifecycle-runtime-ktx:2.4.1"

• Lifecycle#repeatOnLifecyclerepeatOnLifecycle 的作用相同，区别在于它是一个 suspend 函数，需要在协程中执行；
• Flow#flowWithLifecycle的作用相同，内部基于 repeatOnLifecycle API。

如果不使用 Lifecycle#repeatOnLifecycle API，具体会出现什么问题呢？

• Activity.lifecycleScope.launch： 立即启动协程，并在 Activity 销毁时取消协程；

• Fragment.lifecycleScope.launch： 立即启动协程，并在 Fragment 销毁时取消协程；

• Fragment.viewLifecycleOwner.lifecycleScope.launch： 立即启动协程，并在 Fragment 中视图销毁时取消协程。
  可以看到，这些协程 API 只有在最后组件 / 视图销毁时才会取消协程，当视图进入后台时协程并不会被取消，Flow 会持续生产数据，并且会触发更新视图。

• LifecycleContinueScope.launchWhenX： 在生命周期到达指定状态时立即启动协程执行代码块，在生命周期低于该状态时挂起（而不是取消）协程，在生命周期重新高于指定状态时，自动恢复该协程。

可以看到，这些协程 API 在视图离开某个状态时会挂起协程，能够避免更新视图。但是 Flow 会持续生产数据，也会产生一些不必要的操作和资源消耗（CPU 和内存）。 虽然可以在视图进入后台时手动取消协程，但很明显增写了模板代码，没有 repeatOnLifecycle API 来得简洁。

4.Channel通道

在协程的基础能力上使用数据流，除了上文提到到 Flow API，还有一个 Channel API。Channel 是 Kotlin 中实现跨协程数据传输的数据结构，类似于 Java 中的 BlockQueue 阻塞队列。不同之处在于 BlockQueue 会阻塞线程，而 Channel 是挂起线程。Google 的建议 是优先使用 Flow 而不是 Channel，主要原因是 Flow 会更自动地关闭数据流，而一旦 Channel 没有正常关闭，则容易造成资源泄漏。此外，Flow 相较于 Channel 提供了更明确的约束和操作符，更灵活。
需要注意，Channel 也有一个使用上的限制，当 Channel 有多个收集器时，它们不能共享 Channel 传输的数据，每个数据只能被一个收集器独享，因此 Channel 更适合一对一的通信场景。

image.png

综上，SharedFlow 和 Channel 在事件处理上各有特点，大家需要根据实际场景灵活选择：

	SharedFlow	Channel
订阅者数量	订阅者共享通知，可以实现一对多的广播	每个消息只有一个订阅者可以收到，用于一对一的通信
事件接受	collect 之前的事件会丢失	第一个订阅者可以收到 collect 之前的事件

5.浅尝一下

到这里，LiveData、Flow 和 Channel 我们都讲了一遍了，实际场景中怎么使用呢，浅尝以下。

• 事件（Event）： 事件是一次有效的，新订阅者不应该收到旧的事件，因此事件数据适合用 SharedFlow(replay=0)；
• 状态（State）： 状态是可以恢复的，新订阅者允许收到旧的状态数据，因此状态数据适合用 StateFlow。

我们从覆盖性、时效性、幂等性等三个维度列举状态和事件的具体区别

	状态	事件
覆盖性	新状态会覆盖旧状态，如果短时间内发生多次状态更新，可以抛弃中间态只保留最新状态即可。这也是为什么 LiveData 连续 postValue 时会出现数据丢失。	新事件不应该覆盖旧事件，订阅者按照发送顺序接收到所有事件，中间的事件不能遗漏。
时效性	最新状态是需要长久保持的，可以被时刻访问到，因此状态一般是“粘性的”，在新的订阅出现时为其发送最新状态。	事件只能被消费一次，消费后应该丢弃。因此事件一般不是“粘性”的，避免多次消费。
幂等性	状态是幂等的，唯一状态决定唯一UI，同样的状态无需响应多次。因此 StateFlow 在 setValue 时会对新旧数据进行比较，避免重复发送。	订阅者需要对发送的每个事件进行消费，即使是同一类事件发送多次。