Android 框架MVVM详解

Love The Way You Lie 2021-09-12 04:46 905阅读 0赞

# 导读 #

# 我们一步步来，从MVC开始。 MVC 我们都知道，模型——视图——控制器。为了使得程序的各个部分分离降低耦合性，我们对代码的结构进行了划分。 #

![703e89ff78dce6b7f0db10cbcee55729.jpg][]

他们的通信方式也如上图所示，即View层触发操作通知到业务层完成逻辑处理，业务层完成业务逻辑之后通知Model层更新数据，数据更新完之后通知View层展现。在实际运用中人们发现View和Model之间的依赖还是太强，希望他们可以绝对独立的存在，慢慢的就演化出了MVP。

![d3306ab199e685acea781ca951f6d361.jpg][]

Presenter 替换掉了Controller，不仅仅处理逻辑部分。而且还控制着View的刷新，监听Model层的数据变化。这样隔离掉View和Model的关系后使得View层变的非常的薄，没有任何的逻辑部分又不用主动监听数据，被称之为“被动视图”。

![a2a194610e76aa6573bc39816dfb1935.jpg][]

至于MVVM基本上和MVP一模一样，感觉只是名字替换了一下。他的关键技术就是今天的主题(Data Binding)。View的变化可以自动的反应在ViewModel，ViewModel的数据变化也会自动反应到View上。这样开发者就不用处理接收事件和View更新的工作，框架已经帮你做好了。

## 一、什么是MVVM ##

MVVM模式包含了三个部分：

*  Model – 代表你的基本业务逻辑
 *  View – 显示内容
 *  ViewModel – 将前面两者联系在一起的对象

1:一个ViewModel接口提供了两个东西：动作和数据。动作改变Model的下层（click listener，监听文字改变的listener等等），而数据则是Model的内容。在传统的安卓架构中，controller负责推送数据给view。

2:在Activity中findview，然后在它上面设置内容。在MVVM中，ViewModel在改变内容之后通知binding framework内容发生了改变。然后framework自动更新和那些内容绑定的view。这两个组建只是通过ViewModel松耦合在一起。

3:因为ViewModel不在依赖于View了，你可以在没有View的情况下也能测试ViewModel。在合适的依赖注入的帮助下，测试就会变得非常简单。

MVVM是MVC设计模式的更先进进化，符合它进化的方向。 数据源被强化，不单只是请求过来的数据还包括，数据在本页面应该处于的状态，数据源对象在本页面或本模块中共享，一旦一个地方改变，本页面或模块中的所有数据源的内容都改变，保证了数据的一致性。它的全局共享性是它的一大特色。   
从控制器分离出来的非页面间关系部分和http请求部分，产生请求操作类.它可以被控制器调用，也可以被view调用。它负责数据数据请求参数的组装，甚至上次请求的暂存，服务器请求过来的数据转化为数据源数据，进行简单数据处理。我们称它为View-Model。一个页面可以有一个View-Model，也可以有多个View-Model，这个可以根据页面的复杂度和View(调用View-Model的View)是否在其它页面重用。若有View调用请求对象发送请求并且被其它页面重用该View，那么该View不能共享数据源。View-Model一般持有本页面或本模块的共享数据源。

## 二、优缺点： ##

MVVM设计模式的优点   
1.双向绑定技术，当Model变化时，View-Model会自动更新，View也会自动变化。很好做到数据的一致性，不用担心，在模块的这一块数据是这个值，在另一块就是另一个值了。所以 MVVM模式有些时候又被称作：model-view-binder模式。   
2.View的功能进一步的强化，具有控制的部分功能，若想无限增强它的功能，甚至控制器的全部功几乎都可以迁移到各个View上（不过这样不可取，那样View干了不属于它职责范围的事情）。View可以像控制器一样具有自己的View-Model.   
3.由于控制器的功能大都移动到View上处理，大大的对控制器进行了瘦身。不用再为看到庞大的控制器逻辑而发愁了。   
  
MVVM设计模式的缺点   
第一点：数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。   
第二点：一个大的模块中，model也会很大，虽然使用方便了也很容易保证了数据的一致性，当时长期持有，不释放内存，就造成了花费更多的内存。   
第三点：数据双向绑定不利于代码重用。客户端开发最常用的重用是View，但是数据双向绑定技术，让你在一个View都绑定了一个model，不同模块的model都不同。那就不能简单重用View了。   
被误解的MVC和被神化的MVVM（[http://www.infoq.com/cn/articles/rethinking-mvc-mvvm/][http_www.infoq.com_cn_articles_rethinking-mvc-mvvm]）这篇文章是MVVM彻头彻尾的反对者，好像该设计模式一文不值。我只能说他太偏激了，只顾着指责，没有看到他最显然的优点和改进。

## 三、优缺点改进  ##

MVVM更高级更先进表现在解放了控制器（Controller）,就是轻量级控制器。这个批评者也没有否定。MVVM不影响代码重用，其实抽象出来的一个一个小View就是为了代码重用的。反对者所谓的把网络请求封装到类里也就是View-Model。   
其实对它贬低最多的只剩下集优缺点于一身的双向绑定技术。那么他们也不治之症，也可以改进。   
对于调试困难的问题，确实存在，可以通过日志系统来定位，对数据被修改的地方进行敏感的地方进行日志打印。不会你的软件没有日志系统吧？   
对于影响内存问题，你可以通过划分模块时，把一个页面或两到三个页面划分为一个模块，那样应用的model也不大，内存开销很小。我大都把每个页面多划分一个模块，减少耦合度，软件开发的高内聚低耦合的设计思想大家都懂吧！若把一个项目的数据都整合到一个面面俱到的model, 那除非傻子才那么做，就是那样做了，那也不符合MVVM模式了。   
对于数据双向绑定不利于代码重用确实是一个问题。基本上重用的代码model都不相同。你可以对这两个model抽象成一个组合model.也可以观察你这个View需要哪些必须的数据，把它当变成成员变量，让他不绑定model.若这个View在两个模块使用，并且发送请求，那么你可以给这个View抽象为一个新的View-Model.   
若真像《被神化的MVVM》那篇文章说的那样改进MVC设计模式，那么它就不是 MVC了，它更像不采用ReactiveCocoa的 MVVM了。

[703e89ff78dce6b7f0db10cbcee55729.jpg]: /images/20210802/b022988ff6134e249677ca92d04f1481.png
[d3306ab199e685acea781ca951f6d361.jpg]: /images/20210802/0b1ec0fd7dfe470fab5451e0e063c6bd.png
[a2a194610e76aa6573bc39816dfb1935.jpg]: /images/20210802/4b3bd936f68141098953f3bf2ab8f8c3.png
[http_www.infoq.com_cn_articles_rethinking-mvc-mvvm]: http://www.infoq.com/cn/articles/rethinking-mvc-mvvm/