在介绍MVVM（Model View viewModel）之前，先简单的介绍一下MVC(Model View Controller)和MVP（Model View presenter）。如果这方便比较了解，可以忽略此部分，直接阅读MVVM相关的内容。
一、MVC简介
对于MVC我们是比较熟悉，对于原生的Android项目来说，layout.xml里面的xml文件就对应于MVC的view层，里面都是一些view的布局代码，而各种Java bean，还有一些类似repository类就对应于model层，至于controller层，就是各种activity。
调用关系：
- 用户对于V操作后，V捕捉到这个操作后，把逻辑的处理权交给C
- C接收后执行响应的后台业务逻辑，这些业务逻辑可能会影响M
- 当M中数据改变后通过观察者模式通知view
- 当M中数据改变后通过观察者模式通知view
注意点：
- V和M通过观察者模式操作，而同步操作是V主动向M请求数据（凡是在M中设置接收的V都会收到数据的变更请求）
- 逻辑C的测试困难：V的操作是由自己完成的，对于C的改变无法实时显示
- V依赖特定的M，复用性比较差
二、MVP的简介
MVP作为MVC的演化，解决了MVC不少的缺点，对于Android来说，MVP的model层相对于MVC是一样的，而activity和fragment不再是controller层，而是纯粹的view层，所有关于用户事件的转发全部交由presenter层处理。
调用关系：
- 用户对于V操作后，V捕捉到这个操作后，把逻辑的处理权交给P
- P接收后执行响应的后台业务逻辑，这些业务逻辑可能会影响M
- 当M中数据改变后通过观察者模式通知P(注意：不是V)
- P收到观察者模式的数据变化后，通过V提供的接口，更新界面
注意点：
- V不再负责同步逻辑交给P完成（业务逻辑和同步逻辑）
- P和V解耦：通过drgger2（编译时注解）实现V和P的解耦
-逻辑的操作基本由P完成造成P的代码臃肿
三、MVVM详解
它和MVP的区别貌似不大，只不过是presenter层换成了viewmodel层，还有一点就是view层和viewmodel层是相互绑定的关系，这意味着当你更新viewmodel层的数据的时候，view层会相应的变动ui。
调用关系：
- 前面的调用关系与MVP模式相同
- 在VM中有一个Bindler：负责数据同步之间的操纵：
只需要在View的模版语法当中，指令式地声明View上的显示的内容是和Model的哪一块数据绑定
当ViewModel对进行Model更新的时候，Binder会自动把数据更新到View上
注意点：
- V和M实现了自动化
- V和M之间通过观察者模式操纵，而同步操作是由V主动向M请求数据的（然后更新对自己界面）
特别说明：对于这一点的好处就是当M中的数据改变后，凡是在M中设置接收的V都会收到数据的变更请求，保持了同一个M不同的V显示的效果 - 过于简单的图形不适合