谈谈android中的MVC,MVP和MVVM
MVC
在jsp等网页架构中，mvc比较清晰，view就是网页前端,moderl数据端，controller在jsp中的体现就是Servlet，但在android中，这个架构一直存在问题。原因无他，皆因android中，view层和controller层经常混在一起。
假设xml布局是view层，逻辑层属于四大组件，moderl继续是数据逻辑，咋眼看没啥大问题，但是xml布局不能处理任何逻辑，控制能力实在太弱，你想去动态的改变一个页面的背景，或者动态的隐藏/显示一个按钮，这些都没办法在xml中做，只能把代码写在activity中，造成了activity既是controller层，又是view层的这样一个窘境。大家回想一下自己写的代码，如果是一个逻辑很复杂的页面，activity或者fragment是不是动辄上千行呢？这样不仅写起来麻烦，维护起来更是噩梦。
第二、mvc经典模式中view和moderl层耦合性很高，可以相互调用，所以需要新的框架，解耦
MVC -> MVP
MVP作为MVC的演化，解决了MVC不少的缺点，对于Android来说，MVP的model层相对于MVC是一样的，而activity和fragment不再是controller层，而是纯粹的view层，所有关于用户事件的转发全部交由presenter层处理。
view层和model层不再相互可知，完全的解耦，取而代之的presenter层充当了桥梁的作用，用于操作view层发出的事件传递到presenter层中，presenter层去操作model层，并且将数据返回给view层，整个过程中view层和model层完全没有联系。看到这里大家可能会问，虽然view层和model层解耦了，但是view层和presenter层不是耦合在一起了吗？其实不是的。
具体的做法是activity，fragment可以去实现定义好的接口,然后将本对象以接口形式让对应的presenter持有，这样基于接口的通信就实现了
不仅如此，我们还可以编写测试用的View，模拟用户的各种操作，从而实现对Presenter的测试。这就解决了MVC模式中测试，维护难的问题。
总结：
- activity变成了纯粹的view层
- presenter相当于controller,view层和presenter通过接口通信
- 相比mvc,整个架构清晰了,
MVC -> MVVM
从图中看出，它和MVP的区别貌似不大，只不过是presenter层换成了viewmodel层，还有一点就是view层和viewmodel层是相互绑定的关系，这意味着当你更新viewmodel层的数据的时候，view层会相应的变动ui。
activity还是纯粹的view层
(有疑问等待修改，因为基于绑定的关系只能简单的视图和数据刷新同步，逻辑处理放再哪里呢？我估计还是要放在activity上面，无法做到纯粹)
binding类，其实就是上图中view和viewmodel中间的那根线啊
表明bindable属性的类就是viewmoderl
总结：
-缺陷是viewmoderl层和view层基于绑定建立关系，太弱爆了，viewmodel无法控制view层。
两者的结合 MVPVM（MVP+data binding）
我们使用了data binding框架去节省了类似findViewById和数据绑定的时间，又使用了presenter去将业务逻辑和view层分离。