本文主要是介绍探究 Android MVC、MVP、MVVM 的区别以及优缺点,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
- 1. MVC
- MVC
- MVC 优点
- MVC 缺点
- 2. MVP
- MVP 优点
- MVP 缺点
- 3. MVVM
- MVVM 概念
- MVVM 优点
- MVVM 缺点
- 4. Why use Jetpack + MVVM?
- 5. 总结:我理解中的 MVVM
- 5.1 相较于 MVC 和 MVP 的优势
- 1. 解决了各个层级之间耦合度太高的问题
- 2. 解决了代码量太多,或者模式化代码太多的问题
- 3. 解决了可能会有的内存泄漏问题
- 4. 解决了因为Activity停止而导致的View空指针问题
- 5. 解决了生命周期管理问题
- 5.2 最后再说说MVVM为什么这么强大?
- 参考链接
1. MVC
MVC
- 架构介绍
Model
:数据模型,负责处理数据的加载或存储,比如我们从数据库或者网络获取数据View
:视图,负责界面数据的展示,与用户进行交互,也就是我们的xml布局文件Controller
:控制器,负责逻辑业务的处理,也就是我们的Activity
MVC 优点
简单,上去就是复制粘贴一顿怼
- 1.
View
接受用户的请求,然后将请求传递给Controller
- 2.
Controller
进行业务逻辑处理后,通知Model
去更新 -
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
职责过多,代码臃肿
的问题。
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 概念
有 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
的值
- eg:
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 = 强大
参考链接
- Android框架模式——MVVM
- 项目架构三问
这篇关于探究 Android MVC、MVP、MVVM 的区别以及优缺点的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!