Android MVVM架构模式（一）

MVC架构模式

Android MVVM架构模式（一）

1 View XML界面
2 Model 数据库，网络的操作
3 Controller Activity 处理业务逻辑

流程：
圈1 用户操作，传送指令到Controller
圈2 Controller完成逻辑处理，对Model的数据进行修改
圈3 model将修改了的数据再传给View
圈4 也可以直接命令Controller

缺点：这样当Activity有较复杂的功能实现时，Activity会很臃肿，并且最好不要让Activity太耗时

因此，引出下面的MVP模式
MVP架构模式

Android MVVM架构模式（一）
1 View：XML,Activity，Fragment，Adapter等
View不部署任何业务逻辑
2 Presenter：处理所有的业务逻辑
3 Model：数据库，网络操作
4 View Interface ：View 通过View Interface与 Presenter交互，降低耦合，单元测试的时候，可以不需要部署到真机或者模拟器测试，只需要通过interface模拟Activity对Presenter进行测试。

特点：
1 View与Model不直接交互
2 可以将Presenter用于多个View，增加灵活性

Passive View
Presenter是主动的，控制整个框架体系。

缺点：

Activity需要实现各种跟UI相关的接口，同时要在Activity中编写大量的事件，然后在事件处理中调用presenter的业务处理方法，View和Presenter只是互相持有引用并互相做回调,代码不美观。
这种模式中，程序的主角是UI，通过UI事件的触发对数据进行处理，更新UI就要考虑线程的问题。而且UI改变后牵扯的逻辑耦合度太高，一旦控件更改（比较TextView 替换 EditText等）牵扯的更新UI的接口就必须得换。
复杂的业务同时会导致presenter层太大，代码臃肿的问题。

MVVM架构模式

Android MVVM架构模式（一）

1 View：XML，Activity，Fragment，Adapter等

View不部署任何业务逻辑

不写和业务逻辑相关代码，也不写需要根据业务逻辑来更新UI的代码，因为更新UI通过Binding实现，更新UI在ViewModel里面做
Activity 要做的事就是初始化一些控件和更新一些与事务逻辑无关的UI更新（点击变色，滑动渐变,RecyclerView的分隔线设置等）

2 ViewModel：处理所有的业务逻辑
通过DataBinding 框架双向绑定，将数据在相应的控件上会自动去更改UI，也可以将View的变动自动反馈给ViewModel层进行操作。
一般包括：

Context （上下文）
1 做网络请求我们必须把Retrofit Service返回的Observable绑定到Context的生命周期上，防止在请求回来时Activity已经销毁等异常，其实这个Context的目的就是把网络请求绑定到当前页面的生命周期中
2 两个ViewModel 之间的联系是通过Messenger来做，这个Messenger 是需要用到Context
Model (数据模型Bean)
把数据映射到View中可能需要大量对Model的数据拷贝，拿Model 的字段去生成对应的ObservableField（我们不会直接拿Model的数据去做展示），这里其实是有必要在一个ViewModel 保留原始的Model引用
Data Field （数据绑定）
Command （命令绑定）
Child ViewModel （子ViewModel）
ViewModel 是以业务划分的，若你一个Activity里面有两个Fragment，并且两个Fragment做的业务不一样，因此由两个ViewModel来处理。Activity 本身可能就有个ViewModel 来做它自己的业务，这时候Activity的这个ViewModel里面可能包含了两个Fragment分别的ViewModel

3 Model：数据库，网络操作
实体模型（Bean）
Retrofit 的Service
ViewModel 可以根据Model 获取一个Bean的Observable( RxJava ),然后做一些数据转换操作和映射到ViewModel 中的一些字段，最后把这些字段绑定到View层上

圈1+圈2：
数据绑定，命令绑定
ViewModel和View之间通过data-binding双向绑定，当其中之一变动，另一个会自动反映。降低耦合性
MVVM Light Toolkit 也完善了一些data-binding框架不足之处

圈3
圈4

1 在MVVM中，数据和业务逻辑处于一个独立的View Model中，ViewModel只要关注数据和业务逻辑，不需要和UI或者控件打交道。由数据自动去驱动UI去自动更新UI，UI的改变又同时自动反馈到数据，数据成为主导因素，这样使得在业务逻辑处理只要关心数据

2 在MVVM中，我们可以在工作线程中直接修改View Model的数据（只要数据是线程安全的），剩下的数据绑定框架帮你搞定

3 MVVM的分工是非常明显的，由于View和View Model之间是松散耦合的。一个是处理业务和数据，一个是专门的UI处理。

4 一个View Model复用到多个View中，同样的一份数据，用不同的UI去做展示，对于版本迭代频繁的UI改动，只要更换View层就行
5
参考文献：
https://www.tianmaying.com/tutorial/AndroidMVC
http://www.jianshu.com/p/2fc41a310f79