【译】Koltin协程：First things first

原文：Coroutines: First things first
作者：Manuel Vivo
译者：Luckykelan

这一系列的博客文章深入讨论了Kotlin协程中的取消和异常。为了避免浪费内存和电池寿命，协程的取消至关重要；正确的异常处理是获得良好用户体验的关键。作为本系列其他两部分(第2部分：取消，第3部分：异常)的基础，这篇博客定义一些协程的核心概念，如协程作用域、Job和协程上下文等。

协程作用域（CoroutineScope）

CoroutineScope 会跟踪使用launch 或async 创建的任何协程(这些是CoroutineScope 上的扩展函数)，并且可以在任何时间点通过调用scope.cancel() 取消正在此上下文中进行的协程。
每当我们想在我们的APP中启动并控制一个协程的生命周期时，都应该创建一个 CoroutineScope 对象，在Android平台，已有KTX库提供了某些具有生命周期的类的 CoroutineScope ，如 viewModelScope 和 lifecycleScope 。在创建 CoroutineScope 时，它将一个 CoroutineContext 对象作为构造参数，你可以使用如下代码创建新的协程作用域并使用它启动一个协程：

// Job and Dispatcher组成一个新的CoroutineScope
// 我们稍后进行讨论
val scope = CoroutineScope(Job() + Dispatchers.Main)
val job = scope.launch {
    // new coroutine
}

Job

Job是协程的句柄，对于您通过 launch 或 async 启动的每个协程，它都会返回一个Job实例，该实例唯一地标识了此协程并管理其生命周期。正如上面的代码，您还可以将Job对象传递给 CoroutineScope 来保持对此协程生命周期的控制。

协程上下文（CoroutineContext）

CoroutineContext 是一组定义协程行为的元素。它由：

Job — 控制协程的生命周期。
协程调度器（ CoroutineDispatcher ）— 将协程分配到适当的线程。
CoroutineName — 协程的名称，对调试很有帮助。
CoroutineExceptionHandler — 处理未捕获的异常，将在本系列的第3部分中介绍。

当我们创建一个新的协程时，它的协程上下文都有什么呢？我们已经知道协程会返回一个新的Job 实例从而允许我们控制它的生命周期，而其余的元素将从此协程的父元素（父协程或创建它的协程作用域）继承[^译者注]。
由于协程作用域可以创建协程，并且我们可以在协程中创建更多的协程，因此会形成一个隐式的任务层次结构，在下面的代码中，除了使用协程作用域（ CoroutineScope ）创建一个新的协程外，还可以看看如何在协程中创建更多的协程：

val scope = CoroutineScope(Job() + Dispatchers.Main)
val job = scope.launch {
    // CoroutineScope作为父级的新协程
    val result = async {
        // 以协程作为父级创建的新协程
    }.await()
}

这种层次结构的根通常为最上层的协程作用域（ CoroutineScope ）。我们可以把该层次结构可视化如下：

译者注：这种任务的层次结构就是Koltin协程引以为傲的结构化并发 — 父协程可以控制和限制子线程的生命周期，子协程会继承父协程的协程上下文

Job的生命周期

Job 经历以下一系列状态：新建、活动、正在完成、已完成、正在取消和已取消状态。虽然我们无法访问状态本身，但可以访问Job 的属性: isActive 、isCancelled 和 isCompleted 。

如果协程处于活动状态，则协程失败或调用job.cancel()方法将使Job处于取消状态( isActive = false, iscancel = true )。一旦所有的子协程完成了他们的工作，协程将进入取消状态并且 isCompleted = true 。

关于父级CoroutineContext的解释

在协程的任务层次结构中，每个协程都有一个父级，可以是一个协程作用域，也可以是另一个协程。然而，协程继承的父级协程上下文可能不同于父级本身的上下文，因为协程上下文是基于这个公式计算的

父级上下文 = 默认值 + 继承的上下文 + 参数

某些元素具有默认值，如 Dispatchers.Default 是协程调度器（ CoroutineDispatcher ）的默认值，“coroutine”是 CoroutineName 的默认值。
协程会继承创建它的协程作用域或协程的 CoroutineContext 。
在协程构建器中传递的参数会优先于继承的 CoroutineContext 中的元素。

注意： CoroutineContext 可以使用+运算符组合，由于 CoroutineContext 是一组元素，因此会将加号右边的元素覆盖左侧相同的元素以创建一个新的 CoroutineContext ，如 (Dispatchers.Main, “name”) + (Dispatchers.IO) = (Dispatchers.IO, “name”)

由scope创建的协程，在它的CoroutineContext中至少拥有这些元素，CoroutineName的值为灰色原因是它来自默认值

译者注：根据CoroutineContext的源码，CoroutineContext在内部使用键值对来维护元素，比较神奇的操作是，这些键值对的键对应着值类型的伴生对象，值为这些类型的实例，所以同一类型的元素在同一个CoroutineContext中唯一。

现在我们知道了一个新的协程的父级协程上下文是什么，那么它实际的协程上下文将是：

新协程的上下文 = 父级CoroutineContext + Job()

如果使用上图的scope创建一个新协程，就像这样：

val job = scope.launch（Dispatchers.IO）{ 
    //新协程
}

那么这个新协程的协程上下文和父级协程上下文将是什么呢？请参见下图的答案！

父级上下文中的Job永远也不会与新协程的上下文的Job是同一实例，因为新协程始终会返回一个新的Job实例

我们看到父级上下文中有 Dispatchers.IO ，而不是声明 scope 时我们传入的Dispatchers.Main ，因为它被协程构建器 launch 的参数覆盖了。另外，请注意父级上下文中的Job实例是scope对象的Job，而新协程的实际Job实例是被重新分配的(绿色)。
我们将在本系列的第三部分看到，协程上下文中有一个叫 SupervisorJob 的 Job 实现， SupervisorJob 改变了 CoroutineScope 处理异常的方式。