在 Coroutines 中的取消和异常系列的第 2 部分中，我们了解了在不再需要工作时取消工作的重要性。 在 Android 上，您可以使用 Jetpack 提供的 CoroutineScopes：viewModelScope 或 LifecycleScope，它们会在其作用域完成时取消任何正在运行的工作——也就是当 Activity/Fragment/Lifecycle 完成时。 如果您正在创建自己的 CoroutineScope，请确保将其绑定到作业并在需要时调用取消。
但是，在某些情况下，您希望即使用户离开屏幕也能完成操作。 因此，您不希望取消工作（例如写入数据库或向您的服务器发出特定网络请求）。
继续阅读以获取实现此目标的模式！
Coroutines or WorkManager?
只要您的应用程序进程还活着，协程就会运行。 如果您需要运行的操作应该比流程更持久（例如，将日志发送到您的远程服务器），请在 Android 上改用 WorkManager。 WorkManager 是用于预计在未来某个时间点执行的关键操作的库。
将协程用于当前进程中有效的操作，并且可以在用户终止应用程序时取消（例如，发出要缓存的网络请求）。 触发这些操作的模式是什么？
协程最佳实践
由于此模式建立在其他协程最佳实践之上； 让我们回顾一下：
1. 将 Dispatchers 注入到类中
在创建新协程或调用 withContext 时不要对它们进行硬编码。
✅ 优点：易于测试，因为您可以轻松地将它们替换为unit和instrumentation测试。
2. ViewModel/Presenter 层应该创建协程
如果是UI-only操作，那么UI层就可以了。 如果您认为这在您的项目中是不可能的，则可能是您没有遵循最佳实践 #1（即测试不注入 Dispatcher 的 VM 更加困难；在这种情况下，公开挂起函数使其可行）。
✅ 好处：UI 层不应该直接触发任何业务逻辑。 相反，将该责任交给 ViewModel/Presenter 层。 测试 UI 层需要在 Android 中进行instrumentation测试，这需要模拟器才能运行。
3. ViewModel/Presenter 层下面的层应该公开挂起函数和Flows
如果需要创建协程，请使用 coroutineScope 或 supervisorScope。 如果您需要它们遵循不同的范围，这就是本文的内容！ 继续阅读！
✅ 好处：调用者（通常是 ViewModel 层）可以控制这些层中发生的工作的执行和生命周期，可以在需要时取消。
协程中不应取消的操作
想象一下，我们的应用程序中有一个 ViewModel 和一个 Repository，其逻辑如下：
class MyViewModel(private val repo: Repository) : ViewModel() {
fun callRepo() {
viewModelScope.launch {
repo.doWork()
}
}
}
class Repository(private val ioDispatcher: CoroutineDispatcher) {
suspend fun doWork() {
withContext(ioDispatcher) {
doSomeOtherWork()
veryImportantOperation() // This shouldn’t be cancelled
}
}
}
我们不希望 veryImportantOperation() 被 viewModelScope 控制，因为它可以在任何时候被取消。 我们希望该操作比 viewModelScope 的生命周期更长。 我们怎样才能做到这一点？
为此，请在 Application 类中创建您自己的作用域，并在由它启动的协程中调用这些操作。 该范围应该注入需要它的类中。
与我们稍后将看到的其他解决方案（如 GlobalScope）相比，创建自己的 CoroutineScope 的好处在于您可以根据需要对其进行配置。 你需要一个 CoroutineExceptionHandler 吗？ 您有自己的线程池用作调度程序吗？ 将所有常见配置放在其 CoroutineContext 中！
您可以将其称为 applicationScope，并且它必须包含一个 SupervisorJob()，以便协程中的异常不会在层次结构中传播（如本系列的第 3 部分所示）：
class MyApplication : Application() {
// No need to cancel this scope as it'll be torn down with the process
val applicationScope = CoroutineScope(SupervisorJob() + otherConfig)
}
我们不需要取消这个作用域，因为我们希望它在应用进程还活着的时候一直保持活动状态，所以我们不持有对 SupervisorJob 的引用。 我们可以使用这个作用域来运行需要比调用作用域在我们的应用程序中提供的生命周期更长的协程。
对于不应取消的操作，从应用程序 CoroutineScope 创建的协程中调用它们
每当你创建一个新的 Repository 实例时，传入我们上面创建的 applicationScope。 对于测试，请查看下面的测试部分。
使用哪个协程构建器？
根据veryImportantOperation 的行为，您需要使用launch 或async 启动一个新的协程：
- 如果需要返回结果，使用 async 并调用 await 等待它完成。
- 如果没有，请使用launch并使用join等待它完成。 请注意，如本系第 3 部分所述，您必须在启动块内手动处理异常。
这是您使用 launch 触发协程的方式：
class Repository(
private val externalScope: CoroutineScope,
private val ioDispatcher: CoroutineDispatcher
) {
suspend fun doWork() {
withContext(ioDispatcher) {
doSomeOtherWork()
externalScope.launch {
// if this can throw an exception, wrap inside try/catch
// or rely on a CoroutineExceptionHandler installed
// in the externalScope's CoroutineScope
veryImportantOperation()
}.join()
}
}
}
或者使用async
class Repository(
private val externalScope: CoroutineScope,
private val ioDispatcher: CoroutineDispatcher
) {
suspend fun doWork(): Any { // Use a specific type in Result
withContext(ioDispatcher) {
doSomeOtherWork()
return externalScope.async {
// Exceptions are exposed when calling await, they will be
// propagated in the coroutine that called doWork. Watch
// out! They will be ignored if the calling context cancels.
veryImportantOperation()
}.await()
}
}
}
在任何情况下，ViewModel 代码都不会改变，而且即使 viewModelScope 被结束了，使用 externalScope 的工作也会继续运行。 此外，doWork() 不会像任何其他挂起调用一样在 veryImportantOperation() 完成之前返回。
更简单的实现呢？
另一种可以服务于某些用例的模式（这可能是任何人都会想出的第一个解决方案）是使用 withContext 将非常重要的操作包装在 externalScope 的上下文中，如下所示：
class Repository(
private val externalScope: CoroutineScope,
private val ioDispatcher: CoroutineDispatcher
) {
suspend fun doWork() {
withContext(ioDispatcher) {
doSomeOtherWork()
withContext(externalScope.coroutineContext) {
veryImportantOperation()
}
}
}
}
但是，这种方法有一些注意事项：
- 如果在veryImportantOperation 正在执行时调用doWork 的协程被取消，它将继续执行直到下一个取消点，而不是在veryImportantOperation 完成执行之后。
- 当在 withContext 中使用上下文时，CoroutineExceptionHandlers 不会像您期望的那样工作，因为将重新抛出异常。
备选方案
还有其他方法可以使用协程来实现这种行为。 但是，这些解决方案无法系统地应用于所有用例。 让我们看看一些替代方案以及为什么/何时应该/不应该使用它们。
❌ GlobalScope
不应该使用 GlobalScope 的原因有很多：
- 加剧硬编码值。 如果您直接使用 GlobalScope，则可能很想对 Dispatcher 进行硬编码。 这是一个不好的做法！
- 它使测试变得非常困难。 由于您的代码将在不受控制的范围内执行，您将无法管理由它启动的工作。
- 你不能像我们在 applicationScope 中所做的那样为作用域中内置的所有协程建立一个公共 CoroutineContext。 相反，您必须将公共 CoroutineContext 传递给 GlobalScope 启动的所有协程。
建议：不要直接使用
❌ Android 中的 ProcessLifecycleOwner 作用域
在 Android 中，androidx.lifecycle:lifecycle-process 库中有一个 applicationScope 可用，可通过 ProcessLifecycleOwner.get().lifecycleScope 访问。
在这种情况下，您将注入 LifecycleOwner 而不是我们之前所做的 CoroutineScope。 在生产中，您将传入 ProcessLifecycleOwner.get() 并在单元测试中，您可以使用 LifecycleRegistry 创建一个假的 LifecycleOwner。
请注意，此范围的默认 CoroutineContext 使用 Dispatchers.Main.immediate，这可能不适合后台工作。 与 GlobalScope 一样，您必须将公共 CoroutineContext 传递给 GlobalScope 启动的所有协程。
由于上述所有原因，此替代方法需要的工作不仅仅是在 Application 类中创建 CoroutineScope。 此外，我个人不喜欢在 ViewModel/Presenter 下面的层中包含与 Android 生命周期相关的类，因为这些层应该与平台无关。
建议：不要直接使用
⚠️ 免责声明
如果你的 applicationScope 的 CoroutineContext 与 GlobalScope 或 ProcessLifecycleOwner.get().lifecycleScope 匹配，你可以直接分配它们，如下所示：
class MyApplication : Application() {
val applicationScope = GlobalScope
}
您仍然可以获得上述所有好处，如果将来需要，您可以轻松更改它。
❌ ✅ 使用NonCancellable
如本系列的第 2 部分所示，您可以使用 withContext(NonCancellable) 来调用已取消协程中的挂起函数。 我们建议使用它来执行可以挂起的清理代码。 但是，您不应该滥用它。
这样做非常危险，因为您会失去对协程执行的控制。 确实，它产生了更简洁、更易于阅读的代码，但是这在未来可能导致的问题是不可预测的。
其用法示例：
class Repository(
private val ioDispatcher: CoroutineDispatcher
) {
suspend fun doWork() {
withContext(ioDispatcher) {
doSomeOtherWork()
withContext(NonCancellable) {
veryImportantOperation()
}
}
}
}
尽管它很诱人，但您可能并不总是知道 veryImportantOperation() 背后是什么：也许它是一个外部库，也许实现是在一个接口后面，......会发生什么问题？
- 您将无法在测试中停止这些操作。
- 使用延迟的无限循环将无法再取消。
- 在其中收集 Flow 会使 Flow 无法从外部取消。
这些问题可能会导致微妙且难以调试的错误。
建议：仅用于挂起清理代码。
每当您需要一些工作超出其当前范围时，我们建议在您的 Application 类中创建一个自定义范围并在其中运行协程。 避免将 GlobalScope、ProcessLifecycleOwner 范围和 NonCancellable 用于此类工作。
译Coroutines & Patterns for work that shouldn’t be cancelled