一文彻底搞懂MVC MVP MVVM 架构模式（Android）

• 对于我们 Android 开发者来说，常见的架构模式基本上就是 MVC，MVP，MVVM，这三种也是开发 GUI 应用程序常见的模式。除此之外还有 分层模式，客户端-服务器模式(CS模式)，主从模式，管道过滤器模式，事件总线模式 等等。这篇文章还是具体分析 MVC，MVP，MVVM 这三种架构模式。

1. Modle

无论在那个架构模式中，Model都是不变的，Model类封装了数据模型和相应的网络操作等

Model

• 首先看看MVC

在这里说的是Android开发中类似

xml(view)

activity、fragment(controller)

model

MVC

正解：当用户出发事件的时候，view层会发送指令到controller层，接着controller去通知model层更新数据，model层更新完数据以后直接显示在view层上，这就是MVC的工作原理。

个人理解:简单来说，controller就是model和VIew的中间件，视图的相关变化需要根据Model来的数据进行相应的变化，而model层需要从controller层获取数据，Veiw层变化直接使用model层的数据

比如你的界面有一个按钮，按下这个按钮去网络上下载一个文件，这个按钮是view层的，是使用xml来写的，而那些和网络连接相关的代码写在其他类里，比如你可以写一个专门的networkHelper类，这个就是model层，那怎么连接这两层呢？是通过button.setOnClickListener()这个函数，这个函数就写在了activity中，对应于controller层。是不是很清晰。>> 总结：对于这种架构模式，如果我们的项目很小(几百行代码量)，代码量不多，其实还是非常好的架构，但项目比较复杂的时候就不推荐这个架构了，因为他的逻辑代码全部都在controller中(activity或者fragment)，这就会显得activity非常的臃肿，也不好进行维护、管理

xml作为view层，控制能力实在太弱了，你想去动态的改变一个页面的背景，或者动态的隐藏/显示一个按钮，这些都没办法在xml中做，只能把代码写在activity中，造成了activity既是controller层，又是view层的这样一个窘境。大家回想一下自己写的代码，如果是一个逻辑很复杂的页面，activity或者fragment是不是动辄上千行呢？这样不仅写起来麻烦，维护起来更是噩梦。所以MVP架构来了

• 看看MVP

(盗图)

 

MVP

其实不难发现：这就是java中经典的数据回调的操作。由于activity和Model之间不直接通信，(只可远观而不可亵玩)所以让presenter作为一个中间件可以很好的解决这个问题。打个形象的比喻：就像织女和牛郎只能通过鹊桥才能获取双方的信息一样。presenter就相当于这个鹊桥。【注意这里是presenter和View】但视图层却也不认识presenter，presenter也不认识视图层，所以他们两个必须得知道对方的信息才能实现,他们之间必须建立联系，(分别得到对方的一个对象，万物皆对象)，但这样还不够，知道对象却也不知道他有什么方法，就好比你找了个男朋友，只知道他的人，却不知道他有多少钱。但你又必须知道他有多少钱，你才能用他的钱，这个时候，接口(银行)就出现了，大家都知道这个接口(银行)而你的男朋友必须把钱存入银行(实现这个接口)，你知道男朋友的身份信息就可以拿着去银行查询他有多少钱(查看presenter接口中的方法，而presenter实现类必定具有里面的方法)，最终达成目的。

实现过程view视图将逻辑判断等代码放入到presenter中，再由presenter传到Model中；而Model中的数据传过来也是先在presenter中，再写入到View中相应的位置显示即可。

总结：其实认真体会就会发现MVP还是很不错的，他将View层变得简单，不再有冗余的代码，不再有大量逻辑代码，而将这些代码统统放进了presenter里面，使程序的维护的难度降低，不再用去读Activity中看花眼睛的代码，直接在presenter中修改相应的接口函数即可。

---

• MVVM架构模式

要了解MVVM，首先我们得了解ViewModel和liveData
ViewModel官网网址：https://developer.android.com/topic/libraries/architecture/viewmodel?hl=zh-cn
livaData官网网址：https://developer.android.com/topic/libraries/architecture/viewmodel?hl=zh-cn

ViewModel类是被设计用来以可感知生命周期的方式存储和管理 UI 相关数据，ViewModel中数据会一直存活即使 activity configuration发生变化，比如横竖屏切换的时候。我们知道在屏幕旋转的 时候 会经历 activity 的销毁与重新创建，这里就涉及到数据保存的问题，显然重新请求或加载数据是不友好的。在 ViewModel 出现之前我们可以用 activity 的onSaveInstanceState()机制保存和恢复数据，但缺点很明显，onSaveInstanceState只适合保存少量的可以被序列化、反序列化的数据，假如我们需要保存是一个比较大的 bitmap list ，这种机制明显不合适。由于 ViewModel 的特殊设计，可以解决此痛点。先来看下 ViewModel 生命周期图：

ViewModel

关于View Model具体什么时候被销毁？

• 其实看到这里我已经有点疑惑了，仔细看：

  

  ViewModel什么时候被销毁
• 同样都是生命周期中的onDestroy为什么上一个没有没有销毁ViewModel而下一个却销毁了呢？

下面给出解释：

当Activity 处于前台的时候被销毁了，那么得到的 ViewModel 是之前实例过的 ViewModel；如果 Activity 处于后台时被销毁了，那么得到的 ViewModel 不是同一个。举例说，如果 Activity 因为配置发生变化而被重建了，那么当重建的时候，ViewModel 是之前的实例；如果因为长期处于后台而被销毁了，那么重建的时候，ViewModel 就不是之前的实例了。而上一个onDestroy是前台的销毁，而后一个是后台的onDestroy

开始正式讲解MVVM

先看下图：

MVVM

• 思路：view给VM传数据是通过VM中定义的一系列方法，通过调用方法传递数据到VM中，而VM将得到的数据进行处理，传到model层，而View怎么更新ui呢？---》监听VM中的livadata对象，livadata对象一改变说明数据有变动就将新数据更新到ui上，相当于livedata不变我就不更新ui，livadata改变就更新ui

image.png

学习时间仓促，后期会修正其中说的不太对的地方。

推荐一篇博客写的不错https://blog.csdn.net/wo_ha/article/details/55519224