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

很高兴见到你！我是《 Jetpack MVVM Best Practice 》作者 KunMinX 。

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

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

关于为什么会存在这个现象、为什么要使用 SharedViewModel + LiveData 等问题，可详见《 LiveData 数据倒灌》篇对背景缘由的解析。

现有解决方案及各自缺陷

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

任何个人或组织在引用上述内容时，须注明原作者和出处。未经授权不得用于洗稿、广告包装等商业用途。