很高兴见到你!我是《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 通过 独创的 “延时自动清理消息” 的设计,来满足:
1.消息被分发给多个观察者时,不会因第一个观察者消费了而直接被置空
2.时限到了,消息便不再会被倒灌
3.时限到了,消息自动从内存中清理释放
4.使非入侵的设计成为可能,并最终结合官方 SingleLiveEvent 的设计实现了 遵循开闭原则的非入侵重写。
并且 UnPeekLiveData 提供了构造器模式,可通过构造器组装适合自己业务场景的 UnPeekLiveData。
零入侵设计 | 延时自动清理消息 | Builder 构造器 |
---|---|---|
PS:非常感谢近期 hegaojian、Angki、Flynn、Joker_Wan 等小伙伴积极的试用和反馈,使得未被觉察的问题 被及时发现和纳入考虑。
详见:GitHub:KunMinX/UnPeekLiveData
本文以 CC 署名-非商业性使用-禁止演绎 4.0 国际协议 发行。
Copyright © 2019-present KunMinX
文中提到的 对 “数据倒灌” 一词及其现象的概括、对 Event 事件包装器、反射方式、SingleLiveEvent 各自存在的缺陷的理解,以及对 UnPeekLiveData 的 “延迟自动清理消息” 的设计,均属于本人独立原创的成果,本人对此享有最终解释权。
任何个人或组织在引用上述内容时,须注明原作者和出处。未经授权不得用于洗稿、广告包装等商业用途。