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

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

Flow vs LiveData

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

Flow 基于协程实现，具备丰富的操做符，经过这些操做符能够实现线程切换、处理流式数据，相比 LiveData 功能更增强大。但惟有一点不足，没法像 LiveData 那样感知生命周期。ide

感知生命周期为 LiveData 至少带来如下两个好处：函数

避免泄漏：当 lifecycleOwner 进入 DESTROYED 时，会自动删除 Observer

节省资源：当 lifecycleOwner 进入 STARTED 时才开始接受数据，避免 UI 处于后台时的无效计算。

Flow 也须要作到上面两点，才能真正地替代 LiveData。oop

lifecycleScope

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

Flow 也是运行在协程中的，lifecycleScope 能够帮助 Flow 解决内存泄露的问题：ui

lifecycleScope.launch {
    viewMode.stateFlow.collect { 
       updateUI(it)
    }
}
复制代码

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

所以，lifecycle-runtime-ktx 又为咱们提供了 LaunchWhenStarted 和 LaunchWhenResumed （下文统称为 LaunchWhenX ）lua

launchWhenX 的利与弊

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

避免泄露：当 lifecycleOwner 进入 DESTROYED 时， lifecycleScope 结束协程

节省资源：当 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

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