LiveData 数据倒灌：别问，问就是不可预期

前言

大家好，我是《Jetpack MVVM Best Practice》作者 KunMinX。

今天提到的 “数据倒灌” 一词，是我为了方便理解和记忆 “页面在 ‘二进宫’ 时收到旧数据推送” 的情况，而在 2019 年 自创并在网上传播的 对此类现象的概括。

它主要发生在：通过 SharedViewModel + LiveData 的组合 来解决页面通信的场景。

本文的目标

由于本文的目标主要是来介绍 官方 Demo 现有解决方案的缺陷，以及经过 1 年迭代的完美解决方案，

所以我假设在座的诸位 对最基本的背景缘由有一定的了解，知道：

为什么 LiveData 默认被设计为粘性事件

为什么 官方文档 推荐使用 SharedViewModel + LiveData（文档没明说，但事实上包含三个关键的背景缘由）

乃至为什么存在 “数据倒灌” 的现象

以及为什么在 “页面通信” 的场景下，不用静态单例、不用 LiveDataBus

如果对于这些前置知识也尚不了解，可结合个人兴趣前往《LiveData 数据倒灌 背景缘由全貌 独家解析》查阅，此处不再累述。

现有解决方案及各自缺陷

在《Jetpack MVVM 精讲》中我分别提到了 Event 事件包装器、反射方式、SingleLiveEvent 这三种方式来解决 “数据倒灌” 的问题。它们分别来自上文我们提到的外网、美团的文章，和官方最新 demo。

但正如我在《Jetpack MVVM 精讲》介绍的，它们分别存在如下问题：

Event 事件包装器：

对于多观察者的情况，只允许第一个观察者消费，这不符合现实需求；

而且手写 Event 事件包装器，在 Java 中存在 null 安全的一致性问题。

·

反射干预 Version 的方式：

存在延迟，无法用于对实时性有要求的场景；

并且数据会随着 SharedViewModel 长久滞留在内存中得不到释放。

·

官方最新 demo 中的 SingleLiveEvent：

是对 Event 事件包装器 一致性问题的改进，但未解决多观察者消费的问题；

而且额外引入了消息未能从内存中释放的问题。

UnPeekLiveData 特点

UnPeekLiveData 通过 独创的 “延时自动清理消息” 的设计，来满足：

1.消息被分发给多个观察者时，不会因第一个观察者消费了而直接被置空

2.时限到了，消息便不再会被倒灌

3.时限到了，消息自动从内存中清理释放

4.使非入侵的设计成为可能，并最终结合官方 SingleLiveEvent 的设计实现了 遵循开闭原则的非入侵重写。

并且 UnPeekLiveData 提供了构造器模式，可通过构造器组装适合自己业务场景的 UnPeekLiveData。

零入侵设计	延时自动清理消息	Builder 构造器

PS：非常感谢近期 hegaojian、Angki、Flynn、Joker_Wan 等小伙伴积极的试用和反馈，使得未被觉察的问题 被及时发现和纳入考虑。

JCenter 依赖

详见 GitHub：https://github.com/KunMinX/UnPeekLiveData

License

本文以 CC 署名-非商业性使用-禁止演绎 4.0 国际协议 发行。

Copyright © 2019-present KunMinX

文中提到的 对 “数据倒灌” 一词及其现象的概括、对 Event 事件包装器、反射方式、SingleLiveEvent 各自存在的缺陷的理解，以及对 UnPeekLiveData 的 “延迟自动清理消息” 的设计，均属于本人独立原创的成果，本人对此享有所有权和最终解释权。

当您借鉴或引用本文的引言、思路、结论进行二次创作，或全文转载时，须注明链接出处，否则我们保留追责的权利。