一位Android资深工程师对移动端架构的思考( 二 ) _Android

优点：
1、模型与视图完全分离（就像牛郎和和织女隔了一个银河，每次都需要靠燕子来传信，好可怜~~）
2、可以更高效地使用模型，因为所有的交互都发生在一个地方——Presenter内部
3、（Presener的复用）一个Presener可以用于多个视图（View），而不需要改变Presenter的逻辑。视图（View）的变化比模型（Model）的变化更频繁的多，所以这样超级方便。
4、（View的复用）View可以进行组件化。在MVP当中，View不依赖Model 。这样就可以让View从特定的业务场景中脱离出来，可以说View可以做到对业务逻辑完全无知。它只需要提供一系列接口提供给上层操作。这样就可以做高度可复用的View组件。
5、更容易单元测试
缺点：
1、由于对视图的渲染放在了Presenter中，所以视图View和Presenter的交互会过于频繁。特别是需要修改视图的时候，Presenter也需要跟着修改，很麻烦。
2、Presenter中除了业务逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，造成Presenter比较笨重，维护起来会比较困难。
3、其实总的来说就是结构很清晰，业务逻辑也很明白，耦合低，但是就是自己写的麻烦，Presenter不好维护，工作量太大，太笨重，有点像MVC中的Activity了，职责太多了。也可以把这三个缺点总结成一句话，麻烦，尾大不掉。
进化3.0 MVVM但是吧，你们爽了Presenter可就累坏了，大事小事都要经过Presenter，就连放个屁也要Presenter来扒裤子，日子过得久了，Presenter总会有意见啊，不带这么使唤人的。
我们就想啊，以前过多的依赖Activity造成结构混乱，耦合太高，后来有了Presenter，虽然耦合大大降低，但是还是过于依赖Presenter，为啥总会过于依赖某一个东西呢，就不能大家都干点活，耦合性也不高的吗？就不能大家有事相互通知吗？非要那么懒依赖别人吗？总要有点正能量吧。那么我们就把Presenter辞退，引入了一个新的小伙伴VM（ViewModel即 Model of View）它即包含了Modle也有View的状态。
MVVM模式中，一个ViewModel和一个View匹配，它没有MVP中的IView接口，而是完全的和View绑定，所有View中的修改变化，都会自动更新到ViewModel中，同时ViewModel的任何变化也会自动同步到View上显示。
这种自动同步的原因其实就是是ViewModel中的属性都实现了observable这样的接口，也就是说当使用属性的set的方法，都会同时触发属性修改的事件，使绑定的UI自动刷新。
在android中DataBinding帮助我们实现MVVM，在XML进行数据绑定，增加了XML的重量，不再像以前那样仅仅是布局，均衡了各部分的职责。
所以MVVM比MVP更升级一步，在MVP中，V是接口IView, 解决对于界面UI的耦合; 而MVVM干脆直接使用ViewModel和UI无缝结合, ViewModel直接就能代表UI.

文章插图

优点：
1、解决了MVP大量的手动View和Model同步的问题，提供双向绑定机制。提高了代码的可维护性。大大方便了开发者。（只有试过才知道有多方便）
2、简化测试。
3、响应式编程更方便。
缺点：
1、过于简单的图形界面显得大材小用（让开发者麻烦的都是缺点）
2、视图状态较多，ViewModel的构建和维护的成本都会比较高。
3、数据绑定的声明是指令式地写在View的模版当中的，这些内容是没办法去打断点debug的。（这是很碉堡的，只能自己细心了）
进化4.0 CLEAN进化了一代有一点，作为东家的谷歌坐不住了，给不给我面子了，来来来，我给你们一个终结的，CLean~~~
WTF？这个洋葱一个的家伙是谁？再给你一个圈就是五环了~~四个圈圈了不起啊？