Kotlin中MutableSharedFlow无法重复触发onSubscription的问题

核心逻辑澄清 #

首先明确：MutableSharedFlow的onSubscription回调只在订阅关系建立时触发一次，并非每次发送事件都会执行。如果你的预期是每次emit都触发它，这属于对API的理解偏差。

如果是后续emit的事件没被collect接收，但日志显示emit已执行，大概率是以下几个原因：

1. Mutex使用不当导致阻塞或订阅中断 #

用Mutex实现单线程队列时，必须保证锁的正确释放，否则会阻塞后续所有emit操作。正确的写法是将临界区逻辑包裹在try-finally中：

suspend fun add() {
    mutex.lock()
    try {
        // 业务计算逻辑
        _sharedFlow.emit(updatedValue)
    } finally {
        mutex.unlock() // 无论是否异常，都要释放锁
    }
}

如果没在finally中释放锁，一旦中间抛出异常，后续的emit会一直处于挂起阻塞状态，看起来像是执行了但实际没完成。

2. 订阅协程被意外取消 #

比如在MainActivity中用lifecycleScope.launch直接collect时，若Activity进入后台，lifecycleScope的协程会被自动取消，后续emit的事件自然收不到。

3. SharedFlow缓存配置不匹配 #

默认创建的MutableSharedFlow（replay=0, extraBufferCapacity=0, onBufferOverflow=SUSPEND）会在订阅者挂起时，让新的emit也挂起等待。如果Add按钮的delay导致订阅者协程暂时挂起，后续emit会被阻塞，直到前面的操作完成。

对应解决方案 #

• 调整事件处理逻辑：如果需要每次处理事件前执行代码，不要放在onSubscription里，直接写在collect的代码块开头：

viewModel.numberFlow.collect { value ->
    // 这里写原计划放在onSubscription的逻辑（如果是每次处理事件都要执行的话）
    updateDisplayValue(value)
}

• 规范Mutex使用：严格用try-finally包裹临界区，确保锁的释放。
• 绑定订阅到生命周期：用repeatOnLifecycle确保只有Activity在前台时保持订阅，后台自动取消，前台恢复时重新订阅（此时会触发onSubscription）：

// MainActivity中
lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.numberFlow
            .onSubscription {
                // 仅在订阅建立时执行，比如初始化操作
            }
            .collect { value ->
                // 处理事件更新UI
            }
    }
}

• 调整SharedFlow缓存参数：如果需要在订阅者暂时挂起时缓存事件，可以设置extraBufferCapacity：

private val _numberFlow = MutableSharedFlow<Int>(extraBufferCapacity = 5)

内容的提问来源于stack exchange，提问作者Compose Learner