Android 协程取消与异常处理：不应取消的操作方案

我们不需要取消该 Scope，因为希望它在应用程序进程存活期间保持活跃。因此不持有对 SupervisorJob 的引用。我们可以使用这个 Scope 来运行协程，这些协程通常需要比调用处（如 ViewModel、Activity、Fragment）更长的生命周期。

最佳实践：对于不应取消的操作，请从 Application 中创建 CoroutineScope，并用该 Scope 创建协程。

每当你创建新的 Repository 实例时，传入我们在上面创建的 applicationScope。

launch 还是 async？

根据 veryImportantOperation() 的行为，你需要选择合适的构造器：

• launch：如果你不需要返回结果，或者结果不重要。等待完成可使用 join()。注意必须在 launch 块内手动处理异常。
• async：如果你需要返回结果，需调用 await() 等待完成。

以下是使用 launch 的方式：

class Repository(
    private val externalScope: CoroutineScope,
    private val ioDispatcher: CoroutineDispatcher
) {
    suspend fun doWork() {
        withContext(ioDispatcher) {
            doSomeOtherWork()
            externalScope.launch {
                try {
                    veryImportantOperation()
                } catch (e: Exception) {
                    // 在此处记录日志或处理异常
                    e.printStackTrace()
                }
            }.join()
        }
    }
}

或者使用 async：

class Repository(
    private val externalScope: CoroutineScope,
    private val ioDispatcher: CoroutineDispatcher
) {
    suspend fun doWork(): Any {
        withContext(ioDispatcher) {
            doSomeOtherWork()
            return externalScope.async {
                veryImportantOperation()
            }.await()
        }
    }
}

在 ViewModel 中用 viewModelScope 调用上面的 doWork() 后，无论外部 scope 状态如何，都不会影响 externalScope 的执行，即使 viewModelScope 被破坏。此外，doWork() 会在 veryImportantOperation() 完成之前阻塞返回，如同普通 suspend 函数调用。

使用 withContext 的替代方案

另一种方式是将 veryImportantOperation() 包在 externalScope 的 context 中：

class Repository(
    private val externalScope: CoroutineScope,
    private val ioDispatcher: CoroutineDispatcher
) {
    suspend fun doWork() {
        withContext(ioDispatcher) {
            doSomeOtherWork()
            withContext(externalScope.coroutineContext) {
                veryImportantOperation()
            }
        }
    }
}

这种方式需要注意以下风险：

1. 取消行为：如果调用 doWork 的协程在执行 veryImportantOperation() 时被取消，它将一直执行到下一个退出节点，而不是在完成之后。
2. 异常处理：当在 withContext 中使用 context 时，externalScope 中的 CoroutineExceptionHandler 可能失效，异常将被重新抛出。

替代方案分析

除了上述方案，还有其他实现方式，但各有优劣。

❌ GlobalScope

不建议直接使用 GlobalScope，原因如下：

• 硬编码风险：容易写出硬编码的 Dispatchers，这是不良实践。
• 测试困难：代码在不受控制的 Scope 中执行，难以管理协程执行和模拟。
• 上下文限制：无法像 applicationScope 那样为所有协程建立通用的 CoroutineContext。

建议：不要直接使用 GlobalScope。

❌ ProcessLifecycleOwner scope in Android

在 Android 中，androidx.lifecycle:lifecycle-process 库提供了 applicationScope，可通过 ProcessLifecycleOwner.get().lifecycleScope 访问。

在这种模式下，你需要传入 LifecycleOwner 而非 CoroutineScope。生产环境中需传入 ProcessLifecycleOwner.get()。

注意：此 Scope 默认使用 Dispatchers.Main.immediate，不适合后台工作。且必须将公共 CoroutineContext 传递给启动的所有协程。

相比在 Application 类中创建 CoroutineScope，这种方法更繁琐，且增加了 ViewModel 层与 Android Lifecycle 的耦合。

建议：不要直接使用它。

✅ NonCancellable

你可以使用 withContext(NonCancellable) 在被取消的协程中调用 suspend 函数。这通常用于清理资源。

class Repository(private val ioDispatcher: CoroutineDispatcher) {
    suspend fun doWork() {
        withContext(ioDispatcher) {
            doSomeOtherWork()
            withContext(NonCancellable) {
                veryImportantOperation()
            }
        }
    }
}

尽管简洁，但风险很高：

• 不可控性：你无法控制协程的执行流。
• 测试问题：在测试中难以结束这些操作。
• 死循环风险：使用延迟的无限循环将永远无法被取消。
• Flow 污染：从其中收集 Flow 会导致 Flow 也变得无法从外部取消。

建议：仅用它来挂起清理操作相关的代码。

小结

1. 自定义 Scope：每当你需要执行超出当前作用域范围的工作时，建议在 Application 类中创建自定义作用域，并在此作用域中执行协程。
2. 避免滥用：在执行这类任务时，避免使用 GlobalScope、ProcessLifecycleOwner 作用域或滥用 NonCancellable。
3. 异常处理：务必在自定义 Scope 中配置 CoroutineExceptionHandler，防止未捕获异常导致整个 Scope 崩溃。
4. 测试策略：在单元测试中，可以通过注入 Mock Scope 或手动控制 Scope 生命周期来验证逻辑。
5. 内存管理：虽然 Application Scope 随进程死亡而终止，但仍需注意避免持有 Activity/Fragment 的强引用以防内存泄漏。