【Jetpack】学穿：LiveData →

作者：coder_pig

0x1、引言

在开始这篇文章前，我就遇到了第一个关于LiveData的问题：该怎么翻译这个词呢？

活的数据？→ 有点奇怪，难不成还有死的数据？
可观察数据？→ 感觉跟Observable有点沾边了
生命周期感知数据？→ 名字也忒长了…

自己想不到，那就集思广益，尝试向群里的小伙伴发起咨询：

好像也没找到比较好的翻译 (好像越来越可刑)，索性就不翻了，哈哈哈~

LiveData 一言以蔽之

LiveData 是能感知生命周期的、可观察的、粘性的数据持有者，以数据驱动的方式更新界面。

① 感知谁的生命周期？

具有生命周期感知的组件，一般代指Activity、Fragment，但不局限此，更泛指实现了 Lifecycle.LifecycleOwner 的组件。

如：利用 Lifecycle 让 App进程拥有生命周期感知 → ProcessLifecycleOwner，具体实现解读：《自定义 LifecycleOwner》

简单点说：实现了Lifecycle那一套的组件，Activity、Fragment默认实现了，所以可以直接用，具体原理解读：《【Jetpack】学穿：Lifecycle → 生命周期 (原理篇)》

② 怎么感知生命周期？

LifecycleOwner 提供了一个 getLifecycle() 用于获取 Lifecycle实例；
你只需自定义一个观察者实现 LifecycleEventObserver 或 DefaultLifecycleObserver，调用Lifecycle实例的 addObserve() 添加观察者实例即可。
当组件生命周期发生变化，就会通知所有的观察者(回调方法)。

LiveData里，还对观察者包了一层 → LifecycleBoundObserver

图中圈住的①：当组件处于 DESTORYED 状态时，自动移除观察者，这样的好处：避免内存泄露。

图中圈住的②，点开 activeStateChanged() 方法：

当组件处于 STARTED/RESUMED 状态，才发送数据，这样的好处：避免因组件处于非活跃状态，接收LiveData事件导致的崩溃，最常见的就是Activity停止了，还执行相关回调。

③ 可观察

除了 LifecycleBoundObserver 生命周期观察者外，LiveData内部还提供了一个数据观察者 Observer

可以调用 observe() 添加数据观察者：

在 dispatchingValue() 分发事件，considerNotify() 中回调 onChanged()，完成数据更新。

④ 粘性

所谓的粘性，通俗点说：先发送数据，然后订阅，也可以收到之前发的数据。

在LiveData中的表现：新的观察者注册时，会收到注册前分发的值。多说无益，不如来个栗子实在：

// 定义变量
private val nNum = MutableLiveData(0)

override fun onCreate(savedInstanceState: Bundle?) {
    ...
    // 绑定第一个观察者
    nNum.observe(this) { Log.e("Test", "第一个观察者：${nNum.value}") }
    // 更新值
    nNum.setValue(100)

    // 延迟1000ms后执行
    mBinding.btTest.postDelayed({
        // 添加新观察者
        nNum.observe(this) { Log.e("Test", "第二个观察者：${nNum.value}") }
    },1000L)
}

运行后输出日志如下：

现象：第二个观察者刚注册，就收到分发的值。这是咋回事？

不急不急，先来探一探值分发的原理，首先，要实现粘性，得把值存起来吧！跟下构造方法：

不难看出一丝端倪：

用一个 Object 类型的 mData 存值；
用一个 int 类型的 mVersion 来标识值的版本，初始值-1，如果版本号小于最新版本号，表示当前的值要更新。

跟下更新值的方法：

新值覆盖旧值，使值的版本号自增1，值分发 (遍历所有观察者并分发)

观察者中也持有一个值的版本号，ObserverWrapper 包 Observer 带的私货：

这样设计的好处：数据始终保持最新状态。

值发生变化后遍历所有观察者，看到这里，读者可能有这样的疑问：

生命周期组件处于非活跃状态，如Activity切到后台，此时发生数据变化，然后切回前台，又是怎么更新的？

留意下面的代码：

当生命周期组件发生状态流转，就会回调onStateChanged，Activity从后台到前台自然会走这里，完成数据更新。注意：这里是单独分发给和生命周期组件绑定的观察者，不是群发！！！

总结下：值变更 + 生命周期组件状态变更都会引起值分发。

到此，好像也没定位到引起粘性的原因? 嗯，还得再跟一下：LiveData.observe() → owner.getLifecycle().addObserver(wrapper) → LifecycleRegistry.addObserver()

Lifecycle添加观察者，状态流转，调用 dispatchEvent() 方法完成事件分发：

回调了 onStateChanged() 方法，符合第二种场景 → 生命周期组件状态变更：

activeStateChanged() → dispatchingValue() → considerNotify()：

粘性的原因到此就一清二楚了，此处应有掌声！！！

怎么解决粘性问题？不急，等下讲，这里TM才开头而已，LiveData用法都还没介绍呢。

⑤ 数据驱动

简单点说：不需要主动给界面推(设置数据)，界面会被动观察数据变化。

0x2、LiveData 使用详解

老规矩，官方文档双手奉上：《LiveData 概览》，以官方文档和源码为准~

① 依赖组件

LiveData基本配着ViewModel一起用的，你实在不想依赖，可以按官方文档的来：Lifecycle

def lifecycle_version = 2.4.1

// Java项目
implementation "androidx.lifecycle:lifecycle-livedata:$lifecycle_version"

// Kotlin项目
implementation "androidx.lifecycle:lifecycle-livedata-ktx:$lifecycle_version"

咳，如果你启用了DataBinding，可以不用另外依赖，不然你会发现两个版本的livedata：

命令行键入：gradlew :app:dependencies > dependencies.txt 扫一波就知道了：

② 创建、观察、更新

创建就不用说了，LiveData是抽象类，要么继承自定义，要么用 MutableLiveData。

观察、更新在粘性那里的例子已经演示得很清楚了，就不Copy了，这里提一嘴添加观察者的两个方法：

observe() → 当生命周期组件处于STARTED和RESUMED状态下才会收到分发值。
observeForever() → 跟生命周期组件状态没关系了，都会收到分发值，要手动调 removeObserver() 移除！

还有两种改变数据的方法：

setValue() → 只能在主线程中调用；
postValue() → 既可以在主线程中调用，也可以在子线程中调用，最终调用的还是setValue()；

③ 为什么LiveData搭配ViewModel使用？

1、避免Activity、Fragment的代码臃肿，不塞ViewModel里也要做数据和组件分离；
2、将LiveData与特定的Activity、Fragment分离，配置发生更改(如旋转)导致重建，不影响LiveData。

④ LiveData扩展

就是LiveData预留了两个回调：onActive() 和 onInactive()，当生命周期组件在活跃和非活跃状态间切换时会回调。

可以怎么玩？比如写一个全局可用的倒计时器，先写倒计时相关功能：

object CountDownManager {
    private var mRemainSecond: Long = 10L
    private var mTimer: CountDownTimer? = null
    private var mListener = arrayListOf()

    // 开始倒计时
    fun startCount(remainSecond: Long? = 10L) {
        mRemainSecond = remainSecond!!
        mTimer = object: CountDownTimer(remainSecond * 1000, 1000) {
            override fun onTick(millisUntilFinished: Long) {
                mRemainSecond--
                dispatchMessage("剩余：$mRemainSecond 秒")
            }

            override fun onFinish() {
                dispatchMessage("倒计时结束")
            }
        }
        mTimer!!.start()
    }

    // 取消倒计时
    fun cancelCount() {
        if(mTimer != null) {
            mTimer!!.cancel()
            mListener.clear()
        }
    }

    // 遍历回调方法
    private fun dispatchMessage(msg: String) { mListener.forEach { it.onChange(msg) } }

    // 添加监听器
    fun setListener(listener: CountDataChangeListener) { mListener.add(listener) }

    // 移除监听器
    fun removeListener(listener: CountDataChangeListener) { mListener.remove(listener) }
}

// 回调接口
interface CountDataChangeListener{
    fun onChange(msg: String)
}

非常简单，就是初始化倒计实例，遍历回调而已，接着继承LiveData，写一个全局数据类：

class GlobalLiveData : LiveData() {
    companion object {
        private lateinit var instance: GlobalLiveData
        fun getInstance() = if (::instance.isInitialized) instance else GlobalLiveData()
    }

    private val mListener = object : CountDataChangeListener {
        override fun onChange(msg: String) {
            postValue(msg)  // 调用更新数据的方法
        }
    }

    fun startCount(remainSecond: Long? = 10L) { CountDownManager.startCount(remainSecond) }

    fun cancelCount() { CountDownManager.cancelCount() }

    // 活跃时添加监听器
    override fun onActive() {
        super.onActive()
        CountDownManager.setListener(mListener)
    }

    // 不活跃时移除监听器
    override fun onInactive() {
        super.onInactive()
        CountDownManager.removeListener(mListener)
    }
}

然后是调用处：

// 添加倒计时监听
GlobalLiveData.getInstance().observe(this) { mBinding.tvTest.text = it }
// 开始倒计时
GlobalLiveData.getInstance().startCount(30)

你只管添加观察，无需担心移除，页面 (Activity、Fragment) 不活跃时不更新页面，活跃时才更新。运行效果如下：

Tips：只是写下例子，真正用到项目还得自己改下哈，如添加/移除观察者时加锁 ~

⑤ LiveData转换

Lifecycle包提供了 Transformations 来对LiveData的数据类型进行转换，可以在数据返回给观察者前，修改LiveData中数据的具体类型。

Transformations 中有两个常用的转换方法 map() 和 swtichMap()，它们都是使用 MediatorLiveData 作为数据的中间消费者，并将转换后的数据传递给最终消费者。

Transformations.map()

先看下map()的具体实现：

流程解读：

实例化一个 MediatorLiveData 实例 result；
调用 addSource() 传入源LiveData 和新建的Observer实例；
在Observer的回调方法onChange()中，把转换函数的执行结果传入result的setValue()方法中；
最后返回result；

跟下：MediatorLiveData.addSource()：

用Source包了一层，将传入参数关林，直接跟 Source.plug()

吼，就是给源LiveData 添加了一个观察者，当它发生数据变化时更新新LiveData 的值。写个简单例子：

// 源LiveData
val mUserLiveData = MutableLiveData()
mUserLiveData.observe(this) {
    Log.e("Test", "mUserLiveData更新了：${it.javaClass.simpleName} --- $it") 
}

// 转换后的LiveData
val mUserNameLiveData = Transformations.map(mUserLiveData) { 
        user -> "${user.userName}-${user.code}" 
}
mUserNameLiveData.observe(this) {
    Log.e("Test", "mUserNameLiveData更新了：${it.javaClass.simpleName} --- $it") 
}

// 点击更新源LiveData数据
findViewById

运行后点击多次更新源LiveData数据，输出结果如下：

结论：每次源LiveData数据发生变化，转换后的LiveData数据也跟着变化。

Transformations.switchMap()

同样先看下switchMap()的具体实现：

留意传入的函数类型，它的返回值类型是 LiveData类型！！！然后在回调执行传入函数后，替换了源LiveData。怎么说？改下上面的简单例子：

val mUserNameLiveData = Transformations.switchMap(mUserLiveData) { user ->
    MutableLiveData().apply { "${user.userName}-${user.code}"  }
}

运行后点击多次更新源LiveData数据，输出结果如下：

结论：仅把源LiveData作为触发器，执行传入函数后返回新的LiveData，源LiveData数据发生变化不影响转换后的LiveData数据。

到此，map()和switchMap()的区别就一清二楚了，还有一点要注意，转换方法都发生在主线程。意味着如果在此进行耗时、太复杂的转换操作可能会堵塞主线程，可以想办法将数据转换操作异步化。如通过 CoroutineLiveData，用它得加下依赖：

implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.4.1'

包里有个 Transformations.kt，对原方法封装，定义成LiveData的扩展方法，便于链式调用：

CoroutineLiveData 中定义了liveData()这个顶层方法，用于构建 CoroutineLiveData：

具体用法示例如下：

val mUserNameLiveData = mUserLiveData.switchMap() { user ->
    liveData(Dispatchers.Default){
        // 模拟耗时操作
        delay(5000)
        emit( "${user.userName}-${user.code}"  )
    }
}

⑥ 合并多个LiveData源

场景：页面有多个数据源，单独用LiveData的话，每个都要定义一个observer，很繁琐。
解法：可以利用 MediatorLiveData 来合并多个数据源，只需定义一个observer。

写个简单示例：

运行后点击多次按钮，输出结果如下：

细心的你有没有发现 mMediatorLiveData发生数据更新这个日志没有输出？

因为它本身也是LiveData，有它自己的value，你得去修改它的值，才会触发数据更新回调~

合并数据源，非常适合存在多个关联网络请求或数据库查询的场景。

到此，关于LiveData的基本使用已经差不多了，和其它Jetpack组件的配合(ViewModel、Room等) 后续学到再讲。

0x3、LiveData 常见问题及解决 ① 解决LiveData带来的粘性问题

上面说过粘性问题 → 添加新观察者，收到之前分发的值，原因如下：

添加观察者，引起生命周期组件状态变化，进行值分发，新观察者中值的版本号为-1，所以会触发值更新。

LiveData没有像EventBus一样，区分粘性和非粘性事件，也没有提供开关，在需要非粘性的场景，就得我们自己想办法了。

网上罗列的常见解决方式有三大类，一一讲解下~

方案一：反射干涉Version (无效)

思路如下：

在observe()时，反射拿到LiveData的mVersion，然后赋值给 LifecycleBoundObserver 的 mLastVersion。

具体实现：

class NoLiveData(data: T) : MutableLiveData(data) {
    // 传入粘性标记，区分粘性和非粘性
    fun observe(owner: LifecycleOwner, observer: Observer, isSticky: Boolean) {
        super.observe(owner, observer)
        if (!isSticky) hook(observer)
    }

    private fun hook(observer: Observer) {
        // 获取mVersion
        val mVersion = javaClass.superclass.superclass.getDeclaredField("mVersion")
            .apply { isAccessible = true }
        val mVersionValue = mVersion.get(this)

        // 获取mObservers
        val mObservers = javaClass.superclass.superclass.getDeclaredField("mObservers")
            .apply { isAccessible = true }
        val mObserversValue = mObservers.get(this)

        // 获取mObservers对象所属的SafeIterableMap
        val methodGet = mObserversValue.javaClass.getDeclaredMethod("get", Any::class.java)
            .apply { isAccessible = true }

        // 获取LifecycleBoundObserver
        val objectWrapperEntry = methodGet.invoke(mObserversValue, observer)
        val objectWrapper = (objectWrapperEntry as Map.Entry<*, *>).value

        // 获取ObserverWrapper
        val mLastVersion = objectWrapper!!.javaClass.superclass.getDeclaredField("mLastVersion")
            .apply { isAccessible = true; }
        val mLastVersionValue = mLastVersion.get(objectWrapper)

        // 将 mVersion的值 赋值给 mLastVersion
        mLastVersion.set(objectWrapper, mVersionValue)
    }
}

看似可以，但实际运行还是触发了粘性，断点发现 activeStateChanged() 会优于 hook() 方法的执行，方案一GG。

方案二：引入中间层

就是定义一个类包裹原始类型，在其中定义一个消费标记，用于标识值变化是否被处理，代码示例如下：

open class OneShotValue(private val value: T) {
    // 值是否被消费
    private var handled = false
    // 获取值，如果值未被处理则返回，否则返回空
    fun getValue(): T? {
        return if (handled) {
            null
        } else {
            handled = true
            value
        }
    }
    // 获取上次被处理的值，留给手动获取用
    fun peekValue(): T = value
}

// 调用处：
private val nNum = MutableLiveData>()
nNum.observe(this) { Log.e("Test", "第一个观察者：${nNum.value!!.getValue()}") }
nNum.value = OneShotValue(100)
nNum.observe(this) { Log.e("Test", "第二个观察者：${nNum.value!!.getValue()}") }

运行结果如下：

可以看出依旧是粘性的，只是第二次拿到的值为null，执行回调代码时，记得做下判空，为空不执行具体业务逻辑。

方案三：拦截观察者回调

谷歌官方给出的一个解决方案，源码可见：SingleLiveEvent.java

class SingleLiveEvent : MutableLiveData() {
    // 标志位，用于表达值是否被消费
    private val mPending: AtomicBoolean = AtomicBoolean(false)

    @MainThread
    override fun observe(owner: LifecycleOwner, observer: Observer) {
        // 中间观察者
        super.observe(owner) { t ->
            // 只有当值未被消费过时，才通知下游观察者
            if (mPending.compareAndSet(true, false)) {
                observer.onChanged(t)
            } else {
                Log.e("Test", "其实还是粘性...")
            }
        }
    }

    @MainThread
    override fun setValue(@Nullable t: T?) {
        // 当值更新时，置标志位为 true
        mPending.set(true)
        super.setValue(t)
    }

    @MainThread
    fun call() {
        value = null
    }
}

添加了一个中间观察者，接管传入观察者回调执行的执行，添加一个mPending标记位(值会在setValue时更新)，如果消费过就不执行回调。

这种玩法可以，但存在一个问题：所有观察者共享一个mPending 会导致第一个观察者消费后，其他观察者没机会消费。举个例：依次添加了A、B、C三个观察者，当值发生改变时，三个观察者都应该执行回调，但是用了这个类，实际上只有A会执行回调。

要解决上面这个问题也不难啊，给Observer包一层，添加一个当前观察者是否消费了数据的标记，具体代码如下：

class SingleLiveEvent : MutableLiveData() {
    // 暂存中间观察者
    private val observers = ArraySet>()

    @MainThread
    override fun observe(owner: LifecycleOwner, observer: Observer) {
        // 避免重复添加
        observers.find { it.observer === observer }?.let { _ -> return}
        ObserverWrapper(observer).apply {
            observers.add(this)
            super.observe(owner, this)
        }
    }

    @MainThread
    override fun observeForever(observer: Observer) {
        // 避免重复添加
        observers.find { it.observer === observer }?.let { _ -> return}
        ObserverWrapper(observer).apply {
            observers.add(this)
            super.observeForever(this)
        }
    }

    @MainThread
    override fun removeObserver(observer: Observer) {
        if (observer is ObserverWrapper && observers.remove(observer)) {
            super.removeObserver(observer)
            return
        }
        val iterator = observers.iterator()
        while (iterator.hasNext()) {
            val wrapper = iterator.next()
            if (wrapper.observer == observer) {
                iterator.remove()
                super.removeObserver(wrapper)
                break
            }
        }
    }

    @MainThread
    override fun setValue(@Nullable t: T?) {
        // 遍历更新所有中间观察者的标记为
        observers.forEach { it.newValue() }
        super.setValue(t)
    }

    // 中间观察者
    private class ObserverWrapper(val observer: Observer) : Observer {
        // 标记当前观察者是否消费了数据
        private var pending = false

        override fun onChanged(t: T?) {
            // 保证只向下游观察者分发一次数据
            if (pending) {
                pending = false
                observer.onChanged(t)
            } else {
                Log.e("Test", "其实还是粘性...")
            }
        }

        fun newValue() {
            pending = true
        }
    }
}

运行下看看效果：

哈哈，其实还是粘性的，类似的方案还有 KunMinX大佬开源的：UnPeek-LiveData，以下是某个比较老版本的代码：

public class ProtectedUnPeekLiveData extends LiveData {

    protected boolean isAllowNullValue;

    private final HashMap observers = new HashMap<>();

    public void observeInActivity(@NonNull AppCompatActivity activity, @NonNull Observer observer) {
        LifecycleOwner owner = activity;
        Integer storeId = System.identityHashCode(observer);
        observe(storeId, owner, observer);
    }

    private void observe(@NonNull Integer storeId,
                         @NonNull LifecycleOwner owner,
                         @NonNull Observer observer) {

        if (observers.get(storeId) == null) {
            observers.put(storeId, true);
        }

        super.observe(owner, t -> {
            if (!observers.get(storeId)) {
                observers.put(storeId, true);
                if (t != null || isAllowNullValue) {
                    observer.onChanged(t);
                }
            }
        });
    }

    @Override
    protected void setValue(T value) {
        if (value != null || isAllowNullValue) {
            for (Map.Entry entry : observers.entrySet()) {
                entry.setValue(false);
            }
            super.setValue(value);
        }
    }

    protected void clear() {
        super.setValue(null);
    }
}

不难看出另外定义了一个 HashMap，原理大同小异。

方案四：不用LiveData，改用Kotlin-Flow

今年的谷歌I/O大会，Yigit 在Jetpack的AMA中明确指出Livedata的存在就是为了照顾Java的使用者，短期内会继续维护。作为Livedata的替代品Flow会在今后渐渐成为主流，用上Flow，就不存在粘性问题了。

Kotlin Flow笔者还没来得及学，后续学完再来填这里的坑哈~

② LiveData会丢失数据吗？

答：在高频数据更新的场景下使用 LiveData.postValue() 时，会造成数据丢失。因为设值和分发值是分开执行的，存在延迟。值先被缓存在变量中，再向主线程抛一个分发值的任务。在这个延迟期间，再调用一次postValue()，变量中缓存的值被更新了，会导致之前的值在未分发前就被擦除。

【Jetpack】学穿：LiveData →

Java相关栏目本月热门文章