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

背景

我们目前的项目中已经逐步从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数据倒灌的解决方案之一_第1张图片

解决方案

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开始监听时,已经拿不到旧值,只等到下一次值改变时才拿到最新的值,符合我们的预期。

LiveData数据倒灌的解决方案之一_第2张图片

字节跳动Tiktok直播团队(海外直播)持续招聘中,目前客户端、后端、Web、算法都有大量HC,需要内推欢迎发送邮件到[email protected][email protected]

你可能感兴趣的:(#,5.Android学习探索,livedata,数据倒灌,mvvm,android)