Jetpack MVVM七宗罪 之二:在 launchWhenX 中启动协程

4,806 阅读4分钟

这是我参与8月更文挑战的第2天,活动详情查看:8月更文挑战

首先承认这个系列有点标题党,Jetpack 的 MVVM 本身没有错,错在开发者的某些使用不当。本系列将分享那些 AAC 中常见的错误用法,帮助大家打造更健康的应用架构

Flow vs LiveData

自 StateFlow/ SharedFlow 出现后, 官方开始推荐在 MVVM 中使用 Flow 替换 LiveData。 ( 见文章:从 LiveData 迁移到 Kotlin 数据流 )

Flow 基于协程实现,具有丰富的操作符,通过这些操作符可以实现线程切换、处理流式数据,相比 LiveData 功能更加强大。 但唯有一点不足,无法像 LiveData 那样感知生命周期。

感知生命周期为 LiveData 至少带来以下两个好处:

  1. 避免泄漏:当 lifecycleOwner 进入 DESTROYED 时,会自动删除 Observer
  2. 节省资源:当 lifecycleOwner 进入 STARTED 时才开始接受数据,避免 UI 处于后台时的无效计算。

Flow 也需要做到上面两点,才能真正地替代 LiveData。

lifecycleScope

lifecycle-runtime-ktx 库提供了 lifecycleOwner.lifecycleScope 扩展,可以在当前 Activity 或 Fragment 销毁时结束此协程,防止泄露。

Flow 也是运行在协程中的,lifecycleScope 可以帮助 Flow 解决内存泄露的问题:

lifecycleScope.launch {
    viewMode.stateFlow.collect { 
       updateUI(it)
    }
}

虽然解决了内存泄漏问题, 但是 lifecycleScope.launch 会立即启动协程,之后一直运行直到协程销毁,无法像 LiveData 仅当 UI 处于前台才执行,对资源的浪费比较大。

因此,lifecycle-runtime-ktx 又为我们提供了 LaunchWhenStartedLaunchWhenResumed ( 下文统称为 LaunchWhenX

launchWhenX 的利与弊

LaunchWhenX 会在 lifecycleOwner 进入 X 状态之前一直等待,又在离开 X 状态时挂起协程。 lifecycleScope + launchWhenX 的组合终于使 Flow 有了与 LiveData 相媲美的生命周期可感知能力:

  1. 避免泄露:当 lifecycleOwner 进入 DESTROYED 时, lifecycleScope 结束协程
  2. 节省资源:当 lifecycleOwner 进入 STARTED/RESUMED 时 launchWhenX 恢复执行,否则挂起。

但对于 launchWhenX 来说, 当 lifecycleOwner 离开 X 状态时,协程只是挂起协程而非销毁,如果用这个协程来订阅 Flow,就意味着虽然 Flow 的收集暂停了,但是上游的处理仍在继续,资源浪费的问题解决地不够彻底。

资源浪费

举一个资源浪费的例子,加深理解

fun FusedLocationProviderClient.locationFlow() = callbackFlow<Location> {
    val callback = object : LocationCallback() {
        override fun onLocationResult(result: LocationResult?) {
            result ?: return
            try { offer(result.lastLocation) } catch(e: Exception) {}
        }
    }
    // 持续获取最新地理位置
    requestLocationUpdates(
        createLocationRequest(), callback, Looper.getMainLooper())

}

如上,使用 callbackFlow 封装了一个 GoogleMap 中获取位置的服务,requestLocationUpdates 实时获取最新位置,并通过 Flow 返回

class LocationActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // 进入 STATED 时,collect 开始接收数据
        // 进入 STOPED 时,collect 挂起
        lifecycleScope.launchWhenStarted {
            locationProvider.locationFlow().collect {
                // Update the UI
            } 
        }
    }
}

LocationActivity 进入 STOPED 时, lifecycleScope.launchWhenStarted 挂起,停止接受 Flow 的数据,UI 也随之停止更新。但是 callbackFlow 中的 requestLocationUpdates 仍然还在持续,造成资源的浪费。

因此,即使在 launchWhenX 中订阅 Flow 仍然是不够的,无法完全避免资源的浪费

解决办法:repeatOnLifecycle

lifecycle-runtime-ktx 自 2.4.0-alpha01 起,提供了一个新的协程构造器 lifecyle.repeatOnLifecycle, 它在离开 X 状态时销毁协程,再进入 X 状态时再启动协程。从其命名上也可以直观地认识这一点,即围绕某生命周期的进出反复启动新协程

使用 repeatOnLifecycle 可以弥补上述 launchWhenX 对协程仅挂起而不销毁的弊端。因此,正确订阅 Flow 的写法应该如下(以在 Fragment 中为例):

onCreateView(...) {
    viewLifecycleOwner.lifecycleScope.launch {
        viewLifecycleOwner.lifecycle.repeatOnLifecycle(STARTED) {
            viewMode.stateFlow.collect { ... }
        }
    }
}

当 Fragment 处于 STARTED 状态时会开始收集数据,并且在 RESUMED 状态时保持收集,最终在 Fragment 进入 STOPPED 状态时结束收集过程。

需要注意 repeatOnLifecycle 本身是个挂起函数,一旦被调用,将走不到后续代码,除非 lifecycle 进入 DESTROYED。

冷流 or 热流

顺道提一点,前面举得地图SDK的例子是个冷流的例子,对于热流(StateFlow/SharedFlow)是否有必要使用 repeatOnLifecycle 呢? 个人认为热流的使用场景中,像前面例子那样的情况会少一些,但是在 StateFlow/SharedFlow 的实现中,需要为每个 FlowCollector 分配一些资源,如果 FlowCollector 能即使销毁也是有利的,同时为了保持写法的统一,无论冷流热流都建议使用 repeatOnLifecycle

最后:Flow.flowWithLifecycle

当我们只有一个 Flow 需要收集时,可以使用 flowWithLifecycle 这样一个 Flow 操作符的形式来简化代码

lifecycleScope.launch {
     viewMode.stateFlow
          .flowWithLifecycle(this, Lifecycle.State.STARTED)
          .collect { ... }
 }

当然,其本质还是对 repeatOnLifecycle 的封装:

public fun <T> Flow<T>.flowWithLifecycle(
    lifecycle: Lifecycle,
    minActiveState: Lifecycle.State = Lifecycle.State.STARTED
): Flow<T> = callbackFlow {
    lifecycle.repeatOnLifecycle(minActiveState) {
        this@flowWithLifecycle.collect {
            send(it)
        }
    }
    close()
}

系列文章

Jetpack MVVM七宗罪之一: 拿 Fragment 当 LifecycleOwner