LiveData数据倒灌的解决方案之一

本文主要是介绍LiveData数据倒灌的解决方案之一，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

背景

我们目前的项目中已经逐步从MVP转移到MVVM（基于ViewModel、LiveData、Coroutine实现），尤其在使用到LiveData的时候，发现了它的“数据倒灌”问题比较影响我们的开发场景，虽然从设计者的角度上来说，这个问题并不算是设计缺陷，但是从我们的使用场景上来说，确实不太必要，所以我们需要想办法避免这个问题。

数据倒灌

什么是“数据倒灌”呢？意思就是说当LiveData的值已经消费之后，监听者才开始对LiveData进行监听，这时候LiveData的值就马上回调给监听者。
举个例子，GameActivity里面有两个Button和两个TextView，当点击Button1的时候，tv_value1这个TextView就会开始监听ViewModel里面的值，当点击Button2的时候，tv_value2这个TextView就会开始监听ViewModel里面的值。

<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"xmlns:app="http://schemas.android.com/apk/res-auto"xmlns:tools="http://schemas.android.com/tools"android:layout_width="match_parent"android:layout_height="match_parent"><Buttonandroid:id="@+id/btn1"android:layout_width="wrap_content"android:layout_height="wrap_content"android:layout_marginBottom="50dp"android:text="开始监听"app:layout_constraintTop_toTopOf="parent"app:layout_constraintStart_toStartOf="parent" /><TextViewandroid:id="@+id/tv_value1"android:layout_width="wrap_content"android:layout_height="wrap_content"android:textSize="10dp"app:layout_constraintStart_toStartOf="parent"app:layout_constraintTop_toBottomOf="@id/btn1"/><Viewandroid:id="@+id/view_line"android:layout_width="match_parent"android:layout_height="2dp"android:background="#111111"app:layout_constraintBottom_toBottomOf="parent"app:layout_constraintTop_toTopOf="parent" /><Buttonandroid:id="@+id/btn2"android:layout_width="wrap_content"android:layout_height="wrap_content"android:layout_marginBottom="50dp"android:text="开始监听"app:layout_constraintTop_toBottomOf="@id/view_line"app:layout_constraintStart_toStartOf="parent" /><TextViewandroid:id="@+id/tv_value2"android:layout_width="wrap_content"android:layout_height="wrap_content"android:textSize="10dp"app:layout_constraintStart_toStartOf="parent"app:layout_constraintTop_toBottomOf="@id/btn2"/></androidx.constraintlayout.widget.ConstraintLayout>

Activity对应代码如下：

class GameActivity : AppCompatActivity() {private lateinit var gameBinding: ActivityGameBindingprivate lateinit var gameVM: GameViewModeloverride 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<String> = 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.ryanimport android.os.Handler
import android.os.Looper
import androidx.lifecycle.LifecycleOwner
import androidx.lifecycle.MediatorLiveData
import androidx.lifecycle.Observerabstract class PublishData<T> {private val source = MediatorLiveData<EventWrapper<T>>()protected open fun publish(event: T) = runOnUI {val eventWrapper = EventWrapper(event)source.value = eventWrappereventWrapper.hasBeenHandled = true}@Deprecated("typo fix", ReplaceWith("observe(lifecycleOwner, observer)"))fun observer(lifecycleOwner: LifecycleOwner, observer: Observer<T>) {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<T>) {val mediator = createUnwrapMediator()mediator.observe(lifecycleOwner, observer)}fun observe(lifecycleOwner: LifecycleOwner, observer: (T) -> Unit) {return observe(lifecycleOwner, Observer { observer(it) })}fun observeDisposable(observer: Observer<T>) {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<T> {val mediator = MediatorLiveData<T>()mediator.addSource(source) { event ->if (!event.hasBeenHandled) {mediator.value = event.peekContent()}}return mediator}
}class MutablePublishData<T> : PublishData<T>() {public override fun publish(event: T) {super.publish(event)}
}// ===========================扩展代码==============================open class EventWrapper<out T>(private val content: T) {var hasBeenHandled = falseinternal 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<T>(private val onEventUnhandledContent: (T) -> Boolean) :Observer<EventWrapper<T>> {override fun onChanged(event: EventWrapper<T>?) {event?.getContentIfNotHandled()?.let {event.hasBeenHandled = onEventUnhandledContent(it)}}
}class SmartObserver<T>(private var ignoreCreationChanged: Boolean = true,private val action: (it: T) -> Unit
) : Observer<T> {override fun onChanged(t: T) {if (ignoreCreationChanged) {ignoreCreationChanged = falsereturn}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开始监听时，已经拿不到旧值，只等到下一次值改变时才拿到最新的值，符合我们的预期。