mvvm 记录

1 Lifecycle

.Lifecycle 的存在，主要是为了解决 生命周期管理 的一致性问题

2 livedata

.在 Lifecycle 的帮助下，实现生命周期管理的一致性，以及作用域的可控 
.通过 “唯一可信源” 完成状态分发，可信源、以 “生命周期安全” 的方式去给订阅者页面分发数据
.无需手动解注册，这规避了 “生命周期安全的一致性问题

.唯一可信源，意味着，无论是 哪个页面发起的 对改变状态的请求，最终 所有页面的状态 的改变，都来自一个确定的、唯一的事件源
.保证数据稳定性高 不做别的事 ，调第三方仓库数据

粘性事件-数据倒灌问题描述：
1 初衷是解决设备横竖屏切换，界面销毁重建，但activity生命周期并未结束，旋转后新建的界面需要重新填入数据
所以livedata会再次推送数据进行更新
2 源码的ObserverWrapper的mLastVersion和LiveData的mVersion不同步的问题导致
3 livedata基于viewmodel，所以之前有过setvalue后++mversion，而ObserverWrapper每次都是新的包装，
  mLastVersion每次就都是-1
解决方案：
1 有反射改变mVersion值：
  重写observe，获取mVersion值给mLastVersion 非androidx版本 https://github.com/JeremyLiao/LiveEventBus/blob/master/live-event-bus/liveeventbus/src/main/java/android/arch/lifecycle/ExternalLiveData.java
3 参考 https://xiaozhuanlan.com/topic/6719328450 

3 viewmodel

.ViewModel 的存在，主要是为了解决 状态管理 和 页面通信 的问题
.ViewModel本质上就是管理各种LiveData数据源的
.作为中间层 对状态管理所尽的“承上启下”的职责

• State-ViewModel 

  为每个页面都单独配备一个 State-ViewModel，职责仅限于状态托管和恢复，也即 State-ViewModel 中 主要包含 ObservableField、LiveData、Request 以及它们的初始化操作，除此之外不包含任何逻辑。

  1.透过状态管理的分治 来减少页面重建时不必要的资源开销 2.透过工厂模式 实现状态作用域的可控 3.配合 LiveData 实现单向依赖，以规避内存泄漏的风险

• Callback-ViewModel 

  作为充当数据分发唯一可信源，用于“数据请求”、“页面通信” 等场景， 提供给外部特定函数达到“读写分离” 来实现状态的跨页面同步更新。 对外部提供LiveData类型，外部即可只能只读getValue()

5 ViewModel总结

.Callback-ViewModel 值得注意的是，“读写分离” 仅用于 “唯一可信源”；
.对于 State-ViewModel 持有的 LiveData，由于其仅用于 “数据绑定” 的用途、
 在不适合防抖加持的场景下替代"自带防抖特性的 ObservableField"，因而这种场景下的 LiveData
 可以直接在页面内 setValue —— 所通知的目标不包含其他页面的状态，仅针对当前页内部的状态。

4 databinding

.DataBinding 的存在，主要是为了解决 视图调用 的一致性问题。
.规避了视图调用的 一致性问题 —— 无需手工判空。
.规避了视图调用的 一致性问题，乃至无需手动调用视图，从而完全不用编写 findViewById。
.就算要调用视图，也不用 findViewById，而是直接通过 binding 来引用。
.先前的 UI 逻辑基本不用改动，改的只是作为末端的状态改变的方式。
.数据驱动UI

4 switchMap :从一个数据源变成另外一个LiveData对象 map :从一个数据源变成另外一个数据源

持续记录中……

总结自 https://xiaozhuanlan.com/kunminx