9、StateFlow 与 Compose：在 Compose 中收集 StateFlow、collectAsState 的使用

说实话，StateFlow 和 Compose 的搭配，是我在项目中最常用的组合之一。记得我刚从 LiveData 迁移到 StateFlow 那会儿，心里还有点打鼓——毕竟 LiveData 在 Android 圈子里用了那么多年。但用了一段时间后，我不得不承认：StateFlow + Compose 的组合拳，打起来确实顺手。

这一节，我们就来聊聊 StateFlow 在 Compose 里到底怎么用，以及那个关键的 collectAsState() 到底干了什么。

为什么是 StateFlow？

你可能会问：LiveData 不是也能用吗？为什么非要 StateFlow？

嗯，这里有个关键点。Compose 是声明式 UI，它需要的是一个「可观察的状态容器」。LiveData 虽然也能观察，但它不是 Kotlin 协程原生支持的。而 StateFlow 是 Kotlin 协程家族的一员，天然支持 Flow 的各种操作符，比如 map、filter、combine 等等。

我在项目中遇到过这样一个场景：需要从两个数据源合并数据，然后更新 UI。用 LiveData 的话，我得写 MediatorLiveData，代码又臭又长。换成 StateFlow 后，一个 combine 操作符就搞定了。你说香不香？

核心要点： StateFlow 是 Flow 的一种特殊实现，它始终持有最新的值，并且只会发射更新的值。这正好符合 Compose 的「状态驱动 UI」理念。

collectAsState：桥接 Flow 和 Compose

说白了，collectAsState() 就是一个桥梁。它把 StateFlow 里的数据，转换成 Compose 能识别的 State 对象。一旦 StateFlow 的值变了，Compose 就会自动重组（recompose）用到这个状态的组件。

来看个最简单的例子：

// ViewModel 中
class MyViewModel : ViewModel() {
    private val _count = MutableStateFlow(0)
    val count: StateFlow<Int> = _count.asStateFlow()

    fun increment() {
        _count.value++
    }
}

// Composable 中
@Composable
fun CounterScreen(viewModel: MyViewModel) {
    val count by viewModel.count.collectAsState()

    Column {
        Text("当前计数：$count")
        Button(onClick = { viewModel.increment() }) {
            Text("加一")
        }
    }
}

你看，代码非常简洁。collectAsState() 返回的是一个 State<Int>，我们用 by 委托把它解构出来。当 _count.value 变化时，Compose 会自动更新 Text 组件。

小技巧： 我个人习惯在 ViewModel 中暴露 StateFlow 而不是 MutableStateFlow。用 asStateFlow() 转一下，可以防止外部直接修改状态。这是 Kotlin 官方推荐的做法。

生命周期感知：自动取消收集

你想想看，如果 StateFlow 一直在后台发射数据，而界面已经退出了，会发生什么？轻则内存泄漏，重则崩溃。

好消息是，collectAsState() 是生命周期感知的。当 Composable 退出组合（composition）时，它会自动取消收集。这一点和 LiveData 的 observe() 类似，但实现方式不同。

我曾经在早期版本中踩过一个坑：在 LaunchedEffect 里手动调用 flow.collect()，结果忘了处理取消逻辑。后来改用 collectAsState()，再也没操心过这事。

注意： 如果你在非 Composable 作用域（比如 ViewModel 的 init 块）里收集 Flow，一定要用 viewModelScope 来管理协程生命周期。否则，Flow 可能会一直运行，导致资源浪费。

StateFlow 与 LiveData 的对比

为了让你更直观地理解，我整理了一个对比表格：

特性 StateFlow LiveData
协程原生支持 是 否（需要额外转换）
操作符丰富度 高（map、filter、combine 等） 低（只有 map、switchMap 等少数）
生命周期感知 通过 collectAsState() 实现 内置
初始值 必须提供 可选
粘性事件 有（默认发射最新值） 有

从表格可以看出，StateFlow 在协程生态中的优势很明显。但 LiveData 也有它的场景——比如在 Java 代码中使用，或者和旧版架构组件混用。

实战：带搜索功能的列表

光说不练假把式。我们来看一个实际项目中的例子：搜索用户列表。

// ViewModel
class UserViewModel : ViewModel() {
    private val _searchQuery = MutableStateFlow("")
    val searchQuery: StateFlow<String> = _searchQuery.asStateFlow()

    private val _users = MutableStateFlow<List<String>>(emptyList())
    val users: StateFlow<List<String>> = _users.asStateFlow()

    init {
        // 监听搜索词变化，自动过滤
        viewModelScope.launch {
            searchQuery
                .debounce(300) // 防抖，避免频繁请求
                .filter { it.length >= 2 } // 至少输入2个字符
                .flatMapLatest { query ->
                    // 模拟网络请求
                    searchUsers(query)
                }
                .collect { result ->
                    _users.value = result
                }
        }
    }

    fun onQueryChanged(query: String) {
        _searchQuery.value = query
    }

    private suspend fun searchUsers(query: String): List<String> {
        delay(500) // 模拟网络延迟
        return listOf("用户A: $query", "用户B: $query", "用户C: $query")
    }
}

// Composable
@Composable
fun UserSearchScreen(viewModel: UserViewModel) {
    val query by viewModel.searchQuery.collectAsState()
    val users by viewModel.users.collectAsState()

    Column(modifier = Modifier.padding(16.dp)) {
        OutlinedTextField(
            value = query,
            onValueChange = { viewModel.onQueryChanged(it) },
            label = { Text("搜索用户") }
        )

        Spacer(modifier = Modifier.height(8.dp))

        LazyColumn {
            items(users) { user ->
                Text(
                    text = user,
                    modifier = Modifier.padding(8.dp)
                )
            }
        }
    }
}

这个例子中，我用 debounce 做了防抖处理，用 flatMapLatest 确保只处理最新的搜索请求。这些操作符在 LiveData 里实现起来要麻烦得多。

关键点： flatMapLatest 会取消前一个未完成的请求，只保留最新的。这在搜索场景中非常实用，避免了「先发后至」的问题。

StateFlow 的冷流 vs 热流

这里有个概念需要澄清。StateFlow 是热流（hot flow），意思是它不依赖收集者就能发射数据。而普通的 Flow 是冷流（cold flow），只有被收集时才会开始发射。

为什么 StateFlow 是热流？因为它始终持有最新的值，即使没有收集者，它也会在后台更新。这正好符合 ViewModel 的场景——数据在后台更新，UI 只需要在需要时获取最新值即可。

我记得有一次，同事把 StateFlow 当冷流用，在 flowOf() 外面套了一层 .stateIn()，结果数据死活不更新。后来发现是 stateIn 的 sharingStarted 参数没配对。嗯，这里要注意：stateIn 默认是 SharingStarted.Eagerly，但如果你用 WhileSubscribed()，它会在没有收集者时停止上游。

SVG 流程图：StateFlow 在 Compose 中的数据流

为了让你更直观地理解整个过程，我画了一张图：

StateFlow 在 Compose 中的数据流 ViewModel MutableStateFlow asStateFlow() StateFlow 持有最新值 collectAsState() Compose 重组 UI 数据源更新 _value 变化 UI 自动更新 重组触发 核心流程：数据变化 → StateFlow 更新 → collectAsState 感知变化 → Compose 重组 整个过程无需手动通知，完全由 Compose 的声明式机制自动完成

常见陷阱与避坑指南

最后，分享几个我在项目中踩过的坑：

  • 不要在 Composable 中直接修改 StateFlow：我曾经看到有人直接在 Composable 里写 viewModel.count.value++。这破坏了单向数据流，应该通过 ViewModel 的方法来修改。
  • 注意 collectAsState 的线程：collectAsState() 默认在 Dispatchers.Main 上收集。如果你的 StateFlow 在后台线程发射数据，Compose 会自动切换到主线程更新 UI，不用担心线程问题。
  • 避免在 collectAsState 中做耗时操作：collectAsState() 返回的是 Compose 状态，任何耗时操作都应该在 ViewModel 中完成，而不是在 Composable 里。
  • StateFlow 的初始值很重要：因为 StateFlow 必须提供初始值，所以 UI 在第一次收集时就能拿到数据，不会出现空指针。这一点比 LiveData 更安全。
我的建议： 如果你在写新项目，直接用 StateFlow 替代 LiveData。如果是在维护老项目，可以逐步迁移，先从简单的数据流开始。不用急，一口吃不成胖子。

好了，关于 StateFlow 和 collectAsState 的内容就聊到这里。记住一句话：StateFlow 是数据源，collectAsState 是桥梁，Compose 是最终呈现。这三者配合好了，你的代码会变得非常干净、可维护。

公众号：蓝海资料掘金营，微信 deep3321

← 上一章 📖 返回目录 下一章 →