一文快速入门 Kotlin 协程

一、Kotlin 协程

Kotlin 协程提供了一种全新处理并发的方式，你可以在 Android 平台上使用它来简化异步执行的代码。协程从 Kotlin 1.3 版本开始引入，但这一概念在编程世界诞生的黎明之际就有了，最早使用协程的编程语言可以追溯到 1967 年的 Simula 语言。在过去几年间，协程这个概念发展势头迅猛，现已经被诸多主流编程语言采用，比如 Javascript、C#、Python、Ruby 以及 Go 等。Kotlin 协程是基于来自其他语言的既定概念
Goggle 官方推荐将 Kotlin 协程作为在 Android 上进行异步编程的解决方案，值得关注的功能点包括：

轻量：你可以在单个线程上运行多个协程，因为协程支持挂起，不会使正在运行协程的线程阻塞。挂起比阻塞节省内存，且支持多个并行操作
内存泄露更少：使用结构化并发机制在一个作用域内执行多个操作
内置取消支持：取消功能会自动通过正在运行的协程层次结构传播
Jetpack 集成：许多 Jetpack 库都包含提供全面协程支持的扩展。某些库还提供自己的协程作用域，可供你用于结构化并发

引入依赖：
implementation ‘org.jetbrains.Kotlinx:Kotlinx-coroutines-core:1.4.2’
implementation ‘org.jetbrains.Kotlinx:Kotlinx-coroutines-android:1.4.2’

二、第一个协程

协程可以称为轻量级线程。Kotlin 协程在 CoroutineScope 的上下文中通过 launch、async 等协程构造器（CoroutineBuilder）来声明并启动

fun main() {
    GlobalScope.launch(context = Dispatchers.IO) {
        //延时一秒
        delay(1000)
        log("launch")
    }
    //主动休眠两秒，防止JVM过快退出
    Thread.sleep(2000)
    log("end")
}

private fun log(msg: Any?) = println("[${Thread.currentThread().name}] $msg")
[DefaultDispatcher-worker-1 @coroutine#1] launch
[main] end

在上面的例子中，通过 GlobalScope（即全局作用域）启动了一个协程，在延迟一秒后输出一行日志。从输出结果可以看出来，启动的协程是运行在协程内部的线程池中。虽然从表现结果上来看，启动一个协程类似于我们直接使用 Thread 来执行耗时任务，但实际上协程和线程有着本质上的区别。通过使用协程，可以极大的提高线程的并发效率，避免以往的嵌套回调地狱，极大提高了代码的可读性
以上代码就涉及到了协程的四个基础概念：

suspend function。即挂起函数，delay 函数就是协程库提供的一个用于实现非阻塞式延时的挂起函数
CoroutineScope。即协程作用域，GlobalScope 是 CoroutineScope 的一个实现类，用于指定协程的作用范围，可用于管理多个协程的生命周期，所有协程都需要通过 CoroutineScope 来启动
CoroutineContext。即协程上下文，包含多种类型的配置参数。Dispatchers.IO 就是 CoroutineContext 这个抽象概念的一种实现，用于指定协程的运行载体，即用于指定协程要运行在哪类线程上
CoroutineBuilder。即协程构建器，协程在 CoroutineScope 的上下文中通过 launch、async 等协程构建器来进行声明并启动。launch、async 等均被声明 CoroutineScope 的扩展方法

三、suspend function

如果上述例子试图直接在 GlobalScope 外调用 delay() 函数的话，IDE 就会提示一个错误：Suspend function ‘delay’ should be called only from a coroutine or another suspend function。意思是：delay() 函数是一个挂起函数，只能由协程或者由其它挂起函数来调用
delay() 函数就使用了 suspend 进行修饰，用 suspend 修饰的函数就是挂起函数
public suspend fun delay(timeMillis: Long)

读者在网上看关于协程的文章的时候，应该经常会看到这么一句话：挂起函数不会阻塞其所在线程，而是会将协程挂起，在特定的时候才再恢复协程
对于这句话我的理解是：delay() 函数类似于 Java 中的 Thread.sleep()，而之所以说 delay() 函数是非阻塞的，是因为它和单纯的线程休眠有着本质的区别。协程是运行于线程上的，一个线程可以运行多个（几千上万个）协程。线程的调度行为是由操作系统来管理的，而协程的调度行为是可以由开发者来指定并由编译器来实现的，协程能够细粒度地控制多个任务的执行时机和执行线程，当某个特定的线程上的所有协程被 suspend 后，该线程便可腾出资源去处理其他任务
例如，当在 ThreadA 上运行的 CoroutineA 调用了delay(1000L)函数指定延迟一秒后再运行，ThreadA 会转而去执行 CoroutineB，等到一秒后再来继续执行 CoroutineA。所以，ThreadA 并不会因为 CoroutineA 的延时而阻塞，而是能继续去执行其它任务，所以挂起函数并不会阻塞其所在线程，这样就极大地提高线程的并发灵活度，最大化线程的利用效率。而如果是使用Thread.sleep()的话，线程就真的只是白白消耗 CPU 时间片而不会去执行其它任务

四、suspend function 的挂起与恢复

协程在常规函数的基础上添加了两项操作用于处理长时间运行的任务。在invoke（或 call）和return之外，协程添加了suspend和 resume：

suspend 用于暂停执行当前协程，并保存所有局部变量
resume 用于让已暂停的协程从暂停处继续执行

suspend 函数只能由其它 suspend 函数调用，或者是由协程来调用
以下示例展示了一项任务（假设 get 方法是一个网络请求任务）的简单协程实现：

suspend fun fetchDocs() {                             // Dispatchers.Main
    val result = get("https://developer.android.com") // Dispatchers.IO for `get`
    show(result)                                      // Dispatchers.Main
}

suspend fun get(url: String) = withContext(Dispatchers.IO) { /* ... */ }

在上面的示例中，get() 仍在主线程上被调用，但它会在启动网络请求之前暂停协程。get() 主体内通过调用 withContext(Dispatchers.IO) 创建了一个在 IO 线程池中运行的代码块，在该块内的任何代码都始终通过 IO 调度器执行。当网络请求完成后，get() 会恢复已暂停的协程，使得主线程协程可以直接拿到网络请求结果而不用使用回调来通知主线程。Retrofit 就是以这种方式来实现对协程的支持的
Kotlin 使用堆栈帧管理要运行哪个函数以及所有局部变量。暂停协程时，系统会复制并保存当前的堆栈帧以供稍后使用。恢复时，会将堆栈帧从其保存位置复制回来，然后函数再次开始运行。即使代码可能看起来像普通的顺序阻塞请求，协程也能确保网络请求避免阻塞主线程
在主线程进行的暂停协程和恢复协程的两个操作，既实现了将耗时任务交由后台线程完成，保障了主线程安全，又以同步代码的方式完成了实际上的多线程异步调用。可以说，在 Android 平台上协程主要就用来解决两个问题：

处理耗时任务 (Long running tasks)，这种任务常常会阻塞住主线程
保证主线程安全 (Main-safety) ，即确保安全地从主线程调用任何 suspend 函数

五、CoroutineScope

CoroutineScope 即协程作用域，用于对协程进行追踪。如果我们启动了多个协程但是没有一个可以对其进行统一管理的途径的话，那么就会导致我们的代码臃肿杂乱，甚至发生内存泄露或者任务泄露。为了确保所有的协程都会被追踪，Kotlin 不允许在没有使用 CoroutineScope 的情况下启动新的协程。CoroutineScope 可被看作是一个具有超能力的 ExecutorService 的轻量级版本。它能启动新的协程，同时这个协程还具备上文所说的 suspend 和 resume 的优势
所有的协程都需要通过 CoroutineScope 来启动，它会跟踪它使用 launch 或 async 创建的所有协程，你可以随时调用 scope.cancel() 取消正在运行的协程。CoroutineScope 本身并不运行协程，它只是确保你不会失去对协程的追踪，即使协程被挂起也是如此。在 Android 中，某些 KTX 库为某些生命周期类提供了自己的 CoroutineScope。例如，ViewModel 有 viewModelScope，Lifecycle 有 lifecycleScope
CoroutineScope 大体上可以分为三种：

GlobalScope。即全局协程作用域，在这个范围内启动的协程可以一直运行直到应用停止运行。GlobalScope 本身不会阻塞当前线程，且启动的协程相当于守护线程，不会阻止 JVM 结束运行
runBlocking。一个顶层函数，和 GlobalScope 不一样，它会阻塞当前线程直到其内部所有相同作用域的协程执行结束
自定义 CoroutineScope。可用于实现主动控制协程的生命周期范围，对于 Android 开发来说最大意义之一就是可以避免内存泄露

• 1、GlobalScope

GlobalScope 属于全局作用域，这意味着通过 GlobalScope 启动的协程的生命周期只受整个应用程序的生命周期的限制，只要整个应用程序还在运行且协程的任务还未结束，协程就可以一直运行
GlobalScope 不会阻塞其所在线程，所以以下代码中主线程的日志会早于 GlobalScope 内部输出日志。此外，GlobalScope 启动的协程相当于守护线程，不会阻止 JVM 结束运行，所以如果将主线程的休眠时间改为三百毫秒的话，就不会看到 launch A 输出日志

fun main() {
    log("start")
    GlobalScope.launch {
        launch {
            delay(400)
            log("launch A")
        }
        launch {
            delay(300)
            log("launch B")
        }
        log("GlobalScope")
    }
    log("end")
    Thread.sleep(500)
}

[main] start
[main] end
[DefaultDispatcher-worker-1 @coroutine#1] GlobalScope
[DefaultDispatcher-worker-3 @coroutine#3] launch B
[DefaultDispatcher-worker-3 @coroutine#2] launch A

GlobalScope.launch 会创建一个顶级协程，尽管它很轻量级，但在运行时还是会消耗一些内存资源，且可以一直运行直到整个应用程序停止（只要任务还未结束），这可能会导致内存泄露，所以在日常开发中应该谨慎使用 GlobalScope

• 2、runBlocking

也可以使用 runBlocking 这个顶层函数来启动协程，runBlocking 函数的第二个参数即协程的执行体，该参数被声明为 CoroutineScope 的扩展函数，因此执行体就包含了一个隐式的 CoroutineScope，所以在 runBlocking 内部可以来直接启动协程

public fun <T> runBlocking(context: CoroutineContext = EmptyCoroutineContext, block: suspend CoroutineScope.() -> T): T

runBlocking 的一个方便之处就是：只有当内部相同作用域的所有协程都运行结束后，声明在 runBlocking 之后的代码才能执行，即 runBlocking 会阻塞其所在线程
看以下代码。runBlocking 内部启动的两个协程会各自做耗时操作，从输出结果可以看出来两个协程还是在交叉并发执行，且 runBlocking 会等到两个协程都执行结束后才会退出，外部的日志输出结果有明确的先后顺序。即 runBlocking 内部启动的协程是非阻塞式的，但 runBlocking 阻塞了其所在线程。此外，runBlocking 只会等待相同作用域的协程完成才会退出，而不会等待 GlobalScope 等其它作用域启动的协程
所以说，runBlocking 本身带有阻塞线程的意味，但其内部运行的协程又是非阻塞的，读者需要意会这两者的区别

fun main() {
    log("start")
    runBlocking {
        launch {
            repeat(3) {
                delay(100)
                log("launchA - $it")
            }
        }
        launch {
            repeat(3) {
                delay(100)
                log("launchB - $it")
            }
        }
        GlobalScope.launch {
            repeat(3) {
                delay(120)
                log("GlobalScope - $it")
            }
        }
    }
    log("end")
}

[main] start
[main] launchA - 0
[main] launchB - 0
[DefaultDispatcher-worker-1] GlobalScope - 0
[main] launchA - 1
[main] launchB - 1