开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 21 天，[点击查看活动详情](https://juejin.cn/post/7194721470063312933?utm_source=push&utm_medium=web&utm_campaign=gengwen202302) 续接上文: [轻松搞定Kotlin的Flow, ChannelFlow和CallbackFlow - 1](https://juejin.cn/post/7201892702182260797) # ChannelFlow 现在我们已经了解了Flow的缓冲区, 让我们看看Flow和ChannelFlow之间有什么区别. ## 1. ChannelFlow是有缓冲区的Flow 如果我们的代码如下: ``` fun main() = runBlocking { channelFlow { for (i in 1..5) { println("Emitting $i") send(i) } } .collect { value -> delay(100) println("Consuming $value") } } ``` 你能看到结果如下: ``` Emitting 1 Emitting 2 Emitting 3 Emitting 4 Emitting 5 Consuming 1 Consuming 2 Consuming 3 Consuming 4 Consuming 5 ``` 看起来像常规的`flow`使用了`.buffer(3)`. 但是它有更多的缓冲, 默认大小是64. ![1_bZxMWDDBrM4NWLsxWbpAhg.webp](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/24a9c480d1d942708d87dc99a8a1da3e~tplv-k3u1fbpfcp-watermark.image?) 要想增(或减)缓冲区, 可以在`channelFlow`上使用`buffer`. ## 2. ChannelFlow能够执行异步处理(比如合并) 假设我有下面的输入flow: ``` val myAbcFlow = flow { ('A'..'E').forEach { delay(50) emit(it) } } val my123Flow = flow { (1..5).forEach { delay(50) emit(it) } } ``` 我计算用下面的代码来合并该流: ``` fun Flow.flowMerge(other: Flow): Flow = flow { collect { emit(it) } other.collect { emit(it) } } ``` 当我合并它们的时候: ``` my123Flow.flowMerge(myAbcFlow).collect { delay(50) print("$it ") } ``` 结果如下: ``` 1 2 3 4 5 A B C D E ``` ![1_SHmPZK1bHZ5OHf9kAEp5ng.webp](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c21e961839a2458fad3693b051c40132~tplv-k3u1fbpfcp-watermark.image?) 发谢的顺序与合并过程中的顺序一样. `collect { emit(it) }`必须在执行`other.collect { emit(it) }`之前完成. 我们不能让它用`launch`异步处理, 因为它不是CoroutineScope的一部分. ``` fun Flow.flowMerge(other: Flow): Flow = flow { launch { // ERROR HERE. collect { emit(it) } } other.collect { emit(it) } } ``` 我们甚至不能自作聪明, 试图做以下的事情: ``` fun Flow.flowMerge(other: Flow): Flow = flow { CoroutineScope(Dispatchers.Main).launch { collect { emit(it) } } other.collect { emit(it) } } ``` 它可以编译, 但在运行时将出错: ``` FlowCollector is not thread-safe and concurrent emissions are prohibited. To mitigate this restriction please use 'channelFlow' builder instead of 'flow' ``` 有了这个, `channelFlow`就发挥作用了. ``` fun Flow.channelMerge(other: Flow): Flow = channelFlow{ launch { // THIS IS OKAY collect { send(it) } } other.collect { send(it) } } ``` 我们将得到结果如下: ``` A 1 B 2 C 3 D 4 E 5 ``` ![1_sKyJdZ6ZuZxcBivxlnnmCw.webp](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/ca0c2378fa9b41c790c7746dbd8350c5~tplv-k3u1fbpfcp-watermark.image?) 下面的收集操作将不再阻塞: ``` launch { collect { send(it) } } ``` 由此其它的收集操作可以并行完成: ``` other.collect { send(it) } ``` 因此加快了整个过程, 同时使合并工作交替进行. ## 3. ChannelFlow能够保持开放当我们执行以下流程时: ``` flow { for (i in 1..5) emit(i) } .collect { println(it) } ``` 完成. 结束. 同样地, 我们也可以将此应用于ChannelFlow: ``` channelFlow { for (i in 1..5) send(i) } .collect { println(it) } ``` 完成. 结束. 如果数据来自另一个来源, 而我们想保持流量开放呢? 你想让它变得"更热", 也就是说, 数据可以在上面的ChannelFlow lambda函数之外继续来. ![1_xmjuJxt2I6SfpEsKgKgvbw.webp](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0037f1700db143ad8eb4eb116fbc52ef~tplv-k3u1fbpfcp-watermark.image?) 在正常情况下, 这是不可能的.在完成Channel Flow lambda后, Channel Flow将被关闭. 然而, 对于Channel Flow, 我们可以在Lambda的末尾添加一个特殊的函数`awaitClose()`. ``` channelFlow { for (i in 1..5) send(i) awaitClose() } .collect { println(it) } ``` 这将防止该函数在Lamda之后也被关闭. 为了扩展在`channelFlow`在lambda之后发送数据的能力, 我们可以将`send`函数分配给外面的一个变量函数, 如下所示, 即`sendData`: ``` fun main(): Unit = runBlocking { var sendData: suspend (data: Int) -> Unit = { } var closeChannel: () -> Unit = { } launch { channelFlow { for (i in 1..5) send(i) sendData = { data -> send(data) } closeChannel = { close() } awaitClose { sendData = {} closeChannel = {} } } .collect { println(it) } } delay(10) println("Sending 6") sendData(6) closeChannel() } ``` 我们现在能够在`channelFlow` lambda之后`sendData`了. 我们也能够像上面展示的一样, 使用`closeChannel`函数舶关闭channel, `closeChannel`将在lambda内部调用`close()`. ## 4. ChannelFlow能够发送非挂起数据我们在用`flow`的时候, 必须得用`emit`, 因为它是挂起函数. ``` public suspend fun emit(value: T) ``` 在`channelFlow`中, 我们使用了`send`, 同样也是因为它是挂起函数. ``` public suspend fun send(element: E) ``` 如果我们想发送不在暂停模式下的数据, 这是有限制的. 在`channelFlow`中, 我们有`trySend`, 但它却不是挂起函数. ``` public fun trySend(element: E): ChannelResult ``` 它将允许人们在不需要挂起函数的情况下进行发送. ``` fun main(): Unit = runBlocking { var sendData: (data: Int) -> Unit = { } // Not suspending var closeChannel: () -> Unit = { } launch { channelFlow { for (i in 1..5) trySend(i) sendData = { data -> trySend(data) } closeChannel = { close() } awaitClose { sendData = {} closeChannel = {} } } .collect { println(it) } } delay(10) println("Sending 6") sendData(6) closeChannel() sendData(7) } ``` 注意, `trySend`在流被关闭的情况下很有用, 它将使用`ChannelResult`返回状态而不是崩溃. 除了`trySend`之外, 还有`trySendBlocking`. 它是: ``` public fun SendChannel.trySendBlocking(element: E) : ChannelResult { /* * Sent successfully -- bail out. * But failure may indicate either that the channel it full * or that * it is close. Go to slow path on failure to simplify the * successful path and * to materialize default exception. */ trySend(element).onSuccess { return ChannelResult.success(Unit) } return runBlocking { val r = runCatching { send(element) } if (r.isSuccess) ChannelResult.success(Unit) else ChannelResult.closed(r.exceptionOrNull()) } } ``` 借此: - `trySend`如果缓冲区满了, 将不发送数据, 并执行下一次`trySend`. - `trySendBlocking`如果缓冲区满了, 将不发送数据, 而是等待缓冲区可用时再`trySendBlocking`. # CallbackFlow 对于`channelFlow`, 当我们使用`awaitClose()`时, 表明我们希望它的行为是对其lambda的回调. 如果我们需要设置任何回调, 对我们来说, 设置`awaitClose()`是很重要的. 为了确保我们记得使用`awaitClose()`, 我们可以使用`callbackFlow`来代替`channelFlow`, 而`callbackFlow`本质上是`channelFlow`, 并强制使用`awaitClose()`. 如果我们不对`callbackFlow`使用`awaitClose()`, 你会得到一个运行时错误, 即: ``` Exception in thread "main" java.lang.IllegalStateException: 'awaitClose { yourCallbackOrListener.cancel() }' should be used in the end of callbackFlow block. Otherwise, a callback/listener may leak in case of external cancellation. ``` # 如果channelFlow比flow好得多, 为什么还要用flow? 最初, 我在想, `flow`只能做`channelFlow`能做的事情的一个子集. 认为`channelFlow`是`flow`的一个超集. 然后我了解到`flow`在默认情况下与`channelFlow`的行为略有不同, 正如下面的文章所描述的那样: [Kotlin的ChannelFlow与Flow并不相同](https://medium.com/mobile-app-development-publication/kotlins-channel-flow-with-rendezvous-is-not-the-same-as-kotlin-flow-dfb5cff235d5) [它们也许相似, 但行为确不相同](https://medium.com/mobile-app-development-publication/kotlins-channel-flow-with-rendezvous-is-not-the-same-as-kotlin-flow-dfb5cff235d5) 除此之外, 与`channelFlow`相比, `flow`的重量也更轻. 如果我们只用`emit`和`send`, 来比较 ``` fun main() = runBlocking { val x = 10000000 val time = measureNanoTime { channelFlow { for (i in 1..x) { send(i) } } .collect {} } println(time) } ``` 和 ``` fun main() = runBlocking { val x = 10000000 val time = measureNanoTime { flow { for (i in 1..x) { emit(i) } } .collect {} } println(time) } ``` 结果如下: ![1_qhStpAqJU49-VnBhOO5jTw.webp](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/07866b48dda34d9ca4782a080f2ee55a~tplv-k3u1fbpfcp-watermark.image?) 很明显, 我们可以看到, `flow`在默认情况下比`channelFlow`重量轻. 所以简而言之, 使用`flow`, 除非你需要`channelFlow`的铃声和口哨. # TL; DR; 如果`flow`满足你的需要, 就使用`flow`. 如果你在`flow`内需要缓冲区和异步, 使用`channelFlow`. 如果你需要在`flow`之外发送数据, 使用`callbackFlow`与`awaitClose`. 开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 21 天，[点击查看活动详情](https://juejin.cn/post/7194721470063312933?utm_source=push&utm_medium=web&utm_campaign=gengwen202302)