为什么要使用 .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() 向流中发送事件,避免了意外修改流内容的副作用。

相关推荐
ZealSinger1 天前
Kotlin后端别再用GlobalScope
kotlin·协程·后端开发·结构化并发
mmsx2 天前
Android 上的 AI 对话链路:流式响应、SSE 解析与三级降级
android·kotlin
YB13752 天前
Kotlin 引用操作符::
kotlin
维克兜率天3 天前
【维克】弹性策略:用“乖离率“捕捉超跌反弹
android·开发语言·python·深度学习·kotlin·量化
传奇开心果编程3 天前
【用案例学Material 3 Expressive】第1课:从一封邮件开始,感受安卓设计新语言的表现力
android·学习·ui·kotlin·android jetpack
mmsx3 天前
Android 状态保持:进程被杀、旋屏与后台任务的存活术
android·kotlin
传奇开心果编程4 天前
【Jetpack Compose进阶学与练】第14课:系列收尾复习总结;Compose项目常见坑点汇总;学习路线与后续学习方向
android·学习·ui·kotlin·android jetpack
花开路口4 天前
线程安全完全指南:从 Java 到 Kotlin,一文吃透并发编程
java·kotlin
hai_android4 天前
子 View 被压小时,如何向父容器"告状"?——MEASURED_STATE_TOO_SMALL 向上传递机制
android·kotlin·android jetpack
怪奇云呼军4 天前
从 ElevenLabs 看工具调用:闪电智能 Voice Agent 的企业集成验收设计
android·大数据·运维·服务器·网络·人工智能·kotlin