我最近在学习和阅读很多关于 Flow 和 Kotlin 协程的内容。但是我仍然对何时应该使用Flow 以及何时应该使用Channel 感到困惑。
一开始它看起来更简单。使用热数据流？ Channel。冷的？ Flows。如果您需要从多个地方收听数据流，也是如此；如果是这种情况，Channel 是您的选择。还有很多例子和问题。
但最近在哪里引入了FlowChannels，以及大量鼓励使用Flow 的方法和类，这些方法和类有助于将Channels 转换为Flows 等等。随着每个 Kotlin 版本中出现所有这些新东西，我越来越感到困惑。所以问题是：
什么时候应该使用Channel，什么时候应该使用Flow？
【问题讨论】：
标签： kotlin stream channel kotlin-coroutines
对于迄今为止最好的工具是Channel 的许多用例，Flow 已成为新的最佳工具。
作为一个具体示例，callbackFlow 现在是从 3rd-party API 回调接收数据的最佳方法。这在 GUI 设置中特别有效。它将回调、通道和相关的接收协程都耦合在同一个自包含的Flow 实例中。仅在收集流时注册回调。取消流程会自动传播到关闭通道和取消注册回调。您只需提供一次回调注销代码。
您应该将Channel 视为Flow 在其实现中使用的较低级别的原语。只有在您意识到 Flow 不符合您的要求后，才考虑直接使用它。
【讨论】：
我认为这里有一个很好的解释(Roman Elizarov) Cold flows, hot channels：
通道非常适合模拟本质上很热的数据源，即无需应用程序请求而存在的数据源：传入的网络连接、事件流等。 通道，就像期货一样，是同步原语。当需要将数据从一个协程发送到相同或不同进程中的另一个协程时，您应该使用通道
但是如果我们既不需要并发也不需要同步，只需要非阻塞的数据流怎么办？直到最近我们还没有这种类型，所以欢迎使用 Kotlin Flow 类型...
与通道不同，流本身并不涉及任何并发。它们是非阻塞的，但顺序的。流的目标是让异步数据流成为异步操作的挂起函数——方便、安全、易学和易用。
【讨论】：