做了这么多年 Android，生命周期管理这个老生常谈的问题，到现在依然能在新项目里翻出不少花样。Activity 转个屏，异步任务还在跑，回调回来一访问已经销毁的 View，直接崩给你看；就算不崩，那也是一次次内存泄漏的积累。早期我们用 AsyncTask，后来用 RxJava 的 CompositeDisposable，再后来动手写各种绑定生命周期的工具类——说白了一件事：我们一直想让后台任务跟界面生命周期解耦，又不想让任务失控。
直到 Kotlin 协程普及，Android 官方把 ViewModel 和协程绑在一起，给出viewModelScope这套方案，才算是把这个纠缠多年的问题理干净了。ViewModel 帮我们跨配置变更保存数据，协程帮我们把异步任务放进结构化的作用域里，两者一配合，后台工作跟着 ViewModel 走，ViewModel 销毁则任务自动取消。这篇文章我会从源码到实战，把这对组合的原理、用法和坑一次性讲透。
1. 为什么 ViewModel 和协程天生就该组合在一起
先说清楚痛点在哪儿。Android 的界面对象，Activity 和 Fragment，是典型的不稳定生命周期对象。用户转个屏、切个后台、语言设置改一下，界面就会销毁重建。你在这样的对象里启动一个耗时任务，比如上传图片、请求详情数据，任务还没跑完，界面已经没了。这时候任务持有的回调还在指向旧界面，轻则白跑一趟浪费流量，重则内存泄漏、崩溃。
1.1 ViewModel 解决的其实是"数据活着"的问题
ViewModel 核心设计是：它不持有任何 View 引用，它只在配置变更（Configuration Change）时幸存下来，专属于某个 Activity 或 Fragment，直到页面真正被 finish 才清空。
这带来一个关键好处：数据存储的位置和界面显示的位置解耦了。ViewModel 里保存的数据，界面销毁重建后还能从同一个 ViewModel 实例里拿回来。这种特性，让 ViewModel 成为一个天然的"跨界面存活的数据容器"。
但这还只是个容器，异步任务要从哪里启动、在哪里结束，它自己管不着。没协程之前，你只是把数据放进 ViewModel 里，但启动异步任务还是得靠自己小心清理。这也是为什么早期用 ViewModel 依然容易泄漏——ViewModel 自己可不会帮你取消一个网络请求。
1.2 协程解决的"任务可控"问题
协程最核心的价值不是"轻量线程"，而是结构化并发。结构化并发的意思很简单：每一个协程都必须在某个作用域（Scope）里运行，作用域销毁时，里面所有子协程统一取消。
你可以把协程作用域理解成一棵树的树干：树干没了，整个树枝上挂着的所有叶子都会掉。这个机制天然解决了异步任务生命周期失控的问题——不需要你一个个去记录、去取消任务，只需要让任务跟对树干。
1.3 两者的生命周期时间线完美重合
现在把两个机制叠起来看：ViewModel 的存活范围是"界面存在期间 + 配置变更期间"，协程作用域的存活范围是"作用域取消之前"。让协程作用域绑在 ViewModel 上，意味着：
- 界面正在显示时，任务正常执行，可以安全更新 LiveData / StateFlow；
- 配置变更导致界面销毁重建时，ViewModel 还在，任务继续跑，不中断；
- 页面真正退出时，ViewModel 走
onCleared()，协程作用域自动取消，任务立刻终止。
这三条正好对应了开发中最常见的三种场景。以前我们要手动处理第一条和第三条，现在一行代码都不用写。这也是为什么官方推出viewModelScope之后，社区几乎一边倒地切到了这套方案。
2. viewModelScope 的源码逻辑：取消机制到底怎么生效的
viewModelScope不是魔法，它本质上是 ViewModel 内的一个扩展属性。每次访问它的时候，如果当前 ViewModel 实例里还没有协程作用域，就创建一个新的。官方实现大致是这样：
private const val JOB_KEY = "androidx.lifecycle.ViewModelCoroutineScope.JOB_KEY" val ViewModel.viewModelScope: CoroutineScope get() { val scope: CoroutineScope? = this.getTag(JOB_KEY) if (scope != null) { return scope } return setTagIfAbsent( JOB_KEY, CloseableCoroutineScope( SupervisorJob() + Dispatchers.Main.immediate ) ) }这段代码信息量很大，我拆开讲。
2.1 SupervisorJob：一个子协程挂了，不影响兄弟协程
这里用的是SupervisorJob()，它和普通Job()的关键区别在于：子协程失败会导致父 Job 取消，但不会波及兄弟子协程。
在viewModelScope里启动多个网络请求，其中一个抛了未捕获异常，正常情况下它只会令自己取消，而不会因为这一个失败把其他正常请求全部取消。这在 UI 场景很关键——你同时加载用户信息和商品列表，用户信息接口报错，商品列表不应该跟着被拉垮。
不过要注意了，这只是说不影响"兄弟"，异常本身还是会向上传播到CoroutineExceptionHandler或崩溃日志，只是不会破坏作用域内其他任务。
2.2 Dispatchers.Main.immediate：默认跑主线程
viewModelScope默认调度器是Dispatchers.Main.immediate。也就是说，你在viewModelScope.launch里写的代码，默认就在主线程执行。UI 任务可以直接写，不用再手动切线程。
Main.immediate比Main多了一个行为：如果当前线程已经是主线程，它不会重新分发，而是立即执行。这在某些情况下能避免一轮不必要的消息循环开销，也避免造成诡异的执行顺序问题。
2.3 onCleared() 里到底发生了什么
ViewModel 销毁时会调用clear()方法，在这个方法里，不只是调用onCleared()让你做清理，还会处理getTag(JOB_KEY)拿到的对象——也就是那个协程作用域——调用它的close()方法。
CloseableCoroutineScope实现了Closeable接口，close()就是取消整个作用域。取消的核心是调用Job.cancel()，这会触发协程树的逐层取消：所有正在跑的协程会在下一个挂起点抛出CancellationException，然后静默退出。
这就是为什么你在协程里做耗时操作，界面销毁后任务会自己停。前提是你得遵守协作式取消规则，这个我们后面讲坑的时候再细说。
2.4 取消是"协作式"的，不是强制中断
很多第一次接触协程的人会误以为cancel()是"掐断线程"。实际上不是。协程取消是协作式的：它只是把协程的 Job 状态标记为取消，协程内部在挂起点（比如delay()、网络请求的挂起函数处）会检查取消状态，然后抛CancellationException结束自己。
如果一段代码里全是没有挂起点的纯 CPU 循环，比如：
viewModelScope.launch { var i = 0 while (i < 1000000000) { i++ } updateUi(i) }这个循环不调用任何挂起函数，协程被取消也不会中断它，直到循环跑完，到下一个挂起点才会感知异常。这种行为在真实项目里的影响就是：你看着 Task 好像取消了，但 CPU 还在瞎忙。解决办法是循环里检查isActive，或者调用ensureActive()。
3. 实战中最常用的三种组合模式
原理看完了，说点能直接抄的。我在实际项目里，viewModelScope用得最多的就是三种模式。
3.1 模式一：数据加载 + UI 状态封装
这是最经典的写法。ViewModel 里暴露一个StateFlow给 UI 层，数据加载逻辑放在viewModelScope里：
class ArticleViewModel( private val repository: ArticleRepository ) : ViewModel() { private val _uiState = MutableStateFlow<ArticleUiState>(ArticleUiState.Loading) val uiState: StateFlow<ArticleUiState> = _uiState.asStateFlow() fun loadArticle(id: String) { _uiState.value = ArticleUiState.Loading viewModelScope.launch { try { val article = repository.getArticle(id) _uiState.value = ArticleUiState.Success(article) } catch (e: IOException) { _uiState.value = ArticleUiState.Error("网络异常，请重试") } } } }UI 层用repeatOnLifecycle收集这个StateFlow：
lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.uiState.collect { state -> when (state) { is ArticleUiState.Success -> showArticle(state.article) is ArticleUiState.Error -> showError(state.message) is ArticleUiState.Loading -> showLoading() } } } }这套写法的好处是：UI 层不收发任务，只收集状态；数据的加载、重试、错误处理全在 ViewModel 里，测试也好写。转屏之后StateFlow里的最新状态依然在，新界面一收集就能恢复显示，不用重新请求。
3.2 模式二：多个请求并行，等全部完成再合并
有些页面需要同时请求多个接口，比如详情页要把文章内容、作者信息、相关推荐一起展示。用协程的async写并行非常顺手：
viewModelScope.launch { try { val article = async { repository.getArticle(id) } val author = async { repository.getAuthor(id) } val recommend = async { repository.getRecommend(id) } val articleResult = article.await() val authorResult = author.await() val recommendResult = recommend.await() _uiState.value = ArticleUiState.Success( article = articleResult, author = authorResult, recommends = recommendResult ) } catch (e: Exception) { _uiState.value = ArticleUiState.Error(e.message ?: "加载失败") } }三个请求并发执行，总耗时约等于最慢的那个，而不是三个串行相加。async的await()是挂起函数，所以整个块还是能响应取消——页面退出时三个请求全部终止。
这里有个小细节：两个async共用一个父 Job，发生在一个async里的异常会连带取消另一个还没跑完的异步任务。如果你想"各自失败各自处理"，那就要用coroutineScope或者supervisorScope包一层。实际业务里，我倾向于这些接口本来就是同一屏的必需数据，有一个失败就都别等了，直接给错误提示，反而符合用户预期。
3.3 模式三：防重复提交 / 任务去重
用户疯狂点击刷新按钮，请求就会重复触发。在viewModelScope里处理这个很自然。最简单的方式是记录当前 Job，有任务在跑就不启动新的：
private var loadJob: Job? = null fun refresh() { if (loadJob?.isActive == true) { return } loadJob = viewModelScope.launch { // 执行刷新逻辑 } }更优雅的方案是直接用flow的conflate、debounce或者用Mutex做互斥。我的原则是：能用协程自身的结构化机制解决，就不要引入额外的标志位。比如多次触发只需要最后一次结果时，用flatMapLatest更省心：
fun refresh() { refreshTrigger.value = Unit } val result = refreshTrigger .map { repository.loadData() } .flatMapLatest { it } .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), initialValue)refreshTrigger是一个MutableStateFlow，每次赋值都会取消上一个还没完成的加载流，然后启动新的。既天然防重，又能保证只展示最后一次请求的结果，这个模式在搜索框、筛选条件变化这类场景里非常实用。
4. 我踩过的坑：看似正常却暗藏问题的写法
这套方案用久了，形形色色的坑我都踩过。有些坑的报错信息很迷惑，不往深处挖根本不知道是生命周期作用域的问题。挑几个有代表性的说说。
4.1 在 ViewModel 里用 GlobalScope：任务永远不取消
这个几乎是新人的通病。有人觉得viewModelScope.launch和GlobalScope.launch差不多，不就是启动个协程吗？差得太远了。GlobalScope的生命周期是整个应用进程，没有任何一个界面销毁能取消它。
我在一个项目里见过这样的代码：ViewModel 里用GlobalScope.launch调登录接口，登录成功后把结果写进本地存储。看起来没问题，但一旦用户登录途中退出页面，这个协程还在跑，里面的回调还持有 ViewModel 引用，内存泄漏就这样埋下来了。更隐蔽的是，如果登录逻辑里访问了依赖特定上下文的单例，页面销毁后这个单例还在被使用，状态就可能错乱。
我的建议：项目里全局搜一下GlobalScope，除了极少数工具类、上报类的应用级任务，其他地方一律不允许出现。
4.2 在 Repository 层启动协程，回来发现页面飞了
有些人喜欢在 Repository 里GlobalScope.launch或者自己建一个单例 Scope 跑网络请求。Repository 层有自己的作用域不是不行，但你必须非常清楚这个作用域和调用方没有父子关系。如果是没有生命周期的应用级作用域，那么调用方页面销毁后，请求照常执行，回调照常触发。
一旦这个回调直接改 UI，那就是经典的 "View not attached to window manager" 崩溃。即便你用的是 ViewModel +viewModelScope，如果 Repository 内部偷偷用别的 Scope 创建了子协程，它在viewModelScope取消时也不会被连带取消。
正确做法是：Repository 层的挂起函数保持纯挂起函数，由调用方决定运行在哪个作用域里。ViewModel 把viewModelScope传进去，任务就自然生命周期绑定；测试里可以把任意 TestScope 传进去，也好控制。
4.3 网络请求库没有真正挂起，取消请求成了摆设
很多网络库都有自己的协程支持，比如 Retrofit 的suspend fun写法。这种写法是能响应取消的——协程取消时会立刻取消底层的 OkHttp Call。但如果你用的是回调式的网络库，自己封装挂起函数时处理不当，取消机制就失效了。
我之前看过一种封装写法：
suspend fun <T> request(call: Call<T>): T = suspendCancellableCoroutine { continuation -> call.enqueue(object : Callback<T> { override fun onResponse(call: Call<T>, response: Response<T>) { continuation.resume(response.body()) } override fun onFailure(call: Call<T>, e: Throwable) { continuation.resumeWithException(e) } }) }问题在于：协程取消时continuation会取消，但底层的call并不知道，请求还在网络层跑。正确做法是用invokeOnCancellation把取消传递下去：
suspend fun <T> request(call: Call<T>): T = suspendCancellableCoroutine { continuation -> call.enqueue(object : Callback<T> { override fun onResponse(call: Call<T>, response: Response<T>) { continuation.resume(response.body()) } override fun onFailure(call: Call<T>, e: Throwable) { continuation.resumeWithException(e) } }) continuation.invokeOnCancellation { call.cancel() } }加了invokeOnCancellation之后，页面销毁，协程取消，底层请求才会真正断开。这个细节直接决定了你的取消是真取消还是假取消。
4.4 catch 里吞掉了 CancellationException，任务"取消不了"
这个坑非常经典，也特别难排查。代码长这样：
viewModelScope.launch { try { val data = repository.loadData() _uiState.value = Success(data) } catch (e: Exception) { _uiState.value = Error(e.message) } }看起来无害对不对？问题在于协程取消时抛出的也是Exception家族里的CancellationException。当任务执行到挂起点时被取消，挂起点抛出CancellationException，这个catch捕获它后不但没有重新抛出，还把_uiState.value设置成了Error。
结果就是：页面退出了，协程本该静默取消，却因为被 catch 拦截，UI 状态被改成了"错误"，而且协程并不会因为 catch 了取消异常就继续执行——它已经取消了。最诡异的是，某些场景下还会有类似 "Job was cancelled" 的异常继续冒出去。
正确处理方式是：catch 的时候先判断是不是CancellationException，是就重新抛出：
viewModelScope.launch { try { val data = repository.loadData() _uiState.value = Success(data) } catch (e: CancellationException) { throw e } catch (e: Exception) { _uiState.value = Error(e.message) } }或者用 Kotlin 的runCatching时同样要小心，它默认会捕获CancellationException。真的建议在团队代码规范里写明这一条，不然后面排查崩溃和状态异常会非常痛苦。
5. 继续深挖：viewModelScope 不够用的时候怎么办
viewModelScope解决了 90% 的问题，但剩下 10% 的场景需要自己动手。我说几个亲身遇到的场景和对应方案。
5.1 事件型数据流要用 Channel 而不是 StateFlow
这个不算作用域问题，但和 ViewModel + 协程搭配很常见。StateFlow适合保存"状态"，但如果你要发一次性事件，比如"弹出 Toast""跳转页面"，用StateFlow会丢事件——新的收集者只会收到当前值，不会收到过去的事件。
在 ViewModel 里配合协程的常用做法是用Channel：
class LoginViewModel : ViewModel() { private val _events = Channel<LoginEvent>(Channel.BUFFERED) val events = _events.receiveAsFlow() fun login() { viewModelScope.launch { // 登录逻辑 _events.send(LoginEvent.NavigateToHome) } } }UI 层同样用repeatOnLifecycle收集，事件消费后不会重放。这里要注意：send在Channel满了或没有接收者时是挂起的，如果页面在后台，repeatOnLifecycle暂停收集，send可能会挂住。所以Channel的容量和trySend的使用要看业务需求，别再send死等。
5.2 需要跨页面共享的任务作用域：自定义 Scope 挂在 ViewModel 上
有些业务里，两个页面共享同一个 ViewModel（比如通过activityViewModels()），或者一个 ViewModel 很重，内部要管理多个并行子任务。这时候官方viewModelScope已经够用，但你可能会想给它加一个CoroutineExceptionHandler统一处理异常，或者换一个更合适的调度器。
做法是给 ViewModel 定义一个自定义作用域：
class HeavyViewModel : ViewModel() { private val exceptionHandler = CoroutineExceptionHandler { _, throwable -> // 上报或记录异常 } private val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default + exceptionHandler) override fun onCleared() { scope.cancel() super.onCleared() } }注意onCleared()里必须手动cancel()，这是自定义 Scope 最容易漏掉的地方。漏掉一次，就是一个跟着 ViewModel 同生但不同死的常驻任务。
5.3 什么时候应该用 lifecycleScope 而不是 viewModelScope
很多人以为 UI 相关的协程就该全放 ViewModel，其实不对。lifecycleScope运行在Lifecycle上，和STARTED、DESTROYED状态直接挂钩。适合放lifecycleScope的是：
- 只在界面可见时才需要执行的任务，比如页面曝光统计；
- 直接依赖 View 的短暂操作，比如动画播放、滚动位置恢复；
- UI 层自己发起的、不需要跨转屏保留的临时任务。
viewModelScope适合的是：需要在配置变更后继续执行、结果需要保留下来的任务。比如详情页数据加载，转屏后不希望重新请求，就用 ViewModel；曝光统计这种转屏后没必要补报的任务，放lifecycleScope更合理。
这两个 Scope 各有分工，选错也不会出大问题，但会造成"多余的网络请求"或者"界面销毁了任务还在跑"这类不优雅的行为。现在repeatOnLifecycleAPI 成熟之后，UI 层收集数据流的写法基本固定了，配合两套 Scope 各司其职，项目会很干净。
5.4 测试：用 StandardTestDispatcher 控制虚拟时间
最后提一嘴测试。viewModelScope在单元测试里要配合Dispatchers.setMain使用，把主线程调度器换成测试调度器：
class ArticleViewModelTest { private val dispatcher = StandardTestDispatcher() @Before fun setUp() { Dispatchers.setMain(dispatcher) } @After fun tearDown() { Dispatchers.resetMain() } @Test fun `load article success`() = runTest { val repository = fakeRepository(successData) val viewModel = ArticleViewModel(repository) viewModel.loadArticle("1") advanceUntilIdle() assertEquals( ArticleUiState.Success(successData), viewModel.uiState.value ) } }关键在于advanceUntilIdle()或advanceTimeBy()来推进虚拟时间，让协程里的挂起操作按预期执行。如果你在测试里发现协程迟迟不执行，多半是忘了推进虚拟时间，或者忘记setMain。
最后说点实在的
ViewModel + 协程这套组合，真正解决的问题不是"怎么写代码"，而是"怎么不写代码"——不写onCleared()里的取消逻辑，不写CompositeDisposable.clear()，不写各种生命周期分发工具。我自己的体会是，从老一套迁移到新方案之后，界面层回调的非法状态崩溃少了一大半，排查内存泄漏时也省事很多。
不过它也不是银弹。协程取消是协作式的，用不好照样泄漏；作用域选错了照样失控。如果你刚接触这套组合，建议从最简单的viewModelScope.launch加载数据开始写起，先把取消机制吃透，再去碰复杂的并行和 Flow 组合。毕竟生命周期管理的核心，从来不是拿一个高级 API 压住所有问题，而是你真正理解了对象的存活时间，并让异步任务在正确的时间点老实结束。
