Android 设计模式对比

从来好事天生俭，自古瓜儿苦后甜。这篇文章主要讲述Android 设计模式对比相关的知识，希望能为你提供帮助。
引言：
android框架的发展的过程就是一个不断化繁为简的过程，大家都在研究如何正确方便高效的规范代码。当然这条路也永远不会停止，就像新的芽儿，随着时间的流逝，每天都在长出新的枝叶，每天都在成长。对于技术，每次新框架的提出都在剔除旧框架的诟病和痛点，演变成更方便，更高效，更简洁的新框架，然后新的框架在具体使用中又会带来新的诟病和痛点，反反复复，无穷尽也......从开始使用MVC到使用MVP,从MVP到MVVM,每次框架的提出都有让我们眼前一亮的东西，但具体使用中确还是存在很多的痛点，似乎一直存在一种反作用力来阻止我这样做。但又能怎样？新的芽儿注定会长成参天大树，技术终究只会进步。

概述 MVC
MVC这里就不多说了，大家都熟悉的不能再熟悉了，比较古老的框架了，相信大家也都使用过；

文章图片

MVC具体使用

Model：数据模型，javaBean
View:layout布局文件
Control：Activity，处理数据请求，业务逻辑

MVC的诟病

View和Control耦合严重，Activity中存在大量的逻辑代码，Activity既是View，又是Control，结构不清晰，Activity中内容太多

MVP
MVP是在MVC的基础上把Control独立出来的模型，简化Control的内容，这里Presenter充当中间代理的角色，view和Model不直接交互，而是通过Presenter

文章图片

MVP的具体使用

Model：实体模型，JavaBean
View：Activity和Layout
Presenter：View和Model通过Presenter交互

MVP的诟病

粒度很难把握，使用过MVP的都知道，MVP模型需要定义比较多的接口，View需要定义接口，presenter需要定义接口，以前我们使用一个activty能解决的问题，现在要将一个Activity分解成一个View，一个Preseter，一个Model，每个模块都需要使用接口来实现解耦，这样就会导致有时候一个activity中涉及的业务比较多，按每个业务点搭建MVP模型的话，会导致原来一个Activity类能搞定的，现在需要扩展成多个接口，多个类才能实现；粒度大的话，可能结构不清晰；粒度小的话，代码量又会比较大；
MVP是以UI和事件为驱动的模型，数据的获取是被动的根据UI变动的，我们更希望是数据变化去更新UI，而不是反过来；
Presenter和View耦合度比较高；
Presenter类在业务比较复杂情况下，代码量比较大；

MVVM
MVVM是在MVP的基础上，根据谷歌提出的DateBinding方案重新设计的一个灵活高效的框架，MVVM使用ViewModel一层代替原来的Presenter层;

文章图片

MVVM的使用

Model：数据模型，JavaBean
View：Activty和Layout
ViewModel：View和Model业务逻辑交互

MVVM的优点
数据驱动
在MVVM中，数据的变化可以自动更新view，不需要获取view的引用；
耦合较低
【Android 设计模式对比】MVP模式中View和Presenter是强耦合的，Presenter需要拿到View的引用，这样当View变动时，Presenter也需要变化，耦合度太高；现在MVVM中，ViewModel只负责数据和业务，View的变化，ViewModel不需要关系，数据变化，View自动更新，耦合度比较低；
View更新
MVVM模型中不用考虑是否在主线程中更新UI，DateBinding会负责在主线程中更新UI的，我们不用担心线程的问题，简单的不止一点点；
可重复利用
一个ViewModel就是一个数据源，可以将一个ViewModel绑定到不同的View中，就可以达到更新view目的
MVVM的诟病

MVVM由于是基于google的DataBinding框架的，而DataBinding支持的绑定View还比较少，因此在使用的过程中可能会遇到某些view无法使用DateBinding的情况，这点也是我之前没有使用MVVM的原因
既然存在上面的问题，国内外的大牛已经帮我们封装好了一套使用dateBinding的view库，为避免重复造轮子，我们可以将它引入到我们的项目中直接使用，目前我知道的已经支持常用所有View；

总结经过上面对不同框架的对比，相信大家都有一个基本的了解，有人会问这么多框架，我们使用那个比较好呢？
个人觉得，技术是在不断进步，旧的框架最终都会被新的框架所代替，我觉得MVVM的提出解决了我们使用其他框架的很多痛点，我觉得使用MVVM会更好点。