我最近正在学习和阅读有关Flow和Kotlin Coroutines的很多文章。但是我仍然感到困惑,何时应使用Flow
和何时应使用Channel
。
一开始它看起来更简单。使用热数据流? Channel
。冷的? Flows
。如果您需要从多个地方监听数据流,情况也是这样,如果是Channel
是一个不错的选择。仍然有很多例子和问题。
但是最近引入了FlowChannels
,以及大量鼓励使用Flow
的方法和类,以及将Channels
转换为Flows
的工具,依此类推。随着Kotlin发行版中所有这些新内容和新内容的出现,我开始变得越来越困惑。所以问题是:
我什么时候应该使用Channel,什么时候应该使用Flow?
希望SO社区能够对此清除思路!
非常感谢您!
答案 0 :(得分:2)
我认为(Roman Elizarov) Cold flows, hot channels是一个很好的解释:
渠道非常适合对本质上很热的数据源进行建模,这些数据源在没有应用程序要求的情况下存在:传入网络连接,事件流等。 就像期货一样,渠道也是同步原语。当您需要以相同或不同的过程将数据从一个协程发送到另一个协程时,应使用一个通道
但是,如果我们不需要并发或同步,而只需要非阻塞数据流怎么办?直到最近我们还没有这种类型,所以欢迎Kotlin Flow 类型...
与渠道不同,流本质上不涉及任何并发。它们是非阻塞的,但是是顺序的。流的目标是使异步数据流的悬浮功能成为异步操作,即方便,安全,易学易用。
答案 1 :(得分:1)
对于许多迄今为止最好的工具是Channel
的用例,Flow
已成为新的最好的工具。
作为一个具体示例,callbackFlow
现在是从第三方API的回调中接收数据的最佳方法。这在GUI设置中特别有效。它将回调,通道和相关的接收协程耦合在一起,它们都在同一个独立的Flow
实例中。仅在收集流时才注册回调。取消流程会自动传播到关闭通道并注销回调。您只需要提供一次回调注销代码。
您应该将Channel
视作Flow
在其实现中使用的较低级原语。仅在意识到Flow
不符合您的要求之后,考虑直接使用它。