各位有遇到过 LiveData 在共享 ViewModel 中发生旧数据倒灌的情况吗？

[KunMinX]

当我在 作用域 为 Activity 的 共享 ViewModel 中设置了一个 LiveData，

FragmentA observe 这个 LiveData，那么在收到一次通知、并关闭 FragmentA 后，再进入 FragmentA，

由于 该 ViewModel 是共享的，其中的 LiveData 并没有随着 FragmentA 的退出而清除，那么再次进入后，会自动走一遍 observe 回调，倒灌旧数据。

我知道这么设计的缘由是为了处理生命周期从 unActive 到 active 转变时，跟进“最新” 的状态，但在共享 ViewModel 中，这算不算是一个 bug ？因为 LiveData 封装死了，我似乎没有其他办法来干预这种现象的发生。

看看万能的 V 友有没什么好招

[KunMinX]

@KunMinX
笔误，应该说，要是先 set Null 了，那么其他已观察的页面 就有被迫接受一次推送 null 的风险了。（因为毕竟是 一对多的推送、共享的 ViewModel 和 liveData 的情况）

数十个页面，人工操作一定会存在疏忽、需要各种判空，所以这样其实从快速开发的角度来看，埋下的隐患要大一点。

[KunMinX]

@KunMinX
唉，感觉这个答案还可以更恰当一点：observe 前 set null 一次，容易造成 其他页面 遭受容易被使用者疏忽的 被迫推送，而产生不可预期的错误。

感谢 @mxalbert1996 提出的观点，让我不断地反思 设计成 反射方式 其背后的考虑。

[GLee9507]

@maninfog 我表达了一下我的主观想法，我只是主观的认为楼主理解有误，或许楼主可以另辟蹊径分析问题发生的原因。造成大家不爽深感抱歉。

[janus77]

问个沾边的问题，livedata 能用做 application 全局缓存么？

[DioV]

“在消息通信时则是个麻烦，所以我说这是个 bug，务必解决。”
因为 LiveData 就不是为了解决通讯而存在的，哪里谈得上 bug...
举个不恰当的例子，就像用 Retrofit 做 gRPC 的请求，能实现但绝对不是最合适的方式。

[KunMinX]

@DioV 断章取义烦不烦... MVVM 是一个整体，既然 ViewModel 被设计为支持共享作用域，那么 LiveData 就应考虑到这种跨页面通信的情况，这是官方文档自己都承认的需求。现在我就给 Google 小组留言这个问题。

[KunMinX]

楼上 @colaman 同学提到的包装类的办法，经调查，如果是我这样依然托管给 ViewModel 从而维持 唯一可信源状态分发 的话，那包装类的方式其实更合适。

如果是用作纯粹的 BUS，那可以考虑反射的方式。

这里分享一篇包装类处理的办法：

https://juejin.im/post/5b2b1b2cf265da5952314b63

[DioV]

@KunMinX
戾气真重...
如果你理解下的 MVVM 必须提供这样的功能。那我是不是可以理解 Jetpack Compose 作为一套 Declarative Toolkit 而不必实现这样的需求？
当然我希望你的 Feature Request 能被官方接受。毕竟我也只是个想说说自己看法的围观群众🤷‍♂️

[KunMinX]

@DioV

统一回复一下：

我对自己的每一条评论负责。

通过讨论，我不仅要解决自己的问题，也要考虑到对后来者有无帮助。

在和就事论事的 V 友的讨论中，对 LiveData 粘性问题的解决方案得以不断刷新，因而这次讨论算是成功的，有价值的。

对于 LiveData 的状况，我在 12 楼给出了多达 500 字的翔实的分析，依然还有人只顾自己爽，来不及阅读理解，就急忙发表一些断章取义的抬杠，事后又以各种理由推卸责任。🤷‍♂️

[KunMinX]

对我在 13 楼对 8 楼 v 友 @GLee9507 的过度反应表示抱歉。

现如今，我对 LiveData + ViewModel 的观点，与该帖最终讨论的结果一脉相承，

但如果要说有什么巨大转变的话，我想那就是 我不再要求别人应该应该怎样，正如我不再理会别人的要求。很高兴和 @GLee9507 共享了这一人生智慧 😉