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

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

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

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

@colaman

是的。类似的令人头疼的问题也存在于 Navigation。

Navigation 写死了切换 fragment 必须是通过 replace，而不能使用者自己选择，所以当前对于 Navigation 态度，也是保持欣赏但观望的态度（对它的声明式编程理念比较欣赏）。

网上有给出 keep-fragment-state-Navigation 的解法，这里顺带分享一下：

https://github.com/STAR-ZERO/navigation-keep-fragment-sample

https://github.com/lwj1994/navigation-keep-state-fragment

@mxalbert1996

反射的方式影响最小。因为目标只是 为了解决 不自动倒灌 旧数据，要是先 set Null 了，那么其他已观察的页面再想要取 liveData 临时存的数据，就莫得治了

当然，上面我说到了 “ViewModel” 包含共享的考虑，肯定会有杠精不放过一丝添堵的机会。

首先，遇到像 8 楼这种纯粹来恶心人、不就事论事 的评论，我第一个就选择 block，

其次，我可以分享一下自己在项目中是怎么使用 ViewModel 的：

因为 ViewModel 的本职主要是状态的托管，可以托管 DataBinding 或 视图控制器 所依赖的 state，
也即这种 ViewModel 是 fragment 独享的，我会为每个 Fragment 都配一个，反正我有自己编写的自动化脚本工具，配几个 state 字段就能生成对应的 ViewModel。

第二种就是专门用于数据请求，这些我也设计成让他们被 fragment 独占。因为 ViewModel 就是设计为，你传入什么 owner，这个 ViewModel 就是被哪个 owner 所持有。而且反正就算独占，fragment 重建时这个 ViewModel 被 retain 保留了因而可以支持视图状态的恢复。

第三种就是本帖提到的这种消息通信的用法。

我就说这么多了。

我很后悔开了这个贴。

除了 6 楼的 @sanousun 同学给出了建设性的答复，其他人始终慢了好几拍。

我已经把状况讲得这么清楚了。

为避免这些离题的回复 给后来者造成困扰，这里统一回复一下：

任何技术绝非凭空存在，既然存在了，就有存在的缘由。

ViewModel 被如此设计，当初就是有考虑过 使其作为跨页面共享的存在。

当 lifeCyclerOwner 传入的是 fragment 的宿主 Activity，那么这个 ViewModel 就是被该 Activity 所持有、可以被旗下 Fragments 所共享。

共享 ViewModel 的作用多是为了跨页面的通信，例如回调、实时通信等等。

LiveData 的存在是为了确立 通过唯一可信源分发状态 的开发模式，以避免旧时候滥用 EventBus 导致的 难以追溯、数据过时 等问题。
同时在 ViewModel 或单例的配合下，它使单向依赖成为了可能。
再者它也可以规避一些生命周期问题。

这也就是为什么我选择标准化的 Jetpack MVVM 架构来完成状态管理。

除了状态管理，MVVM 同样有这个条件，甚至是更好的条件，来支持消息推送。这也就是为什么我要用 LiveData 来实现跨页面通信，而拒绝使用 EventBus。

而既然考虑到 共享 ViewModel，那么 LiveData 也理应考虑到应解除对默认 粘性设计的支持。

这个粘性设计或许在 视图控制器 重建 恢复状态时有用，在消息通信时则是个麻烦，所以我说这是个 bug，务必解决。

@zouyun147 @KyonLi

哭了，米家的 一档 64 分贝、二挡 84 分贝。网购耽误事，实在不行，改天我要到商场看看了

@HangoX

就用 bus-LiveData 的方案了。

不手动编写的原因，楼上我已经讲过。

不直接用 LiveDataBus 的原因是，需要维持 通过 唯一可信源 分发状态的 开发模式，来避免不可预期、难以追溯和排查的错误。

好消息，找到解决方案了。

通过反射，阻止用户回调的 liveData 第一次创建时的推送。这个推送实在太坑了。

http://www.pianshen.com/article/4994394892/

@bkmi @zyqf

使用共享作用域，是为了能够跨页面通信，只不过第一次使用了，第二次它自动就回调了，不符合我预期。

手动 postValue，容易因人工操作的疏忽而造成一致性问题，因为项目有数十个 Fragment，这种事情务必在后台自动完成。

我刚刚找到的线索是，每次进入 fragment，livedata 的 observe.lastVersion 都被赋值为 -1，而 version 仍然是 0，那我觉得 bug 可能就在这里

DeepLink

@dunn @echo314
谢谢，刚刚下单了米家的双叶风扇，

@KyonLi
厉害，看来是把 CPU 的风扇外置了。

忽视，说白了就是有能力处理关系，却集中注意到工作上吧。

其实人们更普遍的问题在于能力不足、知识的欠缺。

处理不来的事情就不能勉强，勉强也是徒劳无功。

不是谁都能游刃有余地应对各种人事物。

计算机比生物要确定得多了。计算机是人造物，一切缘由皆可寻，生物是超于人类之外的某种智慧设计的，出了问题哪里问去？关于生物学的很多知识，本世纪内都未必能发觉和解释，再加上 up 主不是会 c++么，所以 up 主自己决定吧。

@crayygy 好的 谢谢推荐

@KunMinX 嗯，对于工厂模式，只能说有点类似，
因为工厂模式尚且需要手动管理，DI 框架不需要，
DI 框架类似于声明式编程，让真正的代码在编译时生成。所以使用起来更灵活，不用修改工厂。

@troywinter @momocraft @crayygy

谢谢，我大概理解了，DI 框架就是为了解决传统依赖注入办法导致的入参一致性问题，当参数变化时，不得不去所有依赖它的类中全改了。

而且顺带解决了多层依赖的关系。
比如
A a = new A()
B b = new B()
C c = new C(a,b)
的情况，有了 DI 框架，直接
C c = C.xxx 即可，有点类似于工厂模式，通过封装解决一致性问题，具体我再看看

我唯一能想到的是，保证构造入参的一致性，此外还有别的价值吗？

你要轻便的话，那肯定是选择 LG gram 了，世界最轻。

如果这样说还是不理解的话，详见

https://xiaozhuanlan.com/topic/7812045693

https://xiaozhuanlan.com/topic/2869301475

文中通过介绍 路由跳转 组件的 存在缘由、职责边界，就算不是 Android 开发，也能迅速掌握状况。