kotlin 02flow-sharedFlow 完整教程

发布于:2025-05-08 ⋅ 阅读:(74) ⋅ 点赞:(0)

一 sharedFlow是什么

SharedFlow 是 Kotlin 协程中 Flow 的一种 热流(Hot Flow),用于在多个订阅者之间 共享事件或数据流。它适合处理 一次性事件(如导航、弹窗、Toast、刷新通知等),而不是持续状态。


✅ SharedFlow 是什么?

SharedFlowFlow 的一种扩展,具备以下特点:

特性 描述
热流 一旦被触发,即使没人监听也会发出
多订阅者 所有活跃订阅者都能收到事件
不保留最新值(除非设置 replay) 不像 StateFlow 那样始终有个当前值
可配置 buffer 和回放(replay) 控制事件是否缓存、丢弃或排队

它本质上是一个“事件广播器”。


✅ 常见使用场景

📍 1. 一次性 UI 事件

  • Toast 弹窗
  • SnackBar 提示
  • 导航跳转
  • 关闭页面
  • 对话框展示/取消

这些事件都是“一次性的”,不需要保存状态,也不该重复触发,因此适合 SharedFlow

sealed class UiEvent {
    data class ShowToast(val message: String) : UiEvent()
    object NavigateToHome : UiEvent()
}
// ViewModel 中
private val _uiEvent = MutableSharedFlow<UiEvent>()
val uiEvent = _uiEvent.asSharedFlow()

fun loginSuccess() {
    viewModelScope.launch {
        _uiEvent.emit(UiEvent.NavigateToHome)
    }
}
// Fragment 中
lifecycleScope.launchWhenStarted {
    viewModel.uiEvent.collect { event ->
        when (event) {
            is UiEvent.ShowToast -> showToast(event.message)
            is UiEvent.NavigateToHome -> navigate()
        }
    }
}

📍 2. 流式通知

  • 通知其他模块刷新数据
  • 数据拉取完成通知页面更新
  • ViewModel 向 UI 发信号

📍 3. 替代 LiveData<Event> 解决重复消费问题

传统用 LiveData<Event<T>>SingleLiveEvent 处理一次性事件,代码复杂、不优雅,而 SharedFlow 是官方推荐的替代方案。


✅ 在公司项目中,SharedFlow 的典型用法

使用方式
ViewModel 使用 MutableSharedFlow 发送事件
UI(Activity/Fragment) 使用 collect 监听事件,做 UI 响应
工具类/中间层 也可以用于广播通知、分发事件

示例:登录成功后跳转 + 弹出 Toast

// ViewModel
val eventFlow = MutableSharedFlow<UiEvent>()

suspend fun login(username: String, pwd: String) {
    if (doLogin(username, pwd)) {
        eventFlow.emit(UiEvent.ShowToast("登录成功"))
        eventFlow.emit(UiEvent.NavigateHome)
    }
}

✅ 与其他 Flow 类型的对比

类型 是否热流 是否可变 是否保留值 场景
Flow ❌ 冷流 一次性数据流
SharedFlow ✅ 热流 ❌(可设置 replay) 一次性事件广播
StateFlow ✅ 热流 ✅(必须初始值) 状态管理(UI 状态、进度等)

✅ 总结一句话:

SharedFlow = Kotlin 中处理一次性事件的推荐工具,适合在 ViewModel → UI 层传递 Toast、导航、弹窗等短暂行为,比 LiveData 更现代、可控。


二 sharedFlow如何处理背压的?


✅ 1. SharedFlow 是如何处理被压的(Backpressure)?

SharedFlow热流(hot stream),意味着数据会立即发出,而不会像 Flow 那样等待订阅者 collect。这也就意味着:

  • 如果发射得太快(比如连续多次 emit)
  • 而订阅者还没来得及 collect
  • 数据就可能被丢弃,或缓存起来等待

这就需要一个“缓存策略”来决定怎么处理这些“来不及处理”的数据 —— 这就是 SharedFlow 的 buffer溢出策略(onBufferOverflow)


✅ 2. replay = 2, extraBufferCapacity = 5 的含义

val sharedFlow = MutableSharedFlow<Int>(
    replay = 2,
    extraBufferCapacity = 5
)

这两者分别控制了两块缓存区域:

参数 含义
replay = 2 每个新订阅者会 立刻收到前 2 条值(即“回放值”)
extraBufferCapacity = 5 除了 replay 缓冲区之外,还允许临时缓存 最多 5 条数据

💡 总缓冲区大小 = replay + extraBufferCapacity

即上面的配置,总共可以缓冲 最多 7 条数据

这意味着在没有 collect 的情况下,可以最多 emit 7 条数据不会失败或丢失。


✅ 3. onBufferOverflow = DROP_OLDEST / DROP_LATEST / SUSPEND 是什么?

这是控制当 缓冲区已满时,继续 emit 会怎么处理的策略。

支持的策略:

策略名 解释
DROP_OLDEST 丢掉最早 emit 的一条数据(先进先出)
DROP_LATEST 丢掉新发射的数据(调用的 emit)
SUSPEND(默认) 挂起 emit 调用,直到 buffer 有空间(安全但可能阻塞)

示例说明:

val flow = MutableSharedFlow<Int>(
    replay = 1,
    extraBufferCapacity = 2,
    onBufferOverflow = BufferOverflow.DROP_OLDEST
)

此时总 buffer 是 3 条:

  • 如果连续 emit 第 1、2、3 条 → 都能进 buffer。
  • 如果 emit 第 4 条时还没人 collect → buffer 满了。
  • DROP_OLDEST 策略:会把 第 1 条值移除,保留 2、3、4。

🔄 emit() 和 tryEmit() 的区别:

  • emit()挂起函数,可能会 suspend(如果 buffer 满且策略是 SUSPEND)。
  • tryEmit()非挂起,返回 true/false 表示是否成功发射。

✅ 总结一句话:

配置项 意义
replay 新订阅者能收到多少“历史值”
extraBufferCapacity 在未 collect 情况下,能暂存多少新值
onBufferOverflow 当缓存已满,是否丢老的、丢新的,或挂起等候
总缓存 replay + extraBufferCapacity 条数据