1. 为什么要在架构组件里引入协程Kotlin协程从1.3版本进入稳定期之后Android社区对它的讨论就没停过。但真正让协程从“语法糖”变成“架构级工具”的是它与Jetpack那一套架构组件ViewModel、Lifecycle、Room、WorkManager的深度整合。我刚开始接触协程的时候也走过一段弯路——在Activity里直接GlobalScope.launch结果横竖屏切换之后任务还在跑回调回来的时候View已经没了空指针一个接一个。后来才慢慢理解协程真正的价值不在于“写起来像同步代码”而在于它提供了一套结构化的并发模型而架构组件恰好是这套模型在Android端的落地载体。这个内容适合谁看如果你已经写过一些Kotlin知道suspend关键字大概是什么意思但还没系统地把协程用到ViewModel和Repository里那这篇就是给你准备的。如果你已经在用viewModelScope但说不清楚它为什么能在onCleared时自动取消那也能从里面找到答案。我会从设计思路讲到具体实现再到踩过的坑尽量把每个“为什么”都讲透。核心关键词Kotlin协程、ViewModel、Lifecycle、viewModelScope、结构化并发、Room、Flow。2. 整体设计思路与方案选型2.1 协程与架构组件的结合点在哪里Android的架构组件本质上是在解决一个问题生命周期。Activity和Fragment的生命周期由系统控制什么时候销毁你说了不算。而协程解决的是另一个问题异步任务的取消与作用域。这两者一结合就产生了一个很自然的诉求——让协程的生命周期跟着组件的生命周期走。在没有协程之前我们怎么处理异步用AsyncTask用ExecutorService加回调或者用RxJava的CompositeDisposable手动管理订阅。这些方案都能用但都有一个共同点取消逻辑需要手动写。你必须在onDestroy里调用disposable.clear()或者future.cancel(true)一旦忘了就是内存泄漏。协程的结构化并发模型改变了这个局面。它的核心思想是父协程会等待所有子协程完成取消父协程会自动取消所有子协程。这意味着只要我们把协程的根作用域绑定到组件的生命周期上取消就是自动的不需要手动干预。架构组件里的ViewModel提供了一个viewModelScopeLifecycle提供了lifecycleScopeLifecycleService提供了lifecycleScope这些扩展属性就是官方给出的“绑定方案”。你不需要自己写CoroutineScope直接用就行。2.2 为什么选择ViewModel作为协程的主战场在实际项目里协程的启动点应该放在哪里我的经验是大部分业务协程应该放在ViewModel里。原因有三点。第一ViewModel的生命周期比Activity长。横竖屏切换时Activity重建但ViewModel还在协程不会被打断。如果放在Activity里每次旋转屏幕都要重新请求数据体验很差。第二ViewModel不持有View的引用。协程在ViewModel里跑即使回调回来的时候View已经销毁了也不会造成内存泄漏。你只需要把数据通过LiveData或者StateFlow暴露出去View层自己决定要不要观察。第三viewModelScope的取消时机非常明确——onCleared()被调用时。这个时机比onDestroy更可靠因为onDestroy可能因为配置变更而触发但onCleared只在ViewModel真正要被销毁时才调用。那Repository层呢Repository里的suspend函数不需要自己的作用域它们应该由调用方通常是ViewModel的作用域来管理。这就是所谓的“挂起函数不拥有作用域”原则。如果你在Repository里自己launch一个协程那就破坏了结构化并发调用方无法取消它。2.3 方案对比协程 vs RxJava vs 回调我做过一个对比表格方便你理解为什么现在官方推荐协程。维度回调RxJava协程取消管理手动CompositeDisposable手动结构化并发自动代码可读性回调地狱链式调用学习曲线陡同步写法易读生命周期绑定无需配合AutoDispose官方扩展属性直接支持异常处理每层手动onError回调try-catch统一处理背压支持无Flowable支持Flow支持学习成本低高中RxJava在流式处理上确实强大但协程的Flow已经覆盖了大部分场景而且和suspend函数的互操作性更好。如果你的项目还在用RxJava不必急着全量替换可以新代码用协程老代码慢慢迁移。3. 核心细节解析与实操要点3.1 viewModelScope的底层实现很多人用viewModelScope用得很顺手但不知道它内部是怎么实现的。我一开始也以为它是什么黑魔法后来翻了源码才发现其实很简单。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) ) }关键点有三个。第一它用的是SupervisorJob这意味着一个子协程失败不会影响其他子协程。第二默认调度器是Dispatchers.Main.immediate所以你在viewModelScope里直接写UI操作是安全的。第三它通过setTagIfAbsent把作用域存在ViewModel的tag里在onCleared时通过CloseableCoroutineScope自动取消。注意Dispatchers.Main.immediate和Dispatchers.Main的区别在于如果当前已经在主线程immediate会立即执行而不重新post到消息队列。这在某些时序敏感的场景下很重要。3.2 挂起函数的调度与线程切换协程最容易被误解的一点是“协程就是轻量级线程”。这个说法不算错但容易让人以为协程自带线程切换。实际上协程本身不绑定任何线程它只是一个可挂起的计算单元。线程切换是由调度器Dispatcher决定的。在Android里常用的调度器有三个Dispatchers.Main主线程用于UI操作Dispatchers.IOIO密集型任务比如网络请求、文件读写、数据库操作Dispatchers.DefaultCPU密集型任务比如排序、解析、计算一个典型的Repository函数长这样suspend fun fetchUserData(userId: String): User withContext(Dispatchers.IO) { val response api.getUser(userId) val user response.toUser() userDao.insert(user) user }这里withContext(Dispatchers.IO)的作用是把这个代码块切到IO线程池执行执行完之后自动切回原来的调度器。如果你在viewModelScope里调用这个函数调用前后都在主线程中间的网络和数据库操作在IO线程写起来就像同步代码一样自然。实操心得不要在每个suspend函数里都写withContext。如果函数内部调用的其他suspend函数已经做了线程切换外层就不需要再切了。过度切换反而增加开销。3.3 异常传播与SupervisorJob的选择结构化并发里异常的传播规则是子协程抛出异常会取消父协程进而取消所有兄弟协程。这个规则在大多数情况下是合理的因为一个任务失败整个操作就没有继续的必要了。但有些场景下我们希望一个子任务的失败不影响其他子任务。比如一个页面同时请求用户信息和推荐列表用户信息失败了推荐列表还是应该显示。这时候就需要SupervisorJob。viewModelScope默认就是SupervisorJob所以你在里面launch多个协程一个失败了不会影响其他的。但要注意SupervisorJob只对直接子协程生效如果子协程里又launch了孙协程孙协程的失败还是会取消子协程。viewModelScope.launch { val userDeferred async { fetchUser() } val recommendDeferred async { fetchRecommend() } try { val user userDeferred.await() _userState.value UserState.Success(user) } catch (e: Exception) { _userState.value UserState.Error(e) } try { val recommend recommendDeferred.await() _recommendState.value RecommendState.Success(recommend) } catch (e: Exception) { _recommendState.value RecommendState.Error(e) } }这段代码里两个async是并行的各自处理异常互不影响。如果你把await放在同一个try里那第一个异常就会跳过第二个await推荐列表就永远不会更新了。3.4 Flow与LiveData的取舍架构组件里有两个可观察的数据容器LiveData和StateFlow。LiveData是生命周期感知的StateFlow是协程原生的。选哪个我的建议是新项目用StateFlow老项目保持LiveData。原因如下。LiveData的优势在于它自动感知生命周期在onStop时停止分发在onStart时重新分发最新值。但它的劣势也很明显它不支持背压不支持操作符而且它的value只能在主线程设置。StateFlow是Flow的一种支持所有Flow操作符可以在任何线程更新值而且它和协程的集成更自然。但它不是生命周期感知的你需要用repeatOnLifecycle或者flowWithLifecycle来手动处理。// ViewModel里 private val _uiState MutableStateFlowUiState(UiState.Loading) val uiState: StateFlowUiState _uiState.asStateFlow() // Activity里 lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.uiState.collect { state - render(state) } } }repeatOnLifecycle的作用是在STARTED状态时启动收集在STOPPED状态时取消收集重新STARTED时重新收集。这正好对应了LiveData的自动感知行为。注意repeatOnLifecycle是挂起函数它会在生命周期进入DESTROYED时抛出CancellationException所以不要把它放在try-catch里捕获所有异常否则会吞掉取消信号。4. 实操过程与核心环节实现4.1 项目依赖配置先看依赖。协程和架构组件的版本要匹配不然会出现一些奇怪的运行时错误。我用的版本组合如下// build.gradle (Module) dependencies { def lifecycle_version 2.6.2 def coroutines_version 1.7.3 def room_version 2.5.2 // ViewModel and LiveData implementation androidx.lifecycle:lifecycle-viewmodel-ktx:$lifecycle_version implementation androidx.lifecycle:lifecycle-runtime-ktx:$lifecycle_version implementation androidx.lifecycle:lifecycle-livedata-ktx:$lifecycle_version // Coroutines implementation org.jetbrains.kotlinx:kotlinx-coroutines-core:$coroutines_version implementation org.jetbrains.kotlinx:kotlinx-coroutines-android:$coroutines_version // Room implementation androidx.room:room-runtime:$room_version implementation androidx.room:room-ktx:$room_version kapt androidx.room:room-compiler:$room_version }lifecycle-viewmodel-ktx提供了viewModelScopelifecycle-runtime-ktx提供了lifecycleScope和repeatOnLifecyclelifecycle-livedata-ktx提供了liveData构建器。room-ktx提供了suspend函数和Flow支持。4.2 ViewModel层的协程实现假设我们要做一个用户详情页需要从网络拉取用户信息同时从数据库读取缓存。先看ViewModel的写法。class UserDetailViewModel( private val repository: UserRepository ) : ViewModel() { private val _uiState MutableStateFlowUserUiState(UserUiState.Loading) val uiState: StateFlowUserUiState _uiState.asStateFlow() fun loadUser(userId: String) { viewModelScope.launch { _uiState.value UserUiState.Loading val cachedUser repository.getCachedUser(userId) if (cachedUser ! null) { _uiState.value UserUiState.Success(cachedUser, isFromCache true) } try { val freshUser repository.fetchUser(userId) _uiState.value UserUiState.Success(freshUser, isFromCache false) } catch (e: IOException) { if (cachedUser null) { _uiState.value UserUiState.Error(网络异常请检查连接) } } catch (e: HttpException) { if (cachedUser null) { _uiState.value UserUiState.Error(服务异常请稍后重试) } } } } }这段代码有几个设计决策值得说明。第一先读缓存再请求网络这样用户能快速看到内容网络请求回来后再刷新。第二异常处理区分了IOException和HttpException给用户不同的提示。第三如果缓存有数据网络失败时不覆盖缓存用户至少还能看到旧数据。4.3 Repository层的挂起函数设计Repository层的原则是只提供suspend函数和Flow不自己创建作用域。class UserRepository( private val api: UserApi, private val userDao: UserDao, private val ioDispatcher: CoroutineDispatcher Dispatchers.IO ) { suspend fun getCachedUser(userId: String): User? withContext(ioDispatcher) { userDao.getUserById(userId) } suspend fun fetchUser(userId: String): User withContext(ioDispatcher) { val response api.getUser(userId) val user response.toUser() userDao.insert(user) user } fun observeUser(userId: String): FlowUser? { return userDao.observeUserById(userId) } }注意ioDispatcher是作为构造参数传入的这样在测试时可以替换成TestDispatcher。这是依赖注入的一个小技巧不需要引入额外的测试框架就能做单元测试。observeUser返回的是FlowRoom的Query注解如果返回FlowUser?Room会自动在数据变化时发射新值。这个Flow是冷的只有在被收集时才会查询数据库。4.4 Activity层的生命周期感知收集Activity层要做的事情很简单收集StateFlow渲染UI。class UserDetailActivity : AppCompatActivity() { private val viewModel: UserDetailViewModel by viewModels() override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_user_detail) lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.uiState.collect { state - when (state) { is UserUiState.Loading - showLoading() is UserUiState.Success - showUser(state.user, state.isFromCache) is UserUiState.Error - showError(state.message) } } } } val userId intent.getStringExtra(EXTRA_USER_ID) ?: return viewModel.loadUser(userId) } }repeatOnLifecycle是这里的关键。它保证了在页面不可见时停止收集避免不必要的UI更新和资源浪费。lifecycleScope是LifecycleOwner的扩展属性它的生命周期和Activity绑定在onDestroy时自动取消。实操心得repeatOnLifecycle必须放在lifecycleScope.launch里面不能直接调用。因为它是一个挂起函数需要一个协程作用域来运行。4.5 Room与协程的集成细节Room对协程的支持非常直接。Dao接口里可以直接声明suspend函数和返回Flow的函数。Dao interface UserDao { Query(SELECT * FROM users WHERE id :userId) suspend fun getUserById(userId: String): User? Query(SELECT * FROM users WHERE id :userId) fun observeUserById(userId: String): FlowUser? Insert(onConflict OnConflictStrategy.REPLACE) suspend fun insert(user: User) Transaction suspend fun insertAndGet(user: User): User { insert(user) return getUserById(user.id) ?: user } }Transaction注解可以加在suspend函数上Room会自动处理事务的开启和提交。注意insertAndGet这个函数它先插入再查询整个过程在一个事务里保证了原子性。Room的Flow查询是在每次表数据变化时重新执行查询然后发射新结果。这个机制是通过InvalidationTracker实现的不需要手动通知。5. 常见问题与排查技巧实录5.1 协程不执行或执行不完整这是新手最常遇到的问题。现象是代码写了但协程里的逻辑没跑或者只跑了一半。排查思路如下表现象可能原因解决方法协程完全不执行作用域已取消检查是否在onCleared之后调用协程执行到一半停止子协程异常导致父协程取消用SupervisorJob或try-catch协程不执行且无报错调度器线程池满了检查是否有阻塞操作占用IO线程协程延迟执行Dispatchers.Main队列繁忙用Main.immediate或切到IO我踩过最坑的一次是在viewModelScope.launch里调用了一个suspend函数这个函数内部用了withContext(Dispatchers.IO)但IO线程池被一个死循环占满了导致协程一直挂起。后来用Dispatchers.IO.limitedParallelism(64)限制了并发数才解决。5.2 取消信号被吞掉协程的取消是协作式的。如果协程内部有阻塞操作比如Thread.sleep、InputStream.read取消信号不会立即生效。更糟糕的是如果你在catch块里捕获了CancellationException但没有重新抛出取消信号就被吞掉了。// 错误写法 viewModelScope.launch { try { val data fetchData() _state.value Success(data) } catch (e: Exception) { // 这里会捕获CancellationException导致取消失效 _state.value Error(e.message) } } // 正确写法 viewModelScope.launch { try { val data fetchData() _state.value Success(data) } catch (e: CancellationException) { throw e // 重新抛出取消信号 } catch (e: Exception) { _state.value Error(e.message) } }注意CancellationException是协程取消的信号任何情况下都不应该被吞掉。如果你用了runCatching它也会捕获CancellationException需要特别小心。5.3 Flow收集导致的内存泄漏Flow的收集是挂起操作如果收集协程的生命周期比Flow本身长就会造成泄漏。比如在lifecycleScope里直接collect但Flow来自一个单例那Flow会一直持有Activity的引用。解决方法就是用repeatOnLifecycle或者flowWithLifecycle确保收集协程在生命周期结束时被取消。// 错误写法Activity销毁后收集还在继续 lifecycleScope.launch { viewModel.uiState.collect { ... } } // 正确写法生命周期停止时取消收集 lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.uiState.collect { ... } } }5.4 并发请求的异常处理前面提到过多个async并行时异常处理要分开。但还有一种情况你希望所有请求都完成即使有失败的最后统一处理。viewModelScope.launch { val results listOf( async { fetchA() }, async { fetchB() }, async { fetchC() } ).map { deferred - try { deferred.await() } catch (e: Exception) { null } } // results里失败的为null }这种写法叫“异常隔离”每个await单独捕获异常保证所有请求都执行完。但要注意如果fetchA失败了fetchB和fetchC还是会继续执行因为它们是在不同的async里。5.5 测试协程的常见坑测试协程时Dispatchers.Main在单元测试环境里是不可用的会抛IllegalStateException。解决方法是用Dispatchers.setMain(TestDispatcher())替换主调度器。ExperimentalCoroutinesApi class UserDetailViewModelTest { private val testDispatcher UnconfinedTestDispatcher() Before fun setup() { Dispatchers.setMain(testDispatcher) } After fun tearDown() { Dispatchers.resetMain() } Test fun loadUser success updates state() runTest { val repository FakeUserRepository() val viewModel UserDetailViewModel(repository) viewModel.loadUser(123) assertEquals(UserUiState.Success(...), viewModel.uiState.value) } }UnconfinedTestDispatcher会让协程立即执行不需要手动advanceUntilIdle。如果你用的是StandardTestDispatcher就需要用advanceUntilIdle()来推进虚拟时间。实操心得runTest是kotlinx-coroutines-test提供的测试构建器它会自动处理协程的等待和超时。默认超时是60秒如果测试里有延迟操作可以用runTest(timeout 10.seconds)来调整。6. 进阶场景与性能优化6.1 用Flow做防抖和去重搜索框的实时搜索是一个典型场景用户每输入一个字符就发一次请求但实际只需要最后一次的结果。用Flow的操作符可以很优雅地解决。private val searchQuery MutableStateFlow() val searchResults: StateFlowListItem searchQuery .debounce(300) .filter { it.length 2 } .distinctUntilChanged() .flatMapLatest { query - repository.search(query) .catch { emit(emptyList()) } } .stateIn( scope viewModelScope, started SharingStarted.WhileSubscribed(5000), initialValue emptyList() )debounce(300)表示300毫秒内的连续输入只取最后一次。filter过滤掉长度小于2的查询。distinctUntilChanged避免重复查询相同的关键词。flatMapLatest会在新查询到来时取消上一次查询。stateIn把冷流转换成热流WhileSubscribed(5000)表示在没有订阅者5秒后停止上游流。这套组合拳下来搜索的性能和体验都会好很多。6.2 并行分解与async有些场景下一个页面需要同时请求多个接口然后合并结果。用async可以并行执行总耗时等于最慢的那个请求而不是所有请求之和。suspend fun loadDashboard(): Dashboard coroutineScope { val userDeferred async { fetchUser() } val ordersDeferred async { fetchOrders() } val couponsDeferred async { fetchCoupons() } Dashboard( user userDeferred.await(), orders ordersDeferred.await(), coupons couponsDeferred.await() ) }coroutineScope会等待所有子协程完成如果有任何一个失败它会取消其他子协程并抛出异常。这比SupervisorJob更严格适合“要么全成功要么全失败”的场景。6.3 用SharedFlow做一次性事件StateFlow适合做状态但不适合做一次性事件比如弹Toast、导航。因为StateFlow会重放最新值配置变更后事件会被重复消费。这时候用SharedFlow更合适。private val _events MutableSharedFlowUiEvent() val events: SharedFlowUiEvent _events.asSharedFlow() fun onDeleteClick() { viewModelScope.launch { _events.emit(UiEvent.ShowToast(删除成功)) } }SharedFlow默认不重放emit是挂起函数如果缓冲区满了会挂起。可以用tryEmit做非挂起发射但要注意返回值表示是否成功。注意SharedFlow的收集也要用repeatOnLifecycle否则配置变更后事件会丢失。6.4 协程与WorkManager的配合WorkManager从2.1版本开始支持协程CoroutineWorker的doWork是suspend函数。class SyncWorker( context: Context, params: WorkerParameters ) : CoroutineWorker(context, params) { override suspend fun doWork(): Result { return try { val data repository.fetchLatestData() repository.saveToDatabase(data) Result.success() } catch (e: Exception) { if (runAttemptCount 3) { Result.retry() } else { Result.failure() } } } }CoroutineWorker默认在Dispatchers.Default上运行如果需要IO操作可以在doWork里用withContext(Dispatchers.IO)切换。runAttemptCount表示当前重试次数可以用来做退避策略。7. 我踩过的坑与经验总结第一个坑是在ViewModel的init块里启动协程。看起来没问题但如果ViewModel被创建后立即被销毁比如快速返回协程可能还没执行就被取消了。更安全的做法是在外部显式调用加载函数。第二个坑是用GlobalScope做全局任务。GlobalScope的生命周期和整个应用一样长里面的协程不会被自动取消。如果任务里持有Activity引用就会泄漏。正确的做法是用applicationScope自己创建一个和Application生命周期绑定的作用域。第三个坑是在Flow的collect里做耗时操作。collect是在收集协程的调度器上执行的如果你在collect里做数据库查询会阻塞整个收集。正确的做法是用map或者onEach配合flowOn来切换调度器。第四个坑是忘记处理CancellationException。前面说过runCatching和try-catch(Exception)都会捕获取消信号。我的做法是在catch块的第一行判断if (e is CancellationException) throw e确保取消信号能正常传播。第五个坑是在Repository里用viewModelScope。Repository不应该依赖ViewModel的作用域它应该只提供suspend函数由调用方决定在哪个作用域里执行。这样Repository才能被复用和测试。最后分享一个小技巧如果你不确定一个协程是否被正确取消可以在launch里加一个invokeOnCompletion回调打印取消原因。viewModelScope.launch { try { // 业务逻辑 } finally { println(Coroutine completed: ${coroutineContext[Job]?.getCancellationException()}) } }这个日志能帮你快速定位是正常完成还是被取消以及取消的原因是什么。我在排查一个“数据加载一半就停了”的问题时就是靠这个日志发现是上游的SupervisorJob被取消了。协程和架构组件的结合说到底就是一句话让正确的工具在正确的生命周期里做正确的事。ViewModel管作用域Repository管挂起函数Flow管数据流Lifecycle管收集时机。把这四者的关系理清楚剩下的就是熟练度问题了。