tmacfrank

Kotlin 是一门仅在标准库中提供最基本底层 API 以便其他库能够利用协程的语言。与许多其他具有类似功能的语言不同，async与await在 Kotlin 中并不是关键字，甚至都不是标准库的一部分。此外，Kotlin 的挂起函数概念为异步操作提供了比 future 与 promise 更安全、更不易出错的抽象。kotlinx.coroutines 是由 JetBrains 开发的功能丰富的协程库。使用协程需要添加对 kotlinx-coroutines-core 模块的依赖，如。

本节将介绍在协程间如果有先后执行、互相等待的需求时，应该怎样去处理这种等待和协作的工作。更会与 Java 的线程的协作工作对比，从而说明，在线程中通常不太简单的协作操作，在协程中很容易实现。

SharedFlow 与 StateFlow 是 Flow 的两个变种，它们把 Flow 的功能从数据流的收集改成了事件流和状态的订阅，这就把适用场景切换到了一个非常实用的范围。

本篇是 Flow 操作符的第二篇文章，会讲解异常相关操作符、流程监听操作符、flowOn、buffer 操作符、Flow 合并操作符以及将 Flow 转换为其他类型的操作符。

Flow 的操作符指的是用一个或多个 Flow 对象，来创建出另一个新的 Flow 对象的函数。接下来我们会用两篇的篇幅来介绍 Flow 的常用操作符。

上一篇我们讲解了 Channel 的相关知识。Channel 是一个跨协程传递数据的工具，属于底层工具，不是拿来直接用的，尤其是在近些年 Flow API 被推出并逐渐完善之后，Channel 都不太适合当做一个上层的功能性工具来用了。如果需要事件流或数据流，还是用 Flow 比较好。Channel 现在更多是作为 Flow API 的一个关键的底层支撑而存在，它给 Flow 提供了跨协程的能力。从功能上说，Flow 更完整，使用体验更顺畅。本篇我们就开始了解 Flow 的相关内容。

前面我们讲解的 Channel 的相关知识。Channel 是一个跨协程传递数据的工具，属于底层工具，不是拿来直接用的，尤其是在近些年 Flow API 被推出以及逐渐完善之后，Channel 都不太适合当做一个上层的功能性工具来用了。如果需要事件流或数据流，还是用 Flow 比较好。Channel 现在更多是作为 Flow API 的一个关键的底层支撑而存在，它给 Flow 提供了跨协程的能力。从功能上说，Flow 更完整，使用体验更顺畅。这一篇我们就开始了解 Flow 的相关内容。

协程提供了多种 CoroutineContext：ContinuationInterceptor、Job、CoroutineExceptionHandler、CoroutineName。如果上述内容都不能满足要为 CoroutineContext 附加专属信息或专属功能的需求，就需要自定义 CoroutineContext。// 自定义的功能。

本篇将继续结构化并发的话题，来介绍结构化异常管理的相关内容。

结构化并发实际上就是父子协程关系的管理，管理父子协程之间生命周期的关联，包括正常的生命周期，以及取消和异常这些特殊情况下的生命周期。接下来我们会用两篇文章的篇幅来介绍结构化并发，第一篇介绍协程的取消，第二篇介绍协程的异常管理。本篇我们会先用代码将协程具象化，然后明确父子协程的关系是如何形成的，最后以线程结束的方式作为引导，对比引出协程的取消。

本系列文章作为 Kotlin 协程的基础讲解，会介绍协程的概念、用法与适用场景，此外还会介绍与协程紧密相关的 Flow 的相关知识。首篇会先介绍协程的基本概念与使用方法。

Flow 与 Jetpack Paging3 Demo。

（P92~P94）我们会将几个 Flow 的应用实例放在同一个 Demo 中，主页就是一个 Activity 里包含一个按钮，点击按钮跳转到对应的功能展示页面上。整体架构采用一个 Activity 多个 Fragment 的结构，结合 Jetpack 的 Navigation 和 Room 框架。配置上在 build.gradle 中导入依赖，开启 ViewBinding：接下来对 MainActivity 进行 ViewBinding 初始化：Activity 初始化完成，然后就应该创建主 Fragm

这里有一个小技巧就是 async 正常应该是在协程环境中使用的，粗暴的方式是直接 GlobalScope.async，但是由于 GlobalScope 会造成内存泄漏，因此稍好一点的方式就是将两个函数从原本的挂起函数改造成 CoroutineScope 的扩展函数。实际上跟线程是一样的，共享变量 count 被多个线程操作，由于 count++ 不是原子操作，所以某个线程在取 count 的值时，可能不是 count 最新的值，而是自加前的老值，因此最终结果小于 1000。

*如何理解流的上下文保存：**流的上下文保存指的是在 Kotlin 流（Flow）中，流的操作会继承之前操作中设置的上下文，这种行为被称为上下文保存。**流上下文与协程上下文是否相同：**在 Kotlin 中，流（Flow）的上下文通常是与协程的上下文相关联的，但它们并不完全相同。**流的上下文：**在 Kotlin 中，流（Flow）可以与协程的上下文（Coroutine Context）一起使用，以控制流的执行环境和调度方式。流的上下文用于控制流的执行环境，而协程的上下文用于控制整个协程的执行环境。

Job：控制协程的生命周期CoroutineDispatcher：向合适的线程分发任务CoroutineName：协程名称，调试时很有用CoroutineExceptionHandler：处理未被捕获的异常。

最后一种方式是 yield，会出让线程的执行权，适用于 CPU 计算特别密集，可能会耗尽 CPU 资源的情况，此时出让调度器所在的线程（池）执行权，让所有线程（包括自己）重新竞争 CPU。需要说明的是，调用 cancel 后的 join 还是需要的，因为 runBlocking 中后续可能还会执行其他的代码，这里加一个 join 意思就是你等待我取消完成后再执行其他代码。但如果是一般的父协程，父协程本身的任务与其子协程的运行顺序是不确定的，父协程有可能先运行完而不等待子协程是否运行完。

（P2）协程难在哪？（P3）协程基于线程，它是轻量级的线程。GlobalScope 作为全局作用域可能会造成内存泄漏，官方不建议使用它。而是使用 MainScope、ViewModelScope 以及 LifecycleScope 等与 Lifecycle 绑定的作用域。

除了系统提供的 4 个调度器，使用者也可以自定义线程池供协程使用。/***//***/实现了 Closeable 的对象在使用完毕后需要调用 close() 进行关闭，这一点容易被使用者忽略，因此才打了 @DelicateCoroutinesApi 注解提醒使用者。那为什么 Dispatchers 中提供的 Default 和 IO 不用手动关闭呢？因为那些是全局的，永久存活，不需要被关闭。