其他分享
首页 > 其他分享> > Kotlin Coroutines(协程)讲解，2021阿里Android笔试总结

Kotlin Coroutines(协程)讲解，2021阿里Android笔试总结

作者：互联网

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 的使用场景。

现在，你应该可以很灵活地使用各种 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.awa

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》

【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享

it() + suggestedFriends.await())

}

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

作用域（Scope）

到目前为止，我们使用简单的方式轻松地实现了复杂的操作。但是，仍有一个问题未解决。

假如我们要使用 RecyclerView 显示朋友列表，当请求仍在进行的时候，客户关闭了 activity，此时 activity 处于 isFinishing 的状态，任何更新 UI 的操作都会导致 App 崩溃。

我们怎么处理这种场景呢？当然是使用作用域（scope）了。先来看看都有哪些作用域：

Global scope

它是一个全局的作用域，如果协程的运行周期和 App 的生命周期一样长的话，创建协程的时候可以使用它。所以它不应该和任何可以被销毁的组件绑定使用。

它的使用方式是这样的：

GlobalScope.launch(Dispatchers.Main) {
…
}

当你使用它的时候，要再三确定，要创建的协程是否需要伴随 App 整个生命周期运行，并且这个协程没有和界面、组件等绑定。

自定义协程作用域

任何类都可以继承 CoroutineScope 作为一个作用域。你需要做的唯一一件事就是重写 coroutineContext  这个属性。

在此之前，你需要明确两个重要的概念 dispatcher  和 Job。

不知道你是否还记得，一个上下文（context）可以是多个上下文的组合。组合的上下文需要是不同的类型。所以，你需要做两件事情：

class MainActivity : AppCompatActivity(), CoroutineScope {

override val coroutineContext: CoroutineContext
get() = Dispatchers.Main + job

private lateinit var job: Job

}

操作符号 + 用于组合上下文。如果两种不同类型的上下文相组合，会生成一个组合的上下文（CombinedContext），这个新的上下文会同时拥有被组合上下文的特性。

如果两个相同类型的上下文相组合，新的上下文等同于第二个上下文。即 Dispatchers.Main + Dispatchers.IO == Dispatchers.IO。

我们可以使用延迟初始化（lateinit）的方式创建一个 Job。这样我们就可以在 onCreate() 方法中初始化它，在 onDestroy() 方法中取消它。

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
job = Job()
…
}

override fun onDestroy() {
job.cancel()
super.onDestroy()
}

这样以来，使用协程就方便多了。我们只管创建协程，而不用关心使用的上下文。因为我们已经在自定义的作用域里面声明了上下文，也就是包含了 main dispatcher 的那个上下文：

launch {
…
}

如果你的所有 activity 都需要使用协程，将上述代码提取到一个父类中是很有必要的。

附录1 - 回调方式转为协程

标签：协程,val,Kotlin,Job,Coroutines,线程,上下文,Dispatchers
来源： https://blog.csdn.net/m0_64604178/article/details/121733405