LiveData的缺点:
而LiveData它的缺点其实也非常明显,LiveData肩负着为UI提供数据订阅的能力,所以他的数据订阅只能在主线程,可能会有小伙伴说可以在子线程通过postValue去发布数据啊。但是其实这个postValue是有坑的,被坑过的小伙伴都应该知道短时间通过多次postValue,中间可能会存在数据的丢失。
而且在复杂的场景LiveData支持的能力确实有一些尴尬。
总结一下LiveDta有几个缺点:
在异步线程修改数据可能存在数据丢失的问题
在复杂的场景,LiveData的能力有一些捉襟见肘
LiveData你别走
《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】 完整内容开源分享
但我们也不应该踩一捧一,确实LiveData整体上有更低的学习成本,在一些简单的场景LiveData已经完全能够满足我们的需要。
而且官方也说过并不会废弃LiveData,原因是:
用 Java 写 Android 的人还需要它,因为Flow是协程的东西,所以如果你是用 Java 的,是没有办法使用Flow的,所以LiveData还是有意义的。
LiveData 的使用比较简单,而且功能上对于简单场景也是足够的,而 RxJava 和 Flow 这种东西学起来就没 LiveData 那么直观。
Flow
====
Flow是Google官方提供的一个类似于RxJava的响应式编程模型。它是基于Kotlin协程的。 它相对于Rxjava具有以下特点:
具有更友好的API,学习成本较低
跟Kotlin协程、LiveData结合更紧密,Flow能够转换成LiveData,在ViewModel中直接使用
结合协程的作用域,当协程被取消时,Flow也会被取消,避免内存泄漏
我们知道Flow的特点之一就是冷流。那么什么是冷流呢?
冷流:当数据被订阅的时候,发布者才开始执行发射数据流的代码。并且当有多个订阅者的时候,每一个订阅者何发布者都是一对一的关系,每个订阅者都会收到发布者完整的数据。
热流:无论有没有订阅者订阅,事件始终都会发生。当热流有多个订阅者时,发布者跟订阅者是一对多的关系,热流可以与多个订阅者共享信息。
StateFlow
因为Flow是冷流,这与LiveData的特点完全不一样,因此Flow提供了StateFlow来实现热流。
StateFlow 是 SharedFlow 的一个比较特殊的变种,而 SharedFlow 又是 Kotlin 数据流当中比较特殊的一种类型。StateFlow 与 LiveData 是最接近的,因为:
它始终是有值的。
它的值是唯一的。
它允许被多个观察者共用 (因此是共享的数据流)。
它永远只会把最新的值重现给订阅者,这与活跃观察者的数量是无关的。
官方推荐当暴露 UI 的状态给视图时,应该使用 StateFlow。这是一种安全和高效的观察者,专门用于容纳 UI 状态。
StateFlow替换掉LiveData是简单的。我们来看看StateFlow的构造函数:
/**
*/
@Suppress(“FunctionName”)
public fun MutableStateFlow(value: T): MutableStateFlow = StateFlowImpl(value ?: NULL)
我们在ViewModel
上游中不断的发送值,View
层通过collect
函数去获取到上游发送的数据。
StateFlow
只有在值发生改变时才会返回,如果发生更新但值没有变化时,StateFlow
不会回调collect
函数,但LiveData
会进行回调。
StateIn 能够将普通的流转换为StateFlow,但转换之后还需要一些配置工作.
scope 共享开始时所在的协程作用域范围
started 控制共享的开始和结束的策略
Lazily
: 当首个订阅者出现时开始,在 scope
指定的作用域被结束时终止。
Eagerly
: 立即开始,而在 scope
指定的作用域被结束时终止。
WhileSubscribed
能够指定当前不有订阅者后,多少时间取消上游数据和能够指定多少时间后,缓存中的数据被丢失,回复称initialValue的值。
initialValue 初始值
WhileSubscribed 策略会在没有收集器的情况下取消上游数据流。通过 stateIn 运算符创建的 StateFlow 会把数据暴露给视图 (View),同时也会观察来自其他层级或者是上游应用的数据流。让这些流持续活跃可能会引起不必要的资源浪费,例如一直通过从数据库连接、硬件传感器中读取数据等等。当您的应用转而在后台运行时,您应当保持克制并中止这些协程。