前言
最近闲着做App的国际版，顺手把项目改成了MVVM+Jetpack+kotlin。为啥这样改呢？以后按住原生开发的架构模式MVVM + JetPack全家桶 + Kotlin = “Google标准化开发模式”，也就是传说的中标准状态管理框架
大部分开发中的坑，都让官方这个jetpack给解决了。
举例描述，把最为写到前面
-
activity把布局xml整成databinding的布局，在布局中写个data，有数据关联的variable1，值我们就是就叫requestModelA，有逻辑处理的variable2,值就叫ClickProxyB。分别和控件相互关联
-
activity中处理逻辑的内部类和界面中的ClickProxyB绑定，那么点击啥的逻辑处理就在这处理了
-
activity中新建一个requestModelA肤质给xml中requestModelA。然后监听自己有没有变化。有变化就会做一些事情，如果直接绑定了ui控件，控件就会自己变。
-
比如按钮A点击事件给了CLickProxyB处理，然后通过requestModelA请求，带着requestModelA.name去请求，后端或者数据库塞给了requestModelA.musicname为”海阔天空“。那么requestModelA.musicname绑定的那个textview就变成了10，就不用接口回调，太美妙了.如果还监听了requestModelA.musicname,那么还可以在监听的内容里做些弹窗
-
假设这个viewmodel的生命周期是整个App，那么当有100个界面都和这个控件绑定， 那么这100个界面就都改了，真的太好用了。
1、Lifeccycle
既然提到状态管理，Lifecycle不得不说。主要作用是生命周期管理，保持一致性
- 1.1、解决了一致性问题。
- 人类写错的东西无法避免，比如某地图api。要在onStart onPause中写对应的方法，那么我100个界面就要写100个难免会出错，其实我只要抽离在统一生命周期里做即可。
- 1.2、解决了业务逻辑代码入侵问题
- 1.3、降低耦合，不需要依赖到某个具体的Activity
2、LiveData
状态的变化，以前我们是用接口回调来完成的，比如mvp，就有恐怖的接口地狱。或者说EventBus，这种属于状态的分发（场景：网络请求回调，跨页面通信的情况）
- liveData（被lifecycle劫持住）和生命周期绑定的状态分发，可做到可见才分发
- setValue触发改变，数据observe()观察触发改变，一个触发，多个改变
- 解决了男追溯、难排查、不可预期的问题，可追溯性很强
- 有个粘性数据问题，liveDataBus
- 如果先触发setValue 后observer就用粘性
- 如果没有上述要求，最好剔除，剔除的方法是通过反射修改版本号
3、Viewmodel（小弟ObservalField,LiveData(慢慢被Flow所取代)）
解决状态管理和页面通信（共享ViewModel）的问题
- Activity被重建（横竖屏切换）八平村在VM里的数据，保存字段的数据的稳定性
- SharedViewModel 共享
- 生命周期哼唱，覆盖了宿主的所有环境
- 解耦，分担了Acititiy/Fragment责任，（ui model）-》VM
4、DataBinding
试图解决一致性的问题@BindingAdapter，将数据处理的逻辑的方法抽离出来，有个误区要注意，不要下面这样写
<TextView 前面讲的DataBinding黑锅事件
android:text="{逻辑，逻辑，逻辑逻辑逻辑逻辑逻辑逻辑逻辑逻辑逻辑}
- 可以完成双向绑定，但是比较耗费性能，不用的时候不要打开
- code全都是在编译期完成的，APT生成代码 。（layout 2 tag ），DataBinding还是会耗费性能的
- 如果编译不通过，BindingImplxxx，布局写错误
- 如果用不到单向绑定，双向绑定，尽量用ViewBinding
- ViewBinding轻量级的 as 3.6 出来的 DataBinding重量级的 编译很慢，耗费性能的问题
5、Navigation
一般情况下，一个Activity多个Fragment基本上会用Navigation 全部大部分都是Activity，则不建议用
图例
- Jetpack组件库的ViewModel()，只是一个组件库而已，和MVVM的VM层没有直接关系。
