viewModelScope：是什么、与ViewModel的绑定及在Android中的工作方式

Android中的viewModelScope是什么？

viewModelScope — 是ViewModel接口上的扩展属性（extension property），在lifecycle-viewmodel-ktx库（从2.1.0版本开始）中添加。它提供了一个与ViewModel生命周期绑定的现成CoroutineScope。

// 内部结构（简化版）
val ViewModel.viewModelScope: CoroutineScope
    get() {
        val scope = this.getTag(JOB_KEY)
        if (scope != null) return scope
        return CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)
            .also { setTag(JOB_KEY, it) }
    }

Scope在首次访问时惰性（lazy）创建，并通过setTag缓存。使用SupervisorJob，这意味着一个子协程中的异常不会取消其他协程。默认调度器是Dispatchers.Main.immediate，如果调用已经在Main上，它会在主线程上执行代码而无需额外调度。

viewModelScope如何接收清理通知

当ViewModel离开生命周期（Activity完成或Fragment删除）时，系统调用clear()，触发onCleared()。在此回调中，viewModelScope取消其Job，递归地结束所有活跃协程。该机制通过Closeable接口实现，scope的Job注册为自动关闭的资源。

viewModelScope是如何工作的：与ViewModel生命周期的绑定

viewModelScope与ViewModel生命周期的绑定机制基于标记和onCleared回调。让我们逐步了解它是如何工作的。

步骤1：首次访问时创建scope

当ViewModel执行viewModelScope.launch { ... }时，getter检查JOB_KEY标记下是否有保存的scope。如果scope尚未创建——则创建新的CoroutineScope(SupervisorJob() + Dispatchers.Main.immediate)实例。Scope通过内部标记映射存储在ViewModel内部。

步骤2：协程的生命周期

通过viewModelScope.launch或viewModelScope.async启动的所有协程都是scope的SupervisorJob的子级。它们在主线程上工作（除非通过withContext指定了其他调度器）。只要ViewModel存活——协程可以是活跃的、挂起的或完成的。

步骤3：在onCleared时取消

当系统销毁ViewModel时，调用ViewModel.clear()。在clear()内部会发生以下情况：

• 调用onCleared()用于用户逻辑
• 关闭通过addCloseable注册的所有Closeable资源
• viewModelScope的Job进入Cancelled状态
• 所有子协程被递归取消
• 释放对scope的引用以便垃圾回收

抗屏幕旋转能力

在屏幕旋转时，Activity被重新创建，但ViewModel被保留（得益于ViewModelStoreOwner）。这意味着viewModelScope保持活跃，协程继续运行而不中断。Activity重新创建后，相同的ViewModel（和相同的scope）被重用——数据加载不会重新开始。

MVVM架构中的viewModelScope

MVVM（Model-View-ViewModel）——是Google推荐的Android应用程序架构。viewModelScope在其中作为异步操作的执行者占据核心位置。

viewModelScope在架构层中的作用

ViewModel通过viewModelScope启动协程，在其内部调用Repository的suspend函数。结果转换为StateFlow，由UI层观察。这种方案确保了清晰的职责分离和每个层的独立可测试性。

为什么viewModelScope在ViewModel中，而不是Fragment中

如果协程从Fragment启动，在屏幕旋转时会随着Fragment的销毁而被取消。ViewModel在旋转中存活，因此在其scope中启动的协程继续执行。这是viewModelScope在加载数据时相对于lifecycleScope的关键优势。

viewModelScope的使用示例

让我们看看在Kotlin的Android应用程序中使用viewModelScope的三个实际场景。

示例1：创建ViewModel时加载数据

class ProfileViewModel(
    private val repo: ProfileRepository
) : ViewModel() {

    private val _profile = MutableStateFlow<Profile?>(null)
    val profile: StateFlow<Profile?> = _profile

    init {
        loadProfile()
    }

    private fun loadProfile() {
        viewModelScope.launch {
            val result = repo.getProfile()
            _profile.value = result
        }
    }
}

在init块中立即启动配置文件的加载。协程默认在主线程上执行。Repository在其suspend函数内部使用withContext(Dispatchers.IO)进行网络请求，因此ViewModel不关心线程切换。

示例2：通过sealed class进行错误处理

sealed class UiState {
    object Loading : UiState()
    data class Success(val data: List<Item>) : UiState()
    data class Error(val message: String) : UiState()
}

fun fetchItems() {
    _state.value = UiState.Loading
    viewModelScope.launch {
        try {
            val items = repo.getItems()
            _state.value = UiState.Success(items)
        } catch (e: Exception) {
            _state.value = UiState.Error(e.message ?: "Unknown error")
        }
    }
}

UI状态通过sealed class UiState描述。ViewModel在每次更改时更新state。Fragment订阅StateFlow，只对当前状态做出反应，忽略重复旋转时的过时调用。

示例3：新请求时取消之前的协程

private var searchJob: Job? = null

fun search(query: String) {
    searchJob?.cancel()
    searchJob = viewModelScope.launch {
        delay(300)
        val results = repo.search(query)
        _searchResults.value = results
    }
}

在每个新的搜索请求中，之前的协程被取消。delay(300)实现了防抖（debounce）——搜索仅在输入暂停300毫秒后执行。这减少了服务器负载并防止了过时的结果。

viewModelScope vs lifecycleScope：何时选择哪个

两个scope都由AndroidX Lifecycle库提供，但绑定到不同的生命周期。它们之间的选择取决于任务类型。

Scope比较

Google建议

Google建议使用viewModelScope处理所有与数据加载和处理相关的任务。lifecycleScope应应用于与UI生命周期特定时刻绑定的操作——例如在屏幕首次出现时启动动画，或在离开屏幕时应停止的Location更新订阅。

使用viewModelScope时的典型错误

即使在文档良好的Android API中，开发人员也会犯典型错误。让我们看看四个最常见的问题。

错误1：scope取消后更新UI

最隐蔽的错误——在ViewModel清理后尝试更新StateFlow或LiveData。虽然viewModelScope在onCleared()时被取消，但协程可能会在实际取消时刻之前执行代码。使用isActive进行检查或依赖catch块的完成。

错误2：启动协程时不考虑SupervisorJob

viewModelScope内部使用SupervisorJob，隔离协程间的错误。但是如果在viewModelScope.launch中使用自己的Job()启动协程，该协程会成为SupervisorJob的子级，但不会受到其他协程错误时取消的保护。

错误3：一个scope中协程过多

虽然viewModelScope没有严格限制，但数千个活跃协程可能会降低系统速度。对于长数据列表，使用Flow配合collectLatest，而不是为每个元素创建单独的协程。

错误4：使用GlobalScope代替viewModelScope

如果意外导入GlobalScope而不是viewModelScope，协程在ViewModel清理时不会被取消。这会导致内存泄漏和潜在的崩溃。始终检查协程是否通过viewModelScope启动，特别是在继承的fragment中。