Kotlin Coroutines(协程)讲解

}

}

步骤如下：

1. 显示一个进度条；
2. 请求服务器校验用户名和密码；
3. 等待校验成功后，请求服务器获取好友列表；
4. 最后，隐藏进度条；

情况还可以更复杂，想象一下，不仅要请求好友列表，还需要请求推荐好友列表，并把两次结果合并进一个列表。

有两种选择：

1. 最简单的方式就是，在请求完好友列表之后，再请求推荐好友列表，但是这种方式不够高效，因为后者并不依赖前者的请求结果；
2. 这种方式相对复杂一些，同时请求好友列表和推荐好友列表，并同步两次请求的结果；

通常情况下，想要偷懒的人可能会选择第一种方式：

progress.visibility = View.VISIBLE

userService.doLoginAsync(username, password) { user ->

userService.requestCurrentFriendsAsync(user) { currentFriends ->

userService.requestSuggestedFriendsAsync(user) { suggestedFriends ->
val finalUser = user.copy(friends = currentFriends + suggestedFriends)
toast(“User ${finalUser.name} has ${finalUser.friends.size} friends”)

progress.visibility = View.GONE
}

}

}

到这里，代码开始变得复杂了，出现了可怕的回调地狱：后一个请求总是嵌套在前一个请求的结果回调里面，缩进变得越来越多。

由于使用的是 Kotlin 的 lambdas，可能看起来并没有那么糟糕。但是随着请求的增多，代码变得越来越难以管理。

别忘了，我们使用的还是一种相对简单但并不高效的一种方式。

什么是协程（Coroutine）

简单来说，协程像是轻量级的线程，但并不完全是线程。

首先，协程可以让你顺序地写异步代码，极大地降低了异步编程带来的负担；

其次，协程更加高效。多个协程可以共用一个线程。一个 App 可以运行的线程数是有限的，但是可以运行的协程数量几乎是无限的；

协程实现的基础是可中断的方法（suspending functions）。可中断的方法可以在任意的地方中断协程的执行，直到该可中断的方法返回结果或者执行完成。

运行在协程中的可中断的方法（通常情况下）不会阻塞当前线程，之所以是通常情况下，因为这取决于我们的使用方式。具体下面会讲到。

coroutine {
progress.visibility = View.VISIBLE

val user = suspended { userService.doLogin(username, password) }
val currentFriends = suspended { userService.requestCurrentFriends(user) }

val finalUser = user.copy(friends = currentFriends)
toast(“User ${finalUser.name} has ${finalUser.friends.size} friends”)

progress.visibility = View.GONE
}

上面的示例是协程的常用使用范式。首先，使用一个协程构造器（coroutine builder）创建一个协程，然后，一个或多个可中断的方法运行在协程中，这些方法将会中断协程的执行，直到它们返回结果。

可中断的方法返回结果后，我们在下一行代码就可以使用这些结果，非常像顺序编程。注意实际上 Kotlin 中并不存在 coroutine 和 suspended 这两个关键字，上述示例只是为了便于演示协程的使用范式。

可中断的方法（suspending functions）

可中断的方法有能力中断协程的执行，当可中断的方法执行完毕后，接着就可以使用它们返回的结果。

val user = suspended { userService.doLogin(username, password) }
val currentFriends = suspended { userService.requestCurrentFriends(user) }

可中断的方法可以运行在相同的或不同的线程，这取决于你的使用方式。可中断的方法只能运行在协程中或其他可中断的方法中。

声明一个可中断的方法，只需要使用 suspend 保留字：

suspend fun suspendingFunction() : Int {
// Long running task
return 0
}

回到最初的示例，你可能会问上述代码运行在哪个线程，我们先看这一行代码：

coroutine {
progress.visibility = View.VISIBLE
…
}

你认为这行代码运行在哪个线程呢？你确定它是运行在 UI 线程吗？如果不是，App 就会崩溃，所以弄明白运行在哪个线程很重要。

答案就是这取决于协程上下文（coroutine context）的设置。

协程上下文（Coroutine Context）

协程上下文是一系列规则和配置的集合，它决定了协程的运行方式。也可以理解为，它包含了一系列的键值对。

现在，你只需要知道 dispatcher 是其中的一个配置，它可以指定协程运行在哪个线程。

dispatcher 有两种方式可以配置：

1. 明确指定需要使用的 dispatcher;
2. 由协程作用域（coroutine scope）决定。这里先不展开说，后面会详细说明；

具体来说，协程构造器（coroutine builder）接收一个协程上下文（coroutine context）作为第一个参数，我们可以传入要使用的 dispatcher。因为 dispatcher 实现了协程上下文，所以可以作为参数传入：

coroutine(Dispatchers.Main) {
progress.visibility = View.VISIBLE
…
}

现在，改变进度条可见性的代码就运行在了 UI 线程。不仅如此，协程内的所有代码都运行在 UI 线程。那么问题来了，可中断的方法会怎么运行？

coroutine {
…
val user = suspended { userService.doLogin(username, password) }
val currentFriends = suspended { userService.requestCurrentFriends(user) }
…
}

这些请求服务的代码也是运行在主线程吗？如果真是这样的话，它们会阻塞主线程。到底是不是呢，还是那句话，这取决于你的使用方式。

可中断的方法有多种办法配置要使用的 dispatcher，其中最常用的方法是 withContext。

withContext

在协程内部，这个方法可以轻易地改变代码运行时所在的上下文。它是一个可中断的方法，所以调用它会中断协程的执行，直到该方法执行完成。

这样以来，我们就可以让示例中那些可中断的方法运行在不同的线程中：

suspend fun suspendLogin(username: String, password: String) =
withContext(Dispatchers.Main) {
userService.doLogin(username, password)
}

上面这些代码会运行在主线程，所以仍然会阻塞 UI 。但是，现在我们可以轻易地指定使用不同的 dispatcher:

suspend fun suspendLogin(username: String, password: String) =
withContext(Dispatchers.IO) {
userService.doLogin(username, password)
}

现在我们使用了 IO dispatcher, 上述代码会运行在子线程。另外，withContext 本身就是一个可中断的方法，所以，我们没必要让它运行在另一个可中断方法中。所以我们也可以这样写：

val user = withContext(Dispatchers.IO) { userService.doLogin(username, password) }
val currentFriends = withContext(Dispatchers.IO) { userService.requestCurrentFriends(user) }

目前为止，我们认识了两个 dispatcher，下面我们详细介绍一下所有的 dispatcher 的使用场景。

• Default: 当我们未指定 dispatcher 的时候会默认使用，当然，我们也可以明确设置使用它。它一般用于 CPU 密集型的任务,特别是涉及到计算、算法的场景。它可以使用和 CPU 核数一样多的线程。正因为是密集型的任务，同时运行多个线程并没有意义，因为 CPU 将会很繁忙。

• IO: 它用于输入/输出的场景。通常，涉及到会阻塞线程，需要等待另一个系统响应的任务，比如：网络请求、数据库操作、文件读写等，都可以使用它。因为它不使用 CPU ，可以同一时间运行多个线程，默认是数量为 64 的线程池。Android App 中有很多网络请求的操作，所以你可能会经常用到它。

• UnConfined: 如果你不在乎启动了多少个线程，那么你可以使用它。它使用的线程是不可控制的，除非你特别清楚你在做什么，否则不建议使用它。

• Main: 这是 UI 相关的协程库里面的一个 dispatcher，在 Android 编程中，它使用的是 UI 线程。

现在，你应该可以很灵活地使用各种 dispatcher 了。

协程构造器（Coroutine Builders）

现在，你可以轻松地切换线程了。接下来，我们学习一下如何启动一个新的协程：当然要靠协程构造器了。

根据实际情况，我们可以选择使用不同的协程构造器，当然我们也可以创建自定义的协程构造器。不过通常情况下，协程库提供的已经满足我们的使用了。具体如下：

runBlocking

这个协程构造器会阻塞当前线程，直到协程内的所有任务执行完毕。这好像违背了我们使用协程的初衷，所以什么场景下会用到它呢？

runBlocking 对于测试可中断的方法非常有用。在测试的时候，将可中断的方法运行在 runBlocking 构建的协程内部，这样就可以保证，在这些可中断的方法返回结果前当前测试线程不会结束，这样，我们就可以校验测试结果了。

fun testSuspendingFunction() = runBlocking {
val res = suspendingTask1()
assertEquals(0, res)
}

但是，除了这个场景外，你也许不会用到 runBlocking 了。

launch

这个协程构造器很重要，因为它可以很轻易地创建一个协程，你可能会经常用到它。和 runBlocking 相反的是，它不会阻塞当前线程（前提是我们使用了合适的 dispatcher）。

这个协程构造器通常需要一个作用域（scope），关于作用域的概念后面会讲到，我们暂时使用全局作用域（GlobalScope）：

GlobalScope.launch(Dispatchers.Main) {
…
}

launch 方法会返回一个 Job，Job 继承了协程上下文（CoroutineContext）。

Job 提供了很多有用的方法。需要明确的是：一个 Job 可以有一个父 Job，父 Job 可以控制子 Job。下面介绍一下 Job 的方法：

job.join

这个方法可以中断与当前 Job 关联的协程，直到所有子 Job 执行完成。协程内的所有可中断的方法与当前 Job 相关联，直到子 Job 全部执行完成，与当前 Job 关联的协程才能继续执行。

val job = GlobalScope.launch(Dispatchers.Main) {

doCoroutineTask()

val res1 = suspendingTask1()
val res2 = suspendingTask2()

process(res1, res2)

}

job.join()

job.join() 是一个可中断的方法，所以它应该在协程内部被调用。

job.cancel

这个方法可以取消所有与其关联的子 Job，假如 suspendingTask1() 正在执行的时候 Job 调用了 cancel() 方法，这时候，res1 不会再被返回，而且 suspendingTask2() 也不会再执行。

val job = GlobalScope.launch(Dispatchers.Main) {

doCoroutineTask()

val res1 = suspendingTask1()
val res2 = suspendingTask2()

process(res1, res2)

}

job.cancel()

job.cancel() 是一个普通方法，所以它不必运行在协程内部。

async

这个协程构造器将会解决我们在刚开始演示示例的时候提到的一些难题。

async 允许并行地运行多个子线程任务，它不是一个可中断方法，所以当调用 async 启动子协程的同时，后面的代码也会立即执行。async 通常需要运行在另外一个协程内部，它会返回一个特殊的 Job，叫作 Deferred。

Deferred 有一个新的方法叫做 await()，它是一个可中断的方法，当我们需要获取 async 的结果时，需要调用 await() 方法等待结果。调用 await() 方法后，会中断当前协程，直到其返回结果。

在下面的示例中，第二个和第三个请求需要依赖第一个请求的结果，请求好友列表和推荐好友列表本来可以并行请求的，如果都使用 withContext，显然会浪费时间：

GlobalScope.launch(Dispatchers.Main) {

val user = withContext(Dispatchers.IO) { userService.doLogin(username, password) }
val currentFriends = withContext(Dispatchers.IO) { userService.requestCurrentFriends(user) }
val suggestedFriends = withContext(Dispatchers.IO) { userService.requestSuggestedFriends(user) }

val finalUser = user.copy(friends = currentFriends + suggestedFriends)
}

假如每个请求耗时 2 秒，总共需要使用 6 秒。如果我们使用 async 替代呢：

GlobalScope.launch(Dispatchers.Main) {

val user = withContext(Dispatchers.IO) { userService.doLogin(username, password) }
val currentFriends = async(Dispatchers.IO) { userService.requestCurrentFriends(user) }
val suggestedFriends = async(Dispatchers.IO) { userService.requestSuggestedFriends(user) }

val finalUser = user.copy(friends = currentFriends.await() + suggestedFriends.await())

}

这时，第二个和第三个请求会并行运行，所以总耗时将会减少到 4 秒。

最后

在此为大家准备了四节优质的Android高级进阶视频：

架构师项目实战——全球首批Android开发者对Android架构的见解

附相关架构及资料

往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
—全球首批Android开发者对Android架构的见解**

附相关架构及资料

[外链图片转存中…(img-dybvs7kA-1715843754080)]

往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！