引言:
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的引用;
耦合较低
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会更好点。