为什么要使用 .asStateFlow() 而不是直接赋值?

记录开发过程中疑问,如果说的不对,欢迎提出修改

这里我使用了两个MutableStateFlow和两个StateFlow做说明,其中strList是由_strList.asStateFlow()赋值,而str2List_strList直接赋值。这两种在代码运行都能正常运行,这也是为什么我对此有疑问,从而做下笔记梳理

示例代码及运行结果

kotlin 复制代码
private val _strList = MutableStateFlow<List<String>>(listOf("A", "B", "C"))
val strList: StateFlow<List<String>> = _strList.asStateFlow()

private val _str2List = MutableStateFlow<List<String>>(listOf("X", "Y", "Z"))
val str2List: StateFlow<List<String>> = _str2List

@Test
fun testAsStateFlow() = runTest {
    launch {
        strList.collect { println("strList 收到新值: $it") }
    }
    launch {
        delay(500) 
        (strList as? MutableStateFlow)?.value = listOf("A", "B", "C", "D")
    }
    launch {
        str2List.collect { println("str2List 收到新值: $it") }
    }
    launch {
        delay(500)
        (str2List as? MutableStateFlow)?.value = listOf("A", "X", "Y", "Z")
    }
}

下面是运行结果,可以看出通过.asStateFlow() 赋值的strList 无法直接通过asStateFlow转换从而修改参数,而str2List却可以

strList 收到新值: A, B, C

str2List 收到新值: X, Y, Z

str2List 收到新值: A, X, Y, Z

1. 什么是 MutableStateFlowStateFlow

  • MutableStateFlow 是一种可变的状态流,它允许我们通过 value 属性修改流中的状态。
  • StateFlow 是一种不可变的状态流,它只暴露给外部读取状态的能力,而不能修改状态。

通常,在封装状态时,我们将 MutableStateFlow 定义为私有属性(例如 _strList),而将其暴露为不可变的 StateFlow(例如 strList),这样外部代码只能读取状态,而无法修改它。

2. 为什么不建议直接赋值?

在上述代码中,如果直接将 _strList_str2List 作为 StateFlow 来暴露,会导致外部代码可以通过强制转换或直接访问 _strList_str2List 来修改其值。这样可能会破坏状态的不可变性,导致不可预测的副作用或状态变更。

例如,在以下代码中,尝试直接修改 strList 的值:

ini 复制代码
(strList as? MutableStateFlow)?.value = listOf("A", "B", "C", "D")

虽然 strListStateFlow 类型,它不能直接修改,但通过强制转换为 MutableStateFlow 类型,代码可以绕过不可变性并直接修改 value 属性。这违背了状态不可变性的设计原则,容易导致不可控的状态更改。

3. asStateFlow 的作用

使用 asStateFlow() 方法可以将 MutableStateFlow 转换为不可变的 StateFlow。这样,外部代码只能读取状态,而无法修改它。通过这种方式,我们可以确保状态的不可变性并防止外部代码直接更改状态。

swift 复制代码
val strList: StateFlow<List<String>> = _strList.asStateFlow()

这样,外部代码只能使用 strList.collect { ... } 来收集状态的变化,而不能修改 strList 的值。这使得状态管理更加安全和可控。

4. 总结

  • MutableStateFlow 提供了修改状态的能力,而 StateFlow 只允许读取状态。
  • 使用 asStateFlow() 可以将 MutableStateFlow 转换为不可变的 StateFlow,从而保护状态不被外部代码直接修改。
  • 通过这种方式,我们可以确保状态的不可变性,减少副作用,使代码更加健壮和可维护。

5.延伸问题:为什么要使用 asSharedFlow

类似于 StateFlowSharedFlow 也有可变和不可变的版本。MutableSharedFlow 允许外部代码通过 emit() 向流中发送事件,而 SharedFlow 则是一个只读流,只能被外部代码订阅和收集,不能直接修改流中的内容。

为了确保流的不可变性,应该使用 asSharedFlow() 方法将 MutableSharedFlow 转换为不可变的 SharedFlow。这样,外部代码只能订阅事件流,而不能通过 emit() 向流中发送事件,避免了意外修改流内容的副作用。

相关推荐
Kapaseker2 天前
别再只用 Loading、Success、Error 表示所有页面状态了
android·kotlin
雨白2 天前
深入理解 Kotlin 协程 (九):互通有无,解构 Channel 缓冲策略与底层无锁机制
android·kotlin
蜡台4 天前
Android WebView 设计指南
android·java·kotlin
Kapaseker4 天前
深入理解 Compose 副作用
kotlin
雨白4 天前
深入理解 Kotlin 协程 (八):拾遗补阙,探秘官方框架的调度细节与取消闭环
android·kotlin
GitLqr5 天前
别被“Flutter 传感器延迟 150ms”带偏了:这可能只是你的实现方式错了
flutter·架构·kotlin
我命由我123455 天前
Android 在构建过程中,发现有两个依赖库都包含了相同路径的资源文件
android·java·开发语言·java-ee·kotlin·android-studio·android runtime
Coffeeee5 天前
谷歌的一个优化建议,让我重新学了一遍Android里面如何正确处理位图
android·google·kotlin
Android打工仔6 天前
Continuation 到底是谁创建的?
android·kotlin
Android-Flutter7 天前
android fragment 使用
android·kotlin