在 Android 开发中使用协程 | 代码实战

• @CeruleanOtter https://twitter.com/CeruleanOtter- ViewModels: A Simple Examplehttps://medium.com/androiddevelopers/viewmodels-a-simple-example-ed5ac416317e

这是在 Android 上使用协程的通用模式。由于 Android framework 不会主动调用挂起函数，所以您需要配合使用协程来响应 UI 事件。最简单的方法就是来一个事件就启动一个新的协程，最适合处理这种情况的地方就是 ViewModel 了。

在 ViewModel 中启动协程是很通用的模式。

ViewModel 实际上使用了 ProductsRepository 来获取数据，示例代码如下:

class ProductsRepository(val productsDao: ProductsDao) {

  /**
       这是一个普通的挂起函数，也就是说调用方必须在一个协程中。repository 并不负责启动或者停止协程，因为它并不负责对协程生命周期的掌控。
       这可能会在 Dispatchers.Main 中调用，同样它也是主线程安全的，因为 Room 会为我们保证主线程安全。
    */
   suspend fun loadSortedProducts(ascending: Boolean): List<ProductListing> {
       return if (ascending) {
           productsDao.loadProductsByDateStockedAscending()
       } else {
           productsDao.loadProductsByDateStockedDescending()
       }
   }
}

ProductsRepository 提供了一个合理的同商品数据进行交互的接口，此应用中，所有内容都存储在本地 Room 数据库中，它为 @Dao 提供了针对不同排序具有不同功能的两个接口。

repository 是 Android 架构组件中的一个可选部分，如果您在应用中已经集成了它或者其他的相似功能的模块，那么它应该更偏向于使用挂起函数。因为 repository 并没有生命周期，它仅仅是一个对象，所以它不能处理资源的清理工作，所以默认情况下，repository 中启动的所有协程都有可能出现泄漏。

使用挂起函数除了避免泄漏之外，在不同的上下文中也可以重复使用 repository，任何知道如何创建协程的都可以调用 loadSortedProducts，例如 WorkManager 所调度管理的后台任务就可以直接调用它。

repository 应该使用挂起函数来保证主线程安全。

注意: 当用户离开界面后，有些在后台中处理数据保存的操作可能还要继续工作，这种情况下脱离了应用生命周期来运行是没有意义的，所以大部分情况下 viewModelScope 都是一个好的选择。

再来看看 ProductsDao，示例代码如下：

@Dao
interface ProductsDao {

   // 因为这个方法被标记为了 suspend，Room 将会在保证主线程安全的前提下使用自己的调度器来运行这个查询
   @Query("select * from ProductListing ORDER BY dateStocked ASC")
   suspend fun loadProductsByDateStockedAscending(): List<ProductListing>
   // 因为这个方法被标记为了 suspend，Room 将会在保证主线程安全的前提下使用自己的调度器来运行这个查询
   @Query("select * from ProductListing ORDER BY dateStocked DESC")
   suspend fun loadProductsByDateStockedDescending(): List<ProductListing>
}

ProductsDao 是一个 Room @Dao，它对外提供了两个挂起函数，因为这些函数都增加了 suspend 修饰，所以 Room 会保证它们是主线程安全的，这也意味着您可以直接在 Dispatchers.Main 中调用它们。

• @FMuntenescuhttps://twitter.com/FMuntenescu- Room Coroutineshttps://medium.com/androiddevelopers/room-coroutines-422b786dc4c5

不过要注意的是，调用它的协程将会在主线程上执行。所以，如果您要对执行结果做一些比较耗时的操作，比如对列表内容进行转换，您要确保这个操作不会阻塞主线程。

注意: Room 使用了自己的调度器在后台线程上进行查询操作。您不应该再使用 withContext(Dispatchers.IO) 来调用 Room 的 suspend 查询，这只会让您的代码变复杂，也会拖慢查询速度。

Room 的挂起函数是主线程安全的，并运行于自定义的调度器中。

一次性请求模式

这是在 Android 架构组件中使用协程进行一次性请求的完整模式，我们将协程添加到了 ViewModel、Repository 和 Room 中，每一层都有着不同的责任分工。

1. ViewModel 在主线程上启动了协程，一旦有结果后就结束执行；
2. Repository 提供了保证主线程安全的挂起函数；
3. 数据库和网络层提供了保证主线程安全的挂起函数。

ViewModel 负责启动协程，并保证用户离开了相应界面时它们就会被取消。它本身并不会做一些耗时的操作，而是依赖别的层级来做。一旦有了结果，就使用 LiveData 将数据发送到 UI 层。因为 ViewModel 并不做一些耗时操作，所以它是在主线程启动协程的，以便能够更快地响应用户事件。

Repository 提供了挂起函数用来访问数据，它通常不会启动一些生命周期比较长的协程，因为它们一旦启动了便无法取消。无论何时 Repository 想要做一些耗时操作，比如对列表内容进行转换，都应该使用 withContext 来提供主线程安全的接口。

数据层 (网络或数据库) 总是会提供挂起函数，使用 Kotlin 协程的时候要保证这些挂起函数是主线程安全的，Room 和 Retrofit 都遵循了这一点。

在一次性请求中，数据层只提供挂起函数，调用方如果想要获取最新的值，只能再次进行调用，这就像浏览器中的刷新按钮一样。

花点时间让您了解一次性请求的模式是值得，它在 Android 协程中是比较通用的模式，您会一直用到它。

第一个 bug 出现了

在经过测试后，您部署到了生产环境，运行了几周都感觉良好，直到您收到了一个很奇怪的 bug 报告:

标题:  — 排序错误！

错误报告: 当我非常快速地点击排序按钮时，排序的结果偶尔是错的，这还不是每次都能复现的。

您研究了一下，不禁问自己哪里出错了？这个逻辑很简单:

1. 开始执行用户请求的排序操作；
2. 在 Room 调度器中开始进行排序；
3. 展示排序结果。

您觉得这个 bug 不存在准备关闭它，因为解决方案很简单，"不要那么快地点击按钮"，但是您还是很担心，觉得还是哪个地方出了问题。于是在代码中加入一些日志，并跑了一堆测试用例后，您终于知道问题出在什么地方了！

看起来应用内展示的排序结果并不是真正的 "排序结果"，而是上一次完成排序的结果。当用户快速点击按钮时，就会同时触发多个排序操作，这些操作可能以任意顺序结束。

当启动一个新的协程来响应 UI 事件时，要去考虑一下用户若在上一个任务未完成之前又开始了新的任务，会有什么样的后果。

这其实是一个并发导致的问题，它和是否使用了协程其实没有什么关系。如果您使用回调、Rx 或者是 ExecutorService，还是可能会遇到这样的 bug。

有非常多方案能够解决这个问题，既可以在 ViewModel 中解决，又可以在 Repository 中解决。我们来看看怎么才能让一次性请求按照我们所期望的顺序返回结果。

最佳解决方案: 禁用按钮

核心问题出在我们做了两次排序，要修复的话我们可以只让它排序一次。最简单的解决方法就是禁用按钮，不让它发出新的事件就可以了。

这看起来很简单，而且确实是个好办法。实现起来的代码也很简单，还容易测试，只要它能在 UI 中体现出来这个按钮的状态，就完全可以解决问题。

要禁用按钮，只需要告诉 UI 在 sortPricesBy 中是否有正在处理的排序请求，示例代码如下:

// 方案 0: 当有任何排序正在执行时，禁用排序按钮

class ProductsViewModel(val productsRepository: ProductsRepository): ViewModel() {
   private val _sortedProducts = MutableLiveData<List<ProductListing>>()
   val sortedProducts: LiveData<List<ProductListing>> = _sortedProducts

   private val _sortButtonsEnabled = MutableLiveData<Boolean>()
   val sortButtonsEnabled: LiveData<Boolean> = _sortButtonsEnabled

   init {
       _sortButtonsEnabled.value = true
   }

   /**
       当用户点击排序按钮时，调用
    */
   fun onSortAscending() = sortPricesBy(ascending = true)
   fun onSortDescending() = sortPricesBy(ascending = false)

   private fun sortPricesBy(ascending: Boolean) {
       viewModelScope.launch {
          // 只要有排序在进行，禁用按钮
           _sortButtonsEnabled.value = false
           try {
               _sortedProducts.value =
                       productsRepository.loadSortedProducts(ascending)
           } finally {
              // 排序结束后，启用按钮
               _sortButtonsEnabled.value = true
           }
       }
   }
}

使用 sortPricesBy 中的 _sortButtonsEnabled 在排序时禁用按钮

好了，这看起来还行，只需要在调用 repository 时在 sortPricesBy 内部禁用按钮就好了。

大部分情况下，这都是最佳解决方案，但是如果我们想在保持按钮可用的前提下解决 bug 呢？这样的话有一点困难，在本文剩余的部分看看该怎么做。

注意: 这段代码展示了从主线程启动的巨大优势，点击之后按钮立刻变得不可点了。但如果您换用了其他的调度程序，当出现某个手速很快的用户在运行速度较慢的手机上操作时，还是可能出现发送多次点击事件的情况。

并发模式

下面几个章节我们探讨一些比较高级的话题，如果您才刚刚接触协程，可以不去理解这一部分，使用禁用按钮这一方案就是解决大部分类似问题的最佳方案。

在剩余部分我们将探索在不禁用按钮的前提下，确保一次性请求能够正常运行。我们可以通过控制何时让协程运行 (或者不运行) 来避免刚刚出现的并发问题。

有三个基本的模式可以让我们确保在同一时间只会有一次请求进行:

1. 在启动更多协程之前取消之前的任务；
2. 让下一个任务排队等待前一个任务执行完成；
3. 如果有一个任务正在执行，返回该任务，而不是启动一个新的任务。

当介绍完这三个方案后，您可能会发现它们的实现都挺复杂的。为了专注于设计模式而不是实现细节，我创建了一个 gist 来提供这三个模式的实现作为可重用抽象 。

方案 1: 取消之前的任务

在排序这种情况下，获取新的事件后就意味着可以取消上一个排序任务了。毕竟用户通过这样的行为已经表明了他们不想要上次的排序结果了，继续进行上一次排序操作没什么意义了。

要取消上一个请求，我们首先要以某种方式追踪它。在 gist 中的 cancelPreviousThenRun 函数就做到了这个。

来看看如何使用它修复这个 bug:

方案 1: 取消之前的任务

// 方案 1: 取消之前的任务

// 对于排序和过滤的情况，新请求进来，取消上一个，这样的方案是很适合的。

class ProductsRepository(val productsDao: ProductsDao, val productsApi: ProductsService) {
   var controlledRunner = ControlledRunner<List<ProductListing>>()

   suspend fun loadSortedProducts(ascending: Boolean): List<ProductListing> {
      // 在开启新的排序之前，先取消上一个排序任务
       return controlledRunner.cancelPreviousThenRun {
           if (ascending) {
               productsDao.loadProductsByDateStockedAscending()
           } else {
               productsDao.loadProductsByDateStockedDescending()
           }
       }
   }
}

使用 cancelPreviousThenRun 来确保同一时间只有一个排序任务在进行看一下 gist 中 cancelPreviousThenRun 中的代码实现，您可以学习到如何追踪正在工作的任务。

// see the complete implementation at
// 在 https://gist.github.com/objcode/7ab4e7b1df8acd88696cb0ccecad16f7 中查看完整实现
suspend fun cancelPreviousThenRun(block: suspend () -> T): T {
   // 如果这是一个 activeTask，取消它，因为它的结果已经不需要了
   activeTask?.cancelAndJoin()

   // ...

简而言之，它会通过成员变量 activeTask 来保持对当前排序的追踪。无论何时开始一个新的排序，都立即对当前 activeTask 中的所有任务执行 cancelAndJoin 操作。这样会在开启一次新的排序之前就会把正在进行中的排序任务给取消掉。

使用类似于 ControlledRunner 这样的抽象实现来对逻辑进行封装是比较好的方法，比直接混杂并发与应用逻辑要好很多。

选择使用抽象来封装代码逻辑，避免混杂并发和应用逻辑代码。

注意: 这个模式不适合在全局单例中使用，因为不相关的调用方是不应该相互取消。

• gisthttps://gist.github.com/objcode/7ab4e7b1df8acd88696cb0ccecad16f7#file-concurrencyhelpers-kt-L19- 代码实现https://gist.github.com/objcode/7ab4e7b1df8acd88696cb0ccecad16f7#file-concurrencyhelpers-kt-L91- cancelAndJoinhttps://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/cancel-and-join.html

方案 2: 让下一个任务排队等待

这里有一个对并发问题总是有效的解决方案。

让任务去排队等待依次执行，这样同一时间就只会有一个任务会被处理。就像在商场里进行排队，请求将会按照它们排队的顺序来依次处理。

对于这种特定的排序问题，其实选择方案 1 比使用本方案要更好一些，但还是值得介绍一下这个方法，因为它总是能够有效的解决并发问题。

// 方案 2: 使用互斥锁
// 注意: 这个方法对于排序或者是过滤来说并不是一个很好的解决方案，但是它对于解决网络请求引起的并发问题非常适合。

class ProductsRepository(val productsDao: ProductsDao, val productsApi: ProductsService) {
   val singleRunner = SingleRunner()

   suspend fun loadSortedProducts(ascending: Boolean): List<ProductListing> {
      // 开始新的任务之前，等待之前的排序任务完成
       return singleRunner.afterPrevious {
           if (ascending) {
               productsDao.loadProductsByDateStockedAscending()
           } else {
               productsDao.loadProductsByDateStockedDescending()
           }
       }
   }
}

无论何时进行一次新的排序， 都使用一个 SingleRunner 实例来确保同时只会有一个排序任务在进行。

它使用了 Mutex，可以把它理解为一张单程票 (或是锁)，协程在必须要获取锁才能进入代码块。如果一个协程在运行时，另一个协程尝试进入该代码块就必须挂起自己，直到所有的持有 Mutex 的协程完成任务，并释放 Mutex 后才能进入。

Mutex 保证同时只会有一个协程运行，并且会按照启动的顺序依次结束。