前言
在之前的《即学即用Android Jetpack - Paging 3》中，我们谈到了因为状态记录遇到的坑。
简单描述一下：
点击图中的皇冠按钮，会弹出 Nike、Adidas 和 其他 品牌的按钮，选中之后，页面中数据源只会包含该品牌的数据。
简单看一下，原来的结构，使用的 LiveData：
class MainViewModel : ViewModel() {
private val selectedBrand = MutableLiveData<String>()
// 2. 数据源根据selectedBrand自动发生切换
val shoes: LiveData<Shoe> = selectedBrand.switchMap {
// ... 切换成对应的数据源
}
// 1 选中品牌
fun selectBrand(brand: String) {
selectedBrand.value = brand
}
}
原来状态记录的核心是 LiveData，当状态方 selectedBrand 发生变化的时候，通过扩展方法 switchMap 将转化为 Paging 2 中对应的数据源 LiveData。
这套状态管理在 Paging 3 中理论上也可行，但是 Paing 3 不再主动支持在获取数据的时候帮你切换到子线程， 但是数据库的库 Room 是不支持在主线程发起请求的。
也许我们可以换一个思路，先建立一个子线程，再发起请求，但是得到的数据源 LiveData 会抛出另外一个错误，因为该 LiveData 是通过 setValue 方法传递数据的，使用过 LiveData 的同学应该都清楚，setValue 不能在子线程中调用。
使用 LiveData 看来行不通了，经过 Yu Jinyan 的提醒，使用 StateFlow，这也就是我们今天的主角。
官方的文档：https://developer.android.com/kotlin/flow/stateflow-and-sharedflow
一、冷流还是热流
在介绍正文之前，我先给大家介绍一下概念，冷流和热流。
如果之前了解过 Kotlin 的协程，那么你就有可能知道 Flow 是冷流，什么是冷流？简单来说，如果 Flow 有了订阅者 Collector 以后，发射出来的值才会实实在在的存在于内存之中，这跟懒加载的概念很像。
与之相对的是热流，我们即将介绍的 StateFlow 和 SharedFlow 是热流，在垃圾回收之前，都是存在内存之中，并且处于活跃状态的。
二、StateFlow
对于 StateFlow，官方的介绍是：
StateFlow是一个状态容器式可观察数据流，可以向其收集器发出当前状态更新和新状态更新。
乍一看，和 Flow 没什么区别，但是你看使用代码，却是有很大的区别。
1. StateFlow使用
第一步：创建 MutableStateFlow 并设置初始化的值。
class MainViewModel : ViewModel() {
val selected = MutableStateFlow<Boolean>(false)
}
第二步：同 Flow 一样，使用 collect 方法：
lifecycleScope.launch {
viewModel.selected.collect {
// ... 引起UI发生的变化
// 比如 某个按钮是否选中状态
}
}
第三步：可以给 selected设置值，从而引起 Ui 层的变化：
class MainViewModel : ViewModel() {
val selected = MutableStateFlow<Boolean>(false)
fun doSomeThing(value: Boolean) {
selected.value = value
}
}
普通的 Flow，是不具备 selected.value = value 这种能力的。
仔细观察一下，这个使用体验完全跟 LiveData 一样，所以它的使用场景和 LiveData 也很类似。
2. 和LiveData比较
那么 StateFlow 和 LiveData 有什么区别吗？
有两点区别：
- 第一点，
StateFlow必须有初始值，LiveData不需要。 - 第二点，当 View 变为 STOPPED 状态时，LiveData.observe() 会自动取消注册使用方，而从 StateFlow 或任何其他数据流收集数据则不会取消注册使用方。
对于 StateFlow 在界面销毁的时仍处于活跃状态，有两种解决方法：
- 使用
ktx将Flow转换为LiveData。 - 在界面销毁的时候，手动取消（这很容易被遗忘）。
class LatestNewsActivity : AppCompatActivity() {
...
// Coroutine listening for UI states
private var uiStateJob: Job? = null
override fun onStart() {
super.onStart()
// Start collecting when the View is visible
uiStateJob = lifecycleScope.launch {
latestNewsViewModel.uiState.collect { uiState -> ... }
}
}
override fun onStop() {
// Stop collecting when the View goes to the background
uiStateJob?.cancel()
super.onStop()
}
}
3. 如何解决开头的问题
关于开头的问题，给出的解决方案如下：
class MainViewModel : ViewModel() {
private val selectedKind = MutableStateFlow("全部")
// 2. 数据源根据selectedBrand自动发生切换
val shoes: Flow<Shoe> = selectedKind.flatMapLatest {
// ... 切换成对应的数据源
}
// 1. 选中品牌
fun selectedBrand(brand: String) {
selectedKind.value = brand
}
}
flatMapLatest 方法的作用：该方法可以产生一个新的 Flow，但是只处理最新接收到的值，比如，我先选中 Nike，后选中 Adidas，但是可能因为延迟，两个信号同时被接收，这个时候只会去请求 Adidas 的数据流。
新的结构：
由于 StateFlow 是热流，当它拥有一个初始的值后，在一开始就能通过 flatMapLatest 转换成对应的数据源，并且可以通过 selectedBrand 设置值，动态引起数据流 shoes 的变化。
三、SharedFlow
和 StateFlow 一样，SharedFlow 也是热流，它可以将已发送过的数据发送给新的订阅者，并且具有高的配置性。
1. SharedFlow使用场景
总的来说，SharedFlow 和 StateFlow 类似，他们都是热流，都可以用来存储状态，但 SharedFlow 配置灵活。
当你有如下场景时，需要使用 SharedFlow：
- 发生订阅时，需要将过去已经更新的n个值，同步给新的订阅者。
- 配置缓存策略。
2. SharedFlow的使用
简单写一个 Demo吧。
第一步：创建一个 MutableSharedFlow，对应的参数解释在注释中
class MainViewModel : ViewModel() {
val sharedFlow = MutableSharedFlow<Int>(
5 // 参数一：当新的订阅者Collect时，发送几个已经发送过的数据给它
, 3 // 参数二：减去replay，MutableSharedFlow还缓存多少数据
, BufferOverflow.DROP_OLDEST // 参数三：缓存策略，三种 丢掉最新值、丢掉最旧值和挂起
)
}
第二步：使用emit或者tryEmit方法
class MainViewModel : ViewModel() {
val sharedFlow = MutableSharedFlow<Int>(
// ....
)
// 初始化时调用
init {
for (i in 0..10) {
sharedFlow.tryEmit(i)
}
}
// 在按钮中调用
fun doAsClick() {
for (i in 11..20) {
sharedFlow.tryEmit(i)
}
}
}
当 MutableSharedFlow 中缓存数据量超过阈值时，emit 方法和 tryEmit 方法的处理方式会有不同：
-
emit方法：当缓存策略为BufferOverflow.SUSPEND时，emit方法会挂起，直到有新的缓存空间。 -
tryEmit方法：tryEmit会返回一个Boolean值，true代表传递成功，false代表会产生一个回调，让这次数据发射挂起，直到有新的缓存空间。
第三步：接收数据
接收数据的方式，跟普通的 Flow 没什么区别。
下面是我的全部代码：
class MainActivity : AppCompatActivity() {
private lateinit var viewModel: MainViewModel
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
viewModel = ViewModelProvider(this).get(com.example.coroutinedemo.viewmodel.MainViewModel::class.java)
val tvContent = findViewById<TextView>(R.id.tv_content)
// 启动第一个协程，接收初始化的数据
lifecycleScope.launch {
val sb = StringBuffer()
viewModel.sharedFlow.collect {
sb.append("<<${it}")
tvContent.text = sb
}
}
val btnGo = findViewById<Button>(R.id.btn_go)
val tvTwo = findViewById<TextView>(R.id.tv_2)
btnGo.setOnClickListener {
// 发送新的数据
viewModel.doAsClick()
// 发送新的数据以后，启动第二个协程
lifecycleScope.launch {
val sb = StringBuffer()
viewModel.sharedFlow.collect {
sb.append("<<${it}")
tvTwo.text = sb.toString()
}
}
}
}
}
点击一下 btnGo，猜一下，tvContent 和 tvTwo 分别展示什么内容？
上面是 tvContent，下面是 tvTwo。
3. 将冷流转化为SharedFlow
直接使用官网的代码，方法是使用 Flow 的扩展方法 shareIn：
class NewsRemoteDataSource(...,
private val externalScope: CoroutineScope,
) {
val latestNews: Flow<List<ArticleHeadline>> = flow {
...
}.shareIn(
externalScope,
replay = 1,
started = SharingStarted.WhileSubscribed() // 启动政策
)
}
重点是参数三，分别提供了三个启动策略：
-
SharingStarted.WhileSubscribed()：存在订阅者时，将使上游提供方保持活跃状态。 -
SharingStarted.Eagerly：立即启动提供方。 -
SharingStarted.Lazily：在第一个订阅者出现后开始共享数据，并使数据流永远保持活跃状态。
总结
Flow 给我的感觉就像古老的印刷术，版面定了就不可更改，不过，该版面可印刷多张内容；StateFlow 给我的感觉就像活字印刷，可以不停的更改版面，也可以使用同一个版面印刷很多内容。
如果你要使用 Flow 记录数据的状态，StateFlow 和 SharedFlow 会是一个不错的选择。StateFlow 和 SharedFlow 提供了在 Flow 中使用 LiveData 式更新数据的能力，但是如果要在 UI 层使用，需要注意生命周期的问题。
StateFlow 和 SharedFlow 相比，StateFlow 需要提供初始值，SharedFlow 配置灵活，可提供旧数据同步和缓存配置的功能。
精彩内容
如果觉得本文不错，「点赞」是对作者最大的鼓励～
技术不止，文章有料，关注公众号 九心说，每周一篇高质好文，和九心在大厂路上肩并肩。
参考链接：
