1. MVC

MVC

  • 架构介绍
  • ​​Model​​：数据模型，负责处理数据的加载或存储，比如我们从数据库或者网络获取数据
  • ​​View​​：视图，负责界面数据的展示，与用户进行交互，也就是我们的xml布局文件
  • ​​Controller​​：控制器，负责逻辑业务的处理，也就是我们的Activity

MVC 优点

简单，上去就是复制粘贴一顿怼

探究 Android MVC、MVP、MVVM 的区别以及优缺点_mvc

  • 1.​​View​​​ 接受用户的请求，然后将请求传递给​​Controller​​
  • 2.​​Controller​​​ 进行业务逻辑处理后，通知​​Model​​去更新
  1. ​​Model​​​ 数据更新后，通知​​View​​ 去更新界面显示
  • 这里容易发生耦合
  • ​​View --> Controller​​​，也就是反应​​View​​​ 的一些用户事件（点击触摸事件）到​​Activity上​​
  • ​​Controller --> Model​​​, 也就是​​Activity​​ 去读写一些我们需要的数据
  • ​​Controller --> View​​​, 也就是​​Activity​​​ 在获取数据之后，将更新内容反映到​​View​​上`

MVC 缺点

  • Android中使用了​​Activity​​​ 来充当​​Controller​​​，但实际上一些​​UI​​​ 也是由​​Activity​​​ 来控制的，比如进度条等。因此部分视图就会跟​​Controller​​​ 捆绑在同一个类了。同时，由于​​Activity​​​ 的职责过大，​​Activity​​ 类的代码也会迅速膨胀
  • 主要表现就是我们的​​Activity​​​ 太重了，经常一写就是几百上千行了。造成这种问题的原因就是​​Controller​​​ 层和​​View​​​ 层的关系太过紧密，也就是​​Activity​​​ 中有太多操作​​View​​ 的代码了
  • MVC还有一个重要的缺陷就是​​View​​​ 跟​​Model​​ 是有交互的，没有做到完全的分离，这就会产生耦合。

PS: 但是！但是！其实Android这种并称不上传统的MVC结构，因为Activity又可以叫View层又可以叫Controller层，所以我觉得这种Android默认的开发结构，其实称不上什么MVC项目架构，因为他本身就是Android一开始默认的开发形式，所有东西都往Activity中丢，然后能封装的封装一下，根本分不出来这些层

2. MVP

PS：之前不就是因为Activity中有操作view，又做Controller工作吗。所以其实MVP架构就是从原来的Activity层把view和Controller区分开，单独抽出来一层Presenter作为原来Controller的职位。

然后最后演化成，将 ​​View​​ 层写成接口的形式，然后Activity去实现View接口，最后在Presenter类中去实现方法

总之呢，就是解决：

  • 将​​Controller​​​ 与​​View​​彻底分离。
  • 解决​​MVC​​​ 中​​Activity​​ 职责过多，代码臃肿

的问题。

探究 Android MVC、MVP、MVVM 的区别以及优缺点_数据_02

  • ​​Model​​：数据模型，比如我们从数据库或者网络获取数据
  • 跟​​MVC​​​不同的地方在于​​Model​​​ 不会跟​​View​​​ 发生交互，只会跟​​Presenter​​ 交互
  • ​​View​​：视图，也就是我们的xml布局文件和Activity
  • MVP在实现上来说可以有多种思路，不同的实现方式其优缺点也是不同的，具体问题具体分析
  • eg: 也有场景下​​Activity​​​ 作为​​Presenter​​ 会更好一些
  • ​​Presenter​​：主持人，单独的类，只做调度工作。
  • ​​View --> Presenter​​​，反应​​View​​​ 的一些用户事件到​​Presenter​​上。
  • ​​Presenter --> Model​​​,​​Presenter​​去读写操作一些我们需要的数据。
  • ​​Presenter--> View​​​,​​Presenter​​​在获取数据之后，将更新内容反馈给​​Activity​​​，进行​​view​​ 更新。

通常View与Presenter是一对一的，但复杂的View可以绑定多个Presenter来处理逻辑。

MVP 优点

这种的优点就是确实大大减少了 ​​Activity​​​ 的负担，让 ​​Activity​​​ 主要承担一个更新 ​​View​​​ 的工作，然后把跟 ​​Model​​​ 交互的工作转移给了 ​​Presenter​​​，从而由​​Presenter​​​方来控制和交互 ​​Model​​​方以及 ​​View​​。所以让项目更加明确简单，顺序性思维开发。

  • ​​View​​​ 与​​Model​​ 完全分离，我们可以修改视图而不影响模型。
  • 可以更高效地使用模型，因为所有的交互都发生​​Presenter​​ 中
  • ​​Presenter​​​ 与​​View​​ 的交互是通过接口来进行的，有利于添加单元测试。

MVP 缺点

缺点也很明显：

  • 首先就是代码量大大增加了，每个页面或者说功能点，都要专门写一个​​Presenter​​类，并且由于是面向接口编程，需要增加大量接口，会有大量繁琐的回调。
  • 页面逻辑复杂的话，相应的接口也会变多，增加维护成本
  • 其次，由于​​Presenter​​​ 里持有了​​Activity​​​ 对象，所以可能会导致内存泄漏或者​​view​​ 空指针，这也是需要注意的地方。
  • 系统内存不足时，系统会回收​​Activity​​​。一般我们都是用​​OnSaveInstanceState()​​​ 去保存状态，用​​OnRestoreInstanceState()​​​ 去恢复状态。但是在我们的​​MVP​​​中，​​View​​​层是不应该去直接操作​​Model​​​的，所以这样做不合理，同时也增大了​​M​​​ 与​​V​​的耦合。
  • 解决办法是不要将​​Activity​​​ 作为​​View​​​ 层，可以把​​Activity​​​当​​Presenter​​来处理。具体实现这里就不分析了，有兴趣的可以研究一下
  • ​​UI​​​ 改变的话，比如​​TextView​​​ 替换​​EditText​​​，可能导致​​Presente​​​ 的一些更新​​UI​​ 的接口也跟着需要更改，存在一定的耦合

3. MVVM

MVVM 概念

探究 Android MVC、MVP、MVVM 的区别以及优缺点_mvc_03

有 ​​Google​​​ 官方加持，更新了 ​​Jetpack​​​ 中很多架构组件，比如 ​​ViewModel​​​，​​Livedata​​​，​​DataBinding​​等等，所以这个是现在的主流框架和官方推崇的框架。

Model：数据模型，比如我们从数据库或者网络获取数据。View：视图，也就是我们的xml布局文件和Activity。ViewModel：关联层，将Model和View绑定，使他们之间可以相互绑定实时更新

  • ​​Model​​：模型层，负责处理数据的加载或存储。与 MVP中的M一样。
  • ​​View​​：视图层，负责界面数据的展示，与用户进行交互。与MVP中的V一样。
  • ​​ViewModel​​​：视图模型，负责完成​​View​​​ 于​​Model​​ 间的交互,负责业务逻辑。
  • ​​View​​​ 与​​ViewModel​​ 进行绑定，能够实现双向的交互
  • ​​ViewModel​​​数据改变时，​​View​​​ 会相应变动​​UI​​，反之亦然
  • ​​ViewModel​​​ 进行业务逻辑处理，通知​​Model​​ 去更新
  • 可以与​​View​​​ 实现​​databinding​​ 双向绑定 ， 使他们之间可以相互绑定实时更新
  • ​​Model​​​ 数据更新后，把新数据传递给​​ViewModel​​
  • eg:​​Activity​​​ 中监听​​viewModel.value​​​ 变化，监听到之后改变​​view​​ 的值
  • ​​View --> ViewModel -->View​​，双向绑定，数据改动可以反映到界面，界面的修改可以反映到数据
  • ​​ViewModel --> Model​​, 操作一些我们需要的数据

MVVM 优点

​​MVVM​​​ 已经被实践证明是一种优秀的设计模式。能很好地将 ​​UI 、交互逻辑、业务逻辑​​​ 和 ​​数据​​ 解耦

  • 降低​​View​​​和​​Controller​​ 的耦合，减轻了视图的压力
  • Activity 代码不会像 MVC 那样那么臃肿，方便维护
  • 相比于​​MVP​​​ 中​​Presente​​​ 与​​View​​​ 存在耦合。​​ViewModel​​​ 与​​View​​​ 的耦合则更低，​​ViewModel​​ 只负责处理和提供数据，UI的改变，比如TextView 替换 EditText，ViewModel 几乎不需要更改任何代码，只需专注于数据处理就可以了。
  • ​​ViewModel​​ 里面只包含数据和业务逻辑，没有UI的东西，方便单元测试。

MVVM 缺点

  • 数据绑定使得程序较难调试
  • 界面出现异常时，有可能是 View 的代码有问题，也可能是 Model 的代码有问题。
  • 由于数据绑定使得数据能够快速传递到其他位置，因此要定位出异常就比较有难度了。

4. Why use Jetpack + MVVM？

我们通常使用 Jetpack 配合 MVVM 一起使用，为什么呢？

  • 快速开发
  • 组件可以单独采用（不过这些组件是为协同工作而构建的），同时利用 Kotlin 语言功能帮助您提高工作效率。
  • 消除样板代码
  • Android Jetpack 可管理繁琐的 Activity（如后台任务、导航和生命周期管理），以便您可以专注于如何让自己的应用出类拔萃。
  • 构建高质量的强大应用
  • Android Jetpack 组件围绕现代化设计实践构建而成，具有向后兼容性，可以减少崩溃和内存泄漏。

开发者可以减少许多样板代码的书写，只需要通过模版工具自动生成就可以了，在取缔非常多的耗时的重复工作的同时，减少了很多因为忘记 unRegister带来的各种问题

5. 总结：我理解中的 MVVM

5.1 相较于 MVC 和 MVP 的优势

1. 解决了各个层级之间耦合度太高的问题

  • 也就是更好的完成了解耦
  • ​​MVP​​​ 层中，​​Presenter​​​ 还是会持有​​View​​ 的引用
  • 但是在​​MVVM​​​中，​​View​​​和​​Model​​​进行双向绑定，从而使​​viewModel​​ 基本只需要处理业务逻辑，无需关系界面相关的元素了

2. 解决了代码量太多，或者模式化代码太多的问题

由于双向绑定，所以UI相关的代码就少了很多，这也是代码量少的关键。而这其中起到比较关键的组件就是 ​​DataBinding​​​，使所有的 ​​UI​​ 变动都交给了被观察的数据模型

3. 解决了可能会有的内存泄漏问题

​​MVVM​​​ 架构组件中有一个组件是 ​​LiveData​​​，它具有生命周期感知能力，可以感知到 ​​Activity​​ 等的生命周期，所以就可以在其关联的生命周期遭到销毁后自行清理，就大大减少了内存泄漏问题

4. 解决了因为Activity停止而导致的View空指针问题

在 ​​MVVM​​​ 中使用了 ​​LiveData​​​，那么在需要更新 ​​View​​​的时候，如果观察者的生命周期处于非活跃状态（如返回栈中的 Activity），则它不会接收任何 ​​LiveData​​ 事件。

也就是他会保证在界面可见的时候才会进行响应，这样就解决了空指针问题。

5. 解决了生命周期管理问题

这主要得益于​​Lifecycle​​组件，它使得一些控件可以对生命周期进行观察，就能随时随地进行生命周期事件。

5.2 最后再说说MVVM为什么这么强大？

​​MVVM​​​ 这个架构本身就比较优秀，再加上Google官方的大力支持，出了这么多 ​​Jetpack​​​ 的组件，有效缓解了以前 ​​MVVM​​ 八仙过海的各种实现方式。

我觉得就是以下三点优势：

  • 解耦，上手成本更低，方便测试，方便维护
  • 快速开发，消除样板代码
  • 构建高质量的强大应用

优秀的架构思想+官方支持 --> JetPack + MVVM = 强大

参考链接