Android开发

【译】Koltin协程:First things first

本文主要是介绍【译】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 )。我们可以把该层次结构可视化如下:

协程在任务层次结构中执行。父级可以是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 处理异常的方式。

这篇关于【译】Koltin协程:First things first的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!