Android Kotlin Coroutine(2):协程的启动以及协程上下文

前面入门时讲过一个最简单的例子,通过 GlobalScope.launch { } 可以启动一个协程,GlobalScope 可以简单理解为协程构造者,它实际上是接口 CoroutineScope 的子类,那我们来看看它到底是什么,启动一个协程需要哪些关键要素。接下来我们讲讲协程相关的几个主要类,先混个脸熟,心里有个大体概念之后,再逐步深入。

1. CoroutineScope介绍

顾名思义“协程域”,只有它能创建协程,既然是创建者,同样它能管理它所创建的协程。该接口定义如下:

public interface CoroutineScope {
    /**
     * The context of this scope.
     * Context is encapsulated by the scope and used for implementation of coroutine builders that are extensions on the scope.
     * Accessing this property in general code is not recommended for any purposes except accessing the [Job] instance for advanced usages.
     *
     * By convention, should contain an instance of a [job][Job] to enforce structured concurrency.
     */
    public val coroutineContext: CoroutineContext
}

接口定义很简单,只包含一个叫 CoroutineContext 的参数,我们称之为协程上下文,那么这又是个什么鬼?我们应该在很多地方都见过名叫上下文的东西,例如在 Android 中一个 Activity 就是上下文 Context 的子类,由此可以类推 CoroutineContext 包含了协程运行时的一些信息,具体后面再逐步介绍。我们再看看 GlobalScope 的定义:

public object GlobalScope : CoroutineScope {
    override val coroutineContext: CoroutineContext
        get() = EmptyCoroutineContext
}

原来 GlobalScope 是个类似 Java 中的单例类,它的协程上下文是个空上下文 EmptyCoroutineContext。那么协程的启动方法是在哪里定义的呢,接口里我们好像没见到。原来协程的启动方法都是通过扩展函数来定义的,它的方法签名为:

public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job

从方法定义中可以看到,协程的启动需要3个参数:context(协程上下文)、start(协程启动模式)、block(协程体),其中前2个参数都有默认值,我们例子中的代码其实只包含了协程体。协程上下文的概念很复杂,也特别难理解,我们可以将之类比为 Android 中的 Activity一样。协程体就像 Thread.run() 方法中的代码一样,协程的运行代码都应该写在里面,这个很容易理解。该方法会返回一个 Job 类型的对象,有趣的是 Job 也是继承自 CoroutineContext,可以认为协程就是一个任务。

2. CoroutineStart(启动模式)介绍

CoroutineStart 是个枚举类,其定义如下:

public enum class CoroutineStart {
    DEFAULT,
    LAZY,
    @ExperimentalCoroutinesApi
   ATOMIC,
   @ExperimentalCoroutinesApi
   UNDISPATCHED;
}

共定义了4种启动模式,但是后2种还是带有实验性质的 Api,我们分别用代码来演示它们之间的区别。

2.1 DEFAULT

这是默认的启动模式,一旦 launch 方法调用后,立即开始调度协程的执行。这种模式有点像线程调用 Thread.start() 方法之后,系统开始调度线程的执行一样。当调度 OK 之后,协程体里的代码会立即执行。

//方便打印出代码执行所在线程
fun log(o: Any?) {
    println("[${Thread.currentThread().name}]:$o")
}

GlobalScope.launch {
    log(1)
    val job = launch() {
        log(2)
    }
    log(3)
}

运行结果可能为:

[DefaultDispatcher-worker-1]:1
[DefaultDispatcher-worker-1]:3
[DefaultDispatcher-worker-1]:2
2.2 LAZY

懒加载模式,launch 方法调用后,并不会立即调度协程的执行。需要手动调用,该协程才会开始调度执行。

GlobalScope.launch {
    log(1)
    val job = launch(start = CoroutineStart.LAZY) {
        log(2)
    }
    log(3)
}

同样的代码,内部的协程启动模式换成 LAZY 之后,再看执行结果:

[DefaultDispatcher-worker-1]:1
[DefaultDispatcher-worker-1]:3

对比前面的代码,能够很明显地看出 LAZYDEFAULT 的差别。

我们修改代码为:

GlobalScope.launch {
    log(1)
    val job = launch(start = CoroutineStart.LAZY) {
        log(2)
    }
    job.join()  //等待协程的执行结果,这里会触发协程的调度执行
    log(3)
}

运行的结果为:

[DefaultDispatcher-worker-1]:1
[DefaultDispatcher-worker-1]:2
[DefaultDispatcher-worker-1]:3
2.3 ATOMIC

这种模式与 DEFAULT 类似,它也是一旦 launch 方法调用后,协程会立即开始调度执行。但很有趣的是,在协程内部没有遇到挂起函数(suspend fun)之前,它不能取消掉。

顺便说一下挂起函数,挂起函数是由 suspend 修饰的函数,它只能在协程内部或挂起函数内调用。可以简单理解为,它能"暂停"该函数的执行,当然这里并不是真的暂停,只是说协程调度器暂时不再调度该协程。

GlobalScope.launch {
    log(1)
    val job1 = launch(start = CoroutineStart.ATOMIC) {
        log(2)
        log(22)
    }
    job1.cancel()

    val job2 = launch {
        log(3)
        log(33)
    }
    job2.cancel()

    val job3 = launch(start = CoroutineStart.ATOMIC) {
        log(4)
        log(44)
        delay(100)
        log(444)
    }
    job3.cancel()

    val job4 = launch(start = CoroutineStart.ATOMIC) {
        delay(100)
        log(5)
    }
    job4.cancel()
}

这段代码的执行结果为:

[DefaultDispatcher-worker-1]:1
[DefaultDispatcher-worker-3]:2
[DefaultDispatcher-worker-3]:22
[DefaultDispatcher-worker-2]:4
[DefaultDispatcher-worker-2]:44

共创建了4个协程:job1、job2、job3、job4,其中协程job2为默认启动模式,其他的启动模式都为 ATOMICdelay(100) 是一个挂起函数调用,相当于 Thread.sleep(100)的作用,每个协程创建之后立即调用 cancel() 方法取消执行。我们来分析每个结果:

  • job1:协程体内没有调用挂起函数,协程体内的代码都被执行了,该协程没有被取消掉;
  • job2:协程被取消掉了;
  • job3:挂起函数 delay(100) 之前的代码执行了,挂起函数后面的代码没有执行;
  • job4:协程体内的第一行代码就是挂起函数调用,最终该协程体内的代码都没执行;

从上面的例子中可以看到,DEFAULT 模式启动的协程如果还没调度执行是可以取消掉的,ATOMIC 模式启动的协程如果还没调度执行时就被取消,协程体内第一个挂起函数之前的代码依旧会执行。如果该协程内部没有调用任何挂起函数,则该协程里的代码无论如何也会执行。协程的取消有点像线程的中断一样,suspend 函数又有点像线程里能够抛出中断异常的方法一样。

2.4 UNDISPATCHED

这种模式具备 ATOMIC 的功能,与之不同的是,一旦调用 launch 方法后,该协程会立即在当前线程执行。

GlobalScope.launch {
    log(1)
    val job1 = launch(start = CoroutineStart.UNDISPATCHED) {
        log(2)
        delay(100)
        log(22)
    }
    job1.cancel()

    val job2 = launch(start = CoroutineStart.UNDISPATCHED) {
        log(3)
        delay(100)
        log(33)
    }
    log("after job2")

    val job3 = launch(start = CoroutineStart.ATOMIC) {
        log(4)
        delay(100)
        log(44)
    }
    log("after job3")
}

执行结果为:

[DefaultDispatcher-worker-2]:1
[DefaultDispatcher-worker-2]:2
[DefaultDispatcher-worker-2]:3
[DefaultDispatcher-worker-2]:after job2
[DefaultDispatcher-worker-2]:after job3
[DefaultDispatcher-worker-2]:4
[DefaultDispatcher-worker-2]:33
[DefaultDispatcher-worker-2]:44

job1 验证了它不能被取消的功能,job2 中 3 会立即在当前线程执行,所以 3 必然会在 after job2 之前执行,job3 中 4 会等待调度器调度执行,所以他并不会在 after job3 之前执行,4after job3 的执行顺序实质上与协程的调度来决定。

3. CoroutineContext介绍

根据文档里的说明,CoroutineContext 的概念主要有3点:

  1. It is an indexed set of [Element] instances. 它是一个包含 Element 实例的索引集;
  2. An indexed set is a mix between a set and a map. 索引集是 set 和 map 的混合结构;
  3. Every element in this set has a unique [Key]. 这个集合中的每个元素都有一个唯一的 Key;

说的通俗一点,CoroutineContext 就是一个集合 Collection,这个集合既有 set 的特性又有 map 的特性,集合里的元素都是 Element 类型的,每个 Element 类型的元素都有一个类型为 Key 的键。按惯例先来看看类定义:

public interface CoroutineContext {

    //操作符'[]'重载,通过 Key 获取 context 中的 Element 类型元素。可直接通过 CoroutineContext[Key] 这种形式来获取与 Key 关联的元素,类似从 List 中取出索引为 index 的某个元素:List[index],从 Map 中取出某个元素则为 Map.get(key)
    public operator fun  get(key: Key): E?

    //聚集函数,函数式编程中出现比较多,想象一下"菲波那切数列求和"就容易理解了
    //这里是提供了遍历当前 context 中所有 Element 元素的能力
    public fun  fold(initial: R, operation: (R, Element) -> R): R

    //操作符 '+' 重载,类似 List 中的 List.addAll(list)方法、Map 中的 Map.putAll(map) 方法,将2个集合合并成一个集合
    public operator fun plus(context: CoroutineContext): CoroutineContext

    //返回一个新的 context,但是该 conext 删除了有指定 Key 的 Element。
    public fun minusKey(key: Key<*>): CoroutineContext
    
    //Key的定义,空实现,仅仅只是做一个标识
    public interface Key
    
    //Element的定义,同样继承自 CoroutineContext
    public interface Element : CoroutineContext {
    
        //每个 Element 都有一个 Key
        public val key: Key<*>
    
        public override operator fun  get(key: Key): E? =
            @Suppress("UNCHECKED_CAST")
            if (this.key == key) this as E else null
    
        public override fun  fold(initial: R, operation: (R, Element) -> R): R =
            operation(initial, this)
    
        public override fun minusKey(key: Key<*>): CoroutineContext =
            if (this.key == key) EmptyCoroutineContext else this
    }    
}

可以发现,CoroutineContext 感觉与 Java 里的 Map 最相似,简直就是一个键为 Key 类型的 Map。众所周知,List、Map 的内部数据结构一般为数组、链表之类的,那么 CoroutineContext 的内部数据结构呢?

查看源码,发现它的底层数据结构是一个叫 CombinedContext 的类来实现的,这是一个内部类,定义如下:

internal class CombinedContext(
    private val left: CoroutineContext,
    private val element: Element
) : CoroutineContext, Serializable 

它有2个参数,left 为 CoroutineContext 类型,element 为就是集合里的元素。看到这个定义是不是特奇怪,既不像数组又不像链表,那么它是怎么具备集合的功能的呢,为此我写了个简单的例子:

class List constructor() {
    private var head: E? = null
    private var tail: List? = null

    constructor(head: E?, tail: List?) : this() {
        this.head = head
        this.tail = tail
    }

    fun add(e: E) {
        if (head == null) {
            head = e
        } else {
            if (tail == null) {
                val nextList = List()
                nextList.head = e
                tail = nextList
            } else {
                tail?.add(e)
            }
        }
    }

    fun size(): Int = (if (head == null) 0 else 1) + (tail?.size() ?: 0)

}

据说这种叫做 List 的递归定义,有些函数式编程语言中,就是采用这种方式来定义 List 的。它有点像链表,又跟链表不太一样,CombinedContext 与之非常类似,仅仅是头尾位置换了一下,当然它更复杂,我们再来看 plus 方法的具体实现:

    public operator fun plus(context: CoroutineContext): CoroutineContext =
        if (context === EmptyCoroutineContext) this else
            context.fold(this) { acc, element ->
                val removed = acc.minusKey(element.key)
                if (removed === EmptyCoroutineContext) element else {
                    val interceptor = removed[ContinuationInterceptor]
                    if (interceptor == null) CombinedContext(removed, element) else {
                        val left = removed.minusKey(ContinuationInterceptor)
                        if (left === EmptyCoroutineContext) CombinedContext(element, interceptor) else
                            CombinedContext(CombinedContext(left, element), interceptor)
                    }
                }
            }

整段代码就是一递归的实现,主要逻辑有:

  1. 除了少数情况外,主要返回的就是 CombinedContext 对象;
  2. 新返回的 CoroutineContext 对象,包含了 2 个 context 里所包含的全部 Element 元素;
  3. 在组合形成 CombinedContext 的时候,如果当前 context 里有与要相加的 context 含有相同 Key 的 Element,则当前 context 里的该元素会被删除掉。这就让 CoroutineContext 具备了 Set 的属性,一个 Key,只能取出一个对应的 Element;
  4. 这里有一个key为 ContinuationInterceptor 的元素,它也是继承自 Element,通常叫做协程上下文拦截器(后面再单独将它)。它有点特殊,不管多少次相加操作之后,它总是出现在最后面。通过一个 context,我们总能最快找到拦截器(避免了递归查找);

下图是主要的继承了 CoroutineContext 的类图:

CoroutineContext类继承

下面我们来写个例子,验证一下其中的特性:

val scope = MainScope()
val context = scope.coroutineContext
//取出 key 为 ContinuationInterceptor 的元素
println("interceptor: " + context[ContinuationInterceptor])

执行结果为: interceptor: Main

class TestContext : ContinuationInterceptor {

    override val key: CoroutineContext.Key<*> = ContinuationInterceptor

    override fun  interceptContinuation(continuation: Continuation): Continuation {
        return continuation
    }
}

val scope = MainScope()
//执行 context 的相加操作之后,再取出 key 为 ContinuationInterceptor 的元素
val context = scope.coroutineContext + TestContext()
println("interceptor: " + context[ContinuationInterceptor])

执行结果为:interceptor: com.hjy.kotlinstudy.TestContext@18b8ff07

这里可以看到,context 的相加操作之后,如果加号前后两个 context 都有相同的 key,则最终只保留加号后面的 key 对应的元素。如果这里你看到 context[ContinuationInterceptor] 方法调用,你一定会觉得很奇怪,方括号里的参数应该是一个 Key 类型的对象啊,这里的 ContinuationInterceptor 只是一个继承了 CoroutineContext 的接口啊,其实这只是 Kotlin 的一个特性,在 ContinuationInterceptor 接口里定义了一个如下对象:

companion object Key : CoroutineContext.Key

这个俗称伴生对象,context[ContinuationInterceptor] 等同于 context[ContinuationInterceptor.Key],在 kotlin 里直接写类名等同于该类里的伴生对象,以后看到类似的写法也就不会觉得晦涩难懂了。

4. 小结

本文介绍了与协程启动相关的几个主要类,特别是 CoroutineContext,我认为它是协程的核心概念,理解它有助于真正理解协程的内部运行机制。

你可能感兴趣的:(Android Kotlin Coroutine(2):协程的启动以及协程上下文)