为什么要使用 .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. 什么是 MutableStateFlow 和 StateFlow?

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

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

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

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

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

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

虽然 strList 是 StateFlow 类型,它不能直接修改,但通过强制转换为 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?

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

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

相关推荐
汪海游龙7 小时前
流式回复结尾的那一下闪:逐帧定位 Compose 聊天列表的三处布局跳动
android·性能优化·kotlin
传奇开心果编程8 小时前
【Compose Multiplatform跨端声明式UI实用技术】第20课:CMP跨平台经典示例深度解析
kotlin·移动开发·跨平台·编程语言理论·开发范式·编程框架·声明式ui
敲代码的瓦龙10 小时前
Jetpack?lifecycle!!!
android·kotlin
Kapaseker15 小时前
为什么程序员始终无法彻底解决内存泄漏?
android·kotlin
汤姆宝库15 小时前
推理工程深拆:调度、量化与投机解码
android·开发语言·kotlin
传奇开心果1 天前
【Compose Multiplatform跨端声明式UI实用技术】第9课:跨平台 ViewModel 与状态架构
android·kotlin
andyweike2 天前
kotlin dsl library工程怎么配置
android·开发语言·kotlin
high一马平川3 天前
# SystemUI Dagger2 精读 · 第 2 章 @Inject:1200 处构造注入,和 1 处例外
android·java·kotlin
小铁-Android3 天前
CompletableDeferred:Kotlin 协程中用于一次性挂起通信的工具
android·kotlin