V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
KunMinX
V2EX  ›  Android

LiveData 数据倒灌:别问,问就是不可预期

  •  
  •   KunMinX · 2020-07-15 13:54:12 +08:00 · 5142 次点击
    这是一个创建于 1372 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

    关于 为什么会存在这个现象、为什么要使用 SharedViewModel + LiveData 等问题,可详见《 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 。

    License

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

    Copyright © 2019-present KunMinX

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

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

    GitHub

    https://github.com/KunMinX/UnPeekLiveData

    9 条回复    2020-10-08 00:39:03 +08:00
    xcstream
        1
    xcstream  
       2020-07-15 13:57:35 +08:00
    所以这是干什么用的
    momocraft
        2
    momocraft  
       2020-07-15 14:22:46 +08:00
    @xcstream

    不懂 android 简单读了一下
    文章描述了一种当 VM 生命周期长于 fragment 时,第二个 fragment 订阅同一个 VM 后立刻收到前一个 fragment 订阅的结果的现象(这个 "粘性事件" 行为和 rx 的 ReplaySubject 相似)

    至于为什么设计上 VM 和 view 生命周期会不匹配,为什么只有 ReplaySubject 这种行为可选,为什么需要新造一个概念及其方案来解决,就不知道了

    我没真的用过 LiveData 写东西,如果这么复杂才能把事情做对,我宁愿换个设计或改用 rx
    winterbells
        3
    winterbells  
       2020-07-15 14:47:49 +08:00 via Android   ❤️ 1
    @momocraft 这个粘性事件,Google 单独写了个去掉这个特性的 live data,但只发在了 sample 里,并没有打包进 jar 。。
    zjsxwc
        4
    zjsxwc  
       2020-07-15 15:01:01 +08:00
    楼主怎么天天发帖刷版,和那个蓝人一个套路

    bkmi
        5
    bkmi  
       2020-07-15 18:01:35 +08:00 via Android
    @winterbells 我估计你说的是 SingleLiveEvent ,楼主提到了,但是他并不能解决所有的黏性问题,他实质上是限制了一个事件只能消费一次,连个半成品都算不上,也不能合入正式库。
    楼主的的延时方案在我看来也不可靠,虽然大部分情况下会好使,低端一些的机器在主线程卡个一两秒的情况太常见了
    bkmi
        6
    bkmi  
       2020-07-15 18:09:03 +08:00 via Android   ❤️ 1
    @momocraft 一方面是因为 Google 的 "高傲",要说动他去改很困难,另一方面是动作太慢,毕竟让 LiveData 支持初始值都花了好多年
    KunMinX
        7
    KunMinX  
    OP
       2020-07-15 18:31:48 +08:00
    @bkmi
    清理不是必需的,不清理也可避免数据倒灌,延迟时间也是可以设置的,这些都可以在 Builder 中自行配置,正文已提到,不再累述。
    KunMinX
        8
    KunMinX  
    OP
       2020-10-07 22:19:39 +08:00
    @momocraft

    任何技术方案绝非凭空存在,在对背景事实一无所知的情况下,构不成有效的推理和交流。

    就事论事、实事求是,是最基本的认知原则。

    后续若是再像上次那样,违背原则地针对我个人说些让人大跌眼镜的话,我从此就当没看见。
    momocraft
        9
    momocraft  
       2020-10-08 00:39:03 +08:00
    还专门找我回过的帖警告我? 至于吗

    不用这么麻烦的, 我不介意少一个你这样的..强者..看到我
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3206 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 00:35 · PVG 08:35 · LAX 17:35 · JFK 20:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.