我们目前的项目中已经逐步从MVP转移到MVVM(基于ViewModel、LiveData、Coroutine实现),尤其在使用到LiveData的时候,发现了它的“数据倒灌”问题比较影响我们的开发场景,虽然从设计者的角度上来说,这个问题并不算是设计缺陷,但是从我们的使用场景上来说,确实不太必要,所以我们需要想办法避免这个问题。
什么是“数据倒灌”呢?意思就是说当LiveData的值已经消费之后,监听者才开始对LiveData进行监听, 这时候LiveData的值就马上回调给监听者。
举个例子,GameActivity里面有两个Button和两个TextView,当点击Button1的时候,tv_value1这个TextView就会开始监听ViewModel里面的值,当点击Button2的时候,tv_value2这个TextView就会开始监听ViewModel里面的值。
Activity对应代码如下:
class GameActivity : AppCompatActivity() {
private lateinit var gameBinding: ActivityGameBinding
private lateinit var gameVM: GameViewModel
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
gameBinding = ActivityGameBinding.inflate(layoutInflater)
setContentView(gameBinding.root)
gameVM = ViewModelProvider(this).get(GameViewModel::class.java)
gameBinding.btn1.setOnClickListener {
val builder1 = StringBuilder()
builder1.append("${getCurTime()}, textview1开始监听...\n")
gameVM.status.observe(this, Observer {
builder1.append("${getCurTime()}, value值改变为: $it\n")
gameBinding.tvValue1.text = builder1.toString()
})
gameVM.start()
}
gameBinding.btn2.setOnClickListener {
val builder2 = StringBuilder()
builder2.append("${getCurTime()}, textview2开始监听...\n")
gameVM.status.observe(this, Observer {
builder2.append("${getCurTime()}, value值改变为: $it\n")
gameBinding.tvValue2.text = builder2.toString()
})
}
}
private fun getCurTime(): String {
val formatter = SimpleDateFormat("HH:mm:ss")
val curDate = Date(System.currentTimeMillis())
return formatter.format(curDate)
}
}
ViewModel里面只有一个status的LiveData,每隔10s钟value的值会自增1,代码如下:
class GameViewModel : ViewModel() {
var status: MutableLiveData = MutableLiveData()
fun start() {
viewModelScope.launch {
repeat(1000) {
status.value = "当前值为$it"
delay(10 * 1000)
}
}
}
}
我们开始实验,17:53:19点解了Button1,GameViewModel的status开始每隔10s自增一次,当status变化的时候,tv_value1的内容就会变化,可以看到在17:53:29的时候,status变成了1,再过3s钟,即17:53:32的时候,Button2被点击,GameViewModel的status再次被监听,但是status的旧值2就会马上返回给监听者,对于大部分场景来说,监听者只需要拿到开始监听后才变化的值,而不是监听前就已经变化的值,这种问题就是我们成为的“数据倒灌”。
LiveData存在的这个问题对于Google官方的设计者来说并不算是一个缺陷,只是对于使用者来说这种功能不太“好”,其原因就是当LiveData每次改变时,即调用setValue时,LiveData对应当version就会从-1自增,但是新监听LiveData的Observer对应的version就会从-1开始,调用observe时内部会判断监听者的version是否小于LiveData的version,很明显当LiveData前面已经修改过之后,其version>-1,监听者的version为-1,这个判断条件判断成立,就会马上把LiveData的值返回给监听者,有兴趣可以看看这篇文章《踩坑之路:LiveData之粘性事件》。
网上提供了一些可用的方案,但是大部分都是对原代码侵入性较强,当后续LiveData进行版本迭代的时候容易造成兼容问题,这里提供一种侵入性较弱的方案,目前也在我们百万级日活的App上稳定使用的方案,其原理是使用MediatorLiveData来保存原始数据,当监听者监听时,创建一个新的MediatorLiveData监听原始的MediatorLiveData,当MediatorLiveData修改时,就会回调给监听者创建的MediatorLiveData,为什么这样不会造成“数据倒灌”呢?因为在修改数据的时候会标记它已经被处理,当监听的时候就判断是否被处理,如果已经被处理就不会返回给监听者,这样就避免了数据倒灌的问题,代码如下。
package com.ryan
import android.os.Handler
import android.os.Looper
import androidx.lifecycle.LifecycleOwner
import androidx.lifecycle.MediatorLiveData
import androidx.lifecycle.Observer
abstract class PublishData {
private val source = MediatorLiveData>()
protected open fun publish(event: T) = runOnUI {
val eventWrapper = EventWrapper(event)
source.value = eventWrapper
eventWrapper.hasBeenHandled = true
}
@Deprecated("typo fix", ReplaceWith("observe(lifecycleOwner, observer)"))
fun observer(lifecycleOwner: LifecycleOwner, observer: Observer) {
observe(lifecycleOwner, observer)
}
@Deprecated("typo fix", ReplaceWith("observe(lifecycleOwner, observer)"))
fun observer(lifecycleOwner: LifecycleOwner, observer: (T) -> Unit) {
observe(lifecycleOwner, observer)
}
fun observe(lifecycleOwner: LifecycleOwner, observer: Observer) {
val mediator = createUnwrapMediator()
mediator.observe(lifecycleOwner, observer)
}
fun observe(lifecycleOwner: LifecycleOwner, observer: (T) -> Unit) {
return observe(lifecycleOwner, Observer { observer(it) })
}
fun observeDisposable(observer: Observer) {
val mediator = createUnwrapMediator()
mediator.observeForever(observer)
}
fun observeDisposable(observer: (T) -> Unit) {
return observeDisposable(Observer { observer(it) })
}
/**
* 获取上一次事件缓存值,可能为空
*/
fun peekEvent(): T? {
return source.value?.peekContent()
}
/**
* 新建一个中间层. 用来筛掉那些已经被处理过的事件. 其实相当于注册一个 forever 的 observer
*/
private fun createUnwrapMediator(): MediatorLiveData {
val mediator = MediatorLiveData()
mediator.addSource(source) { event ->
if (!event.hasBeenHandled) {
mediator.value = event.peekContent()
}
}
return mediator
}
}
class MutablePublishData : PublishData() {
public override fun publish(event: T) {
super.publish(event)
}
}
// ===========================扩展代码==============================
open class EventWrapper(private val content: T) {
var hasBeenHandled = false
internal set // Allow external read but not write
/**
* Returns the content and prevents its use again.
*/
fun getContentIfNotHandled(): T? {
return if (hasBeenHandled) {
null
} else {
content
}
}
/**
* Returns the content, even if it's already been handled.
*/
fun peekContent(): T = content
}
/**
* An [Observer] for [Event]s, simplifying the pattern of checking if the [Event]'s content has
* already been handled.
*
* [onEventUnhandledContent] is *only* called if the [Event]'s contents has not been handled.
*/
class EventObserver(private val onEventUnhandledContent: (T) -> Boolean) :
Observer> {
override fun onChanged(event: EventWrapper?) {
event?.getContentIfNotHandled()?.let {
event.hasBeenHandled = onEventUnhandledContent(it)
}
}
}
class SmartObserver(
private var ignoreCreationChanged: Boolean = true,
private val action: (it: T) -> Unit
) : Observer {
override fun onChanged(t: T) {
if (ignoreCreationChanged) {
ignoreCreationChanged = false
return
}
action(t)
}
}
val uiHandler by lazy {
Handler(Looper.getMainLooper())
}
fun runOnUI(action: () -> Unit) {
if (Looper.getMainLooper() == Looper.myLooper()) {
action.invoke()
} else {
uiHandler.post(action)
}
}
fun runOnUIDelay(delay: Long, action: () -> Unit) {
uiHandler.postDelayed(action, delay)
}
fun removeCallbacks(runnable: Runnable) {
uiHandler.removeCallbacks(runnable)
}
使用了PublishData之后运行程序,可以看到运行结果如下图,当22:09:39开始监听时,已经拿不到旧值,只等到下一次值改变时才拿到最新的值,符合我们的预期。
字节跳动Tiktok直播团队(海外直播)持续招聘中,目前客户端、后端、Web、算法都有大量HC,需要内推欢迎发送邮件到[email protected]或[email protected]。