从Android UI收集流的更安全方法

在安卓应用中，通常从UI层收集Kotlin flows以显示屏幕上的数据更新。但是，为了确保不做过多的工作、浪费资源（包括CPU和内存）或在视图转到后台时泄漏数据，您需要收集这些flows。

在本文中，您将学习如何使用Lifecycle.repeatOnLifecycle和Flow.flowWithLifecycle API来保护资源，以及为什么它们是UI层flow收集的良好默认值。

浪费资源
建议从应用程序层次结构的较低层公开Flow<T> API，而不考虑flow生产者实现细节。但是，您还应该安全地收集它们。

使用通道支持的cold flow或使用缓冲器（如buffer、conflate、flowOn或shareIn）的运算符不安全，无法与某些现有的API（例如CoroutineScope.launch、Flow<T>.launchIn或LifecycleCoroutineScope.launchWhenX）一起收集，除非当活动转到后台时手动取消启动协程的Job。这些API将保持底层flow的生产者活动状态，同时在后台向缓冲区发出项，从而浪费资源。

注：cold flow是一种类型的flow，当新的订阅者收集时，将按需执行代码块。

例如，考虑使用callbackFlow发出位置更新的以下flow：

// Implementation of a cold flow backed by a Channel that sends Location updates
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())
        .addOnFailureListener { e ->
            close(e) // in case of exception, close the Flow
        }
    // clean up when Flow collection ends
    awaitClose {
        removeLocationUpdates(callback)
    }
}

注意：在内部，callbackFlow使用通道，该通道在概念上非常类似于阻止队列，并且默认容量为64个元素。

使用任何前述的API从UI层收集这个flow，即使视图没有在UI中显示它们，也会持续不断地发出位置！请参见下面的示例：

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

        // Collects from the flow when the View is at least STARTED and
        // SUSPENDS the collection when the lifecycle is STOPPED.
        // Collecting the flow cancels when the View is DESTROYED.
        lifecycleScope.launchWhenStarted {
            locationProvider.locationFlow().collect {
                // New location! Update the map
            } 
        }
        // Same issue with:
        // - lifecycleScope.launch { /* Collect from locationFlow() here */ }
        // - locationProvider.locationFlow().onEach { /* ... */ }.launchIn(lifecycleScope)
    }
}

使用lifecycleScope.launchWhenStarted挂起协程执行。新位置将不会被处理，但callbackFlow生产者仍将发送位置。而使用lifecycleScope.launch或launchIn API更加危险，因为即使视图在后台运行，它仍然会继续消耗位置。这可能导致应用程序崩溃。

要解决这些API的问题，您需要在视图进入后台时手动取消收集以取消callbackFlow，并避免位置提供程序发出项并浪费资源。例如，可以执行以下操作：

class LocationActivity : AppCompatActivity() {

    // Coroutine listening for Locations
    private var locationUpdatesJob: Job? = null

    override fun onStart() {
        super.onStart()
        locationUpdatesJob = lifecycleScope.launch {
            locationProvider.locationFlow().collect {
                // New location! Update the map
            } 
        }
    }

    override fun onStop() {
        // Stop collecting when the View goes to the background
        locationUpdatesJob?.cancel()
        super.onStop()
    }
}

这是一个不错的解决方案，但这就是样板代码了，我的朋友们！如果说有一条关于Android开发者的普遍真理，那就是我们非常讨厌写样板代码。不需要写样板代码的最大好处之一就是代码量减少了，出错的机率也因此降低了！

Lifecycle.repeatOnLifecycle

既然我们都明白问题所在，现在是时候想出一个解决方案了。解决方案需要满足三个条件：1）简单易行，2）用户友好或易于记忆/理解，3）更重要的是：安全！不管具体实现细节如何，它都应该适用于所有用例。

不再多说了，你应该使用的API是Lifecycle.repeatOnLifecycle，它可以在lifecycle-runtime-ktx库中找到。

请注意：这些API需要lifecycle-runtime-ktx库2.4.0或更高版本才能使用。

看一看下面的代码：

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

        // Create a new coroutine since repeatOnLifecycle is a suspend function
        lifecycleScope.launch {
            // The block passed to repeatOnLifecycle is executed when the lifecycle
            // is at least STARTED and is cancelled when the lifecycle is STOPPED.
            // It automatically restarts the block when the lifecycle is STARTED again.
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                // Safely collect from locationFlow when the lifecycle is STARTED
                // and stops collection when the lifecycle is STOPPED
                locationProvider.locationFlow().collect {
                    // New location! Update the map
                }
            }
        }
    }
}

repeatOnLifecycle是一个挂起函数，它以Lifecycle.State作为参数，当生命周期达到该状态时，它会自动创建并启动一个新的协程，并取消正在执行该块的协程，当生命周期低于该状态时。

这避免了任何样板代码，因为当不再需要协程时，repeatOnLifecycle会自动执行取消协程的相关代码。正如你所猜想的那样，建议在activity的onCreate或fragment的onViewCreated方法中调用此API，以避免意外行为。请参考下面使用fragment的示例：

class LocationFragment: Fragment() {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        // ...
        viewLifecycleOwner.lifecycleScope.launch {
            viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
                locationProvider.locationFlow().collect {
                    // New location! Update the map
                }
            }
        }
    }
}

重要提醒：在片段中触发UI更新时应始终使用viewLifecycleOwner，但DialogFragments有时可能不存在View。对于DialogFragments，您可使用lifecycleOwner。

请注意：这些API在androidx.lifecycle：lifecycle-runtime-ktx：2.4.0库及更高版本中提供。

实质是：repeatOnLifecycle将挂起调用的协程，在生命周期的进入和离开目标状态时重新启动块的新协程，并在生命周期销毁时恢复调用协程。最后一点非常重要：只有在生命周期销毁时，调用repeatOnLifecycle的协程才会恢复执行。

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

        // Create a coroutine
        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.RESUMED) {
                // Repeat when the lifecycle is RESUMED, cancel when PAUSED
            }

            // `lifecycle` is DESTROYED when the coroutine resumes. repeatOnLifecycle
            // suspends the execution of the coroutine until the lifecycle is DESTROYED.
        }
    }
}

视觉图表

回到起点，通过使用lifecycleScope.launch启动的协程直接收集locationFlow是危险的，因为即使View在后台运行时，收集仍将继续发生。
repeatOnLifecycle可防止因资源浪费和应用程序崩溃而停止和重新启动流程收集，当生命周期进入和退出目标状态时。

Flow.flowWithLifecycle

当您只有一个要收集的Flow时，也可以使用Flow.flowWithLifecycle操作符。此API在幕后使用repeatOnLifecycle API，并在Lifecycle移动到目标状态时发出项目并取消底层生产者。

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

        // Listen to one flow in a lifecycle-aware manner using flowWithLifecycle
        lifecycleScope.launch {
            locationProvider.locationFlow()
                .flowWithLifecycle(lifecycle, Lifecycle.State.STARTED)
                .collect {
                    // New location! Update the map
                }
        }
        
        // Listen to multiple flows
        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                // As collect is a suspend function, if you want to collect
                // multiple flows in parallel, you need to do so in 
                // different coroutines
                launch {
                    flow1.collect { /* Do something */ }   
                }
                
                launch {
                    flow2.collect { /* Do something */ }
                }
            }
        }
    }
}

注意：此 API 名称取决于 Flow.flowOn(CoroutineContext) 操作，因为 Flow.flowWithLifecycle 改变了用于收集上游流的 CoroutineContext，而不影响下游。类似于 flowOn，Flow.flowWithLifecycle 添加了一个缓冲区，以防用户未跟上生产者的步伐。这是由于它的实现使用了 callbackFlow。

配置底层生产者

即使使用这些 API，也要注意可能会浪费资源的热流，即使没有任何人收集它们！也有一些合法的用例，但请谨记并进行必要的文档记录。即使浪费资源，使底层流生产者保持活动状态，对某些用例可能会有益处：可以立即获得新数据，而不是赶上并暂时显示陈旧数据。根据用例决定生产者是否需要始终处于活动状态。

MutableStateFlow 和 MutableSharedFlow API 公开了一个 subscriptionCount 字段，您可以使用它来在 subscriptionCount 为零时停止底层生产者。默认情况下，只要持有流实例的对象在内存中，它们就会保持生产者处于活动状态。不过有一些合法的用例，例如，通过 StateFlow 从 ViewModel 公开到 UI 的 UiState。这是可以的！这种用例要求 ViewModel 始终向 View 提供最新的 UI 状态。

类似地，Flow.stateIn 和 Flow.shareIn 操作员可以配置用于此的共享开始政策。WhileSubscribed() 将在没有活动观察者时停止底层生产者！相反，Eagerly 或 Lazily 将使底层生产者保持处于活动状态，只要它们使用的CoroutineScope处于活动状态。

注意：本文展示的 API 是从 UI 收集流的良好默认值，无论流实现细节如何，都应该使用这些 API。这些 API 做他们应该做的事情：如果 UI 不在屏幕上可见，则停止收集。如果应始终处于活动状态，则由流实现决定。

在 Jetpack Compose 中进行安全的 Flow 收集

如果您正在使用 Jetpack Compose 构建 Android 应用程序，请使用 collectAsStateWithLifecycle API 以生命周期感知的方式从 UI 中收集流。

collectAsStateWithLifecycle 是一个可组合函数，它以生命周期感知的方式从流中收集值，并将最新值表示为 Compose State。每当发生新的流发射时，这个 State 对象的值就会更新。这会导致所有 Composition 中 State.value 的使用都被重新编排。

默认情况下，collectAsStateWithLifecycle 使用Lifecycle.State.STARTED启动和停止从流中收集值。这发生在生命周期移动进入和退出目标状态时。此生命周期状态是您可以在 minActiveState 参数中配置的。

以下代码片段展示了此 API 的实际运用：

@Composable
fun LocationUI(locationFlow: Flow<Location>) {

    val location by locationFlow.collectAsStateWithLifecycle()

    // Current location, do something with it
}

与LiveData的比较

您可能已经注意到，此API的行为类似于LiveData，这是正确的！LiveData了解Lifecycle，其重新启动行为使其非常适合从UI观察数据流。Lifecycle.repeatOnLifecycle和Flow.flowWithLifecycle的情况也是如此！

在仅限Kotlin的应用程序中使用这些API收集flows是LiveData的自然替代品。如果您使用这些API来收集流，则LiveData没有比协程和flow更多的优势。此外，flows更灵活，因为它们可以从任何调度程序中收集，并且可以使用所有其操作符进行运行。与LiveData相反，LiveData的可用运算符有限，并且其值始终从UI线程观察。

在数据绑定中支持StateFlow

另一方面，您可能正在使用LiveData的原因是它受数据绑定的支持。Well，StateFlow也是如此！有关StateFlow在数据绑定中的支持的更多信息，请查看官方文档。

https://developer.android.com/topic/libraries/data-binding/observability#stateflow

使用Lifecycle.repeatOnLifecycle或Flow.flowWithLifecycle API以安全地从Android的UI层中收集flows。