Channel 与 callbackFlow：Google 为什么还要设计第三套模型？—— 从 State、Event 到 Queue，彻底串起 Kotlin Flow 体系
引言
上一篇我们讲了：
《StateFlow 与 SharedFlow：Google 为什么要设计两套 Flow？》
我们知道了：
StateFlow -> State（状态） SharedFlow -> Event（事件）很多同学学到这里会产生一个新的疑问：
既然 SharedFlow 都能发事件了， 为什么 Kotlin 协程里还有 Channel？ callbackFlow 又是什么？ 它们和 SharedFlow 有什么区别？说实话，
以前我也一直觉得：
StateFlow SharedFlow 够用了直到最近重新梳理 Flow 体系，
突然发现：
Google 设计的其实并不是几个 API。
而是几种完全不同的数据传递模型。
今天我们就把这条线彻底串起来。
一、先回顾上一篇
上一篇我们得出了一个重要结论：
StateFlow
解决：
现在是什么状态？例如：
loading userInfo pageState本质：
State（状态）SharedFlow
解决：
刚刚发生了什么事件？例如：
Toast Navigation LoginSuccess本质：
Event（事件）那么问题来了：
为什么还有 Channel？二、SharedFlow 已经能发事件了，为什么还要 Channel？
很多人第一次看到 Channel 的时候都会觉得：
这玩意是不是多余？因为：
SharedFlow已经能：
发送事件 接收事件看起来什么都能做。
实际上：
SharedFlow 和 Channel 解决的是两种完全不同的问题。
三、从现实世界理解三种模型
StateFlow —— 黑板
想象一个教室。
黑板上写着：
当前温度：25℃后来进来的学生：
也能看到25℃因为：
状态永远存在这就是：
StateFlowSharedFlow —— 广播
老师说：
今天下午停课全班同学都听到了。
特点：
一个发送者 多个接收者这就是：
SharedFlowChannel —— 消息队列
现在老师发作业。
每发一份：
被一个同学拿走拿走以后：
别人就拿不到了特点：
一条消息 只被消费一次这就是：
Channel四、我突然发现：这不就是 MQ 吗？
学到这里，我脑子里突然蹦出一个想法：
这特么不就是 MQ 吗？其实非常像。
共同模型：
Producer ↓ Queue ↓ Consumer例如：
RabbitMQ RocketMQ Kafka都是这样。
但区别也很明显。
MQ：
跨进程 跨服务器 可持久化而：
Channel只是：
同一个进程内 协程之间 内存级消息队列所以可以简单理解：
Channel = 协程版 MQ五、Android 为什么很少用 Channel？
很多同学学完 Channel 后会发现：
项目里几乎没见过原因很简单。
大多数 Android 场景：
StateFlow SharedFlow已经够用了。
例如：
Loading PageState Toast Navigation根本不需要：
消息队列所以实际项目大致是：
90% StateFlow 9% SharedFlow 1% Channel六、callbackFlow 又是什么？
学到这里，又会冒出一个新问题：
callbackFlow 是什么？例如：
定位监听
蓝牙监听
传感器监听
WebSocket监听
这些 API 长这样：
setListener { ... }属于：
Callback 模型但 Kotlin Flow 希望你：
collect怎么办？
七、callbackFlow 本质是什么？
答案其实非常优雅。
Google 给我们做了一个桥梁：
callbackFlow
例如：
fun locationFlow() = callbackFlow { val listener = object : LocationListener { override fun onLocationChanged(location: Location) { trySend(location) } } register(listener) awaitClose { unregister(listener) } }这样：
Callback就变成了：
Flow八、callbackFlow 底层到底干了什么？
理解这一张图就够了。
Callback ↓ Channel ↓ Flow ↓ collect也就是说：
外部回调来了 ↓ 塞进 Channel ↓ 转换成 Flow ↓ Collector 消费这也是为什么：
callbackFlow里面最常见的是：
trySend()而不是：
emit()因为它本质上就是：
Callback + Channel九、Flow 体系终于串起来了
到这里，
我突然发现以前学的知识终于连成了一张图。
Flow │ ├── StateFlow │ └── State │ ├── SharedFlow │ └── Event │ ├── Channel │ └── Queue │ └── callbackFlow └── Callback → Queue → Flow以前我觉得：
StateFlow SharedFlow Channel callbackFlow是四个 API。
现在发现：
它们其实是在解决四种不同的数据流动方式。
十、最终总结
StateFlow
解决：
现在是什么状态例如：
Loading UserInfo PageStateSharedFlow
解决：
刚刚发生了什么事件例如：
Toast Navigation ErrorEventChannel
解决：
消息如何排队消费例如：
任务队列 生产者消费者callbackFlow
解决：
如何把 Callback 世界接入 Flow 世界例如：
定位 蓝牙 WebSocket 传感器结语
回头看这一系列内容，
其实我最大的收获并不是学会了几个 API。
而是终于把过去那些零散的知识串成了一张图。
以前我觉得：
LiveData StateFlow SharedFlow Channel callbackFlow只是 Android 中不同的数据传递工具。
直到重新梳理 Kotlin Flow 体系之后，我才发现：
它们其实对应着四种完全不同的思维模型。
StateFlow -> State（状态） SharedFlow -> Event（事件） Channel -> Queue（队列） callbackFlow -> Callback（回调）Google 设计的并不是几个类，而是在引导开发者思考：
现在是什么状态？ 刚刚发生了什么事件？ 消息应该如何排队处理？ 传统回调如何接入协程世界？当理解了这四个模型以后，
再回头看 Flow，
你会发现很多以前觉得复杂的问题，
其实都变得非常自然。
下篇预告
前两篇我们已经建立了完整的理论体系：
State ↓ Event ↓ Queue ↓ Callback但对于 Android 开发来说，
最常见的问题其实是：
定位监听 蓝牙监听 WebSocket监听 传感器监听 下载进度监听这些 API 天生都是：
Callback而我们的业务代码却越来越希望使用：
collect()那么问题来了：
Google 到底是如何把 Callback 世界转换成 Flow 世界的？
callbackFlow 内部到底做了什么？
trySend 为什么会出现？
它和 Channel 又是什么关系？
下一篇我们继续：
《callbackFlow 实战：如何把定位、蓝牙、WebSocket 回调改造成 Flow？》
从源码到实战，
彻底讲透 Callback → Channel → Flow 的完整链路。