引言
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会更好点。
MVVM如何使用
篇幅原因，下一篇文章将为大家详细介绍如何使用MVVM框架，敬请期待；
网友评论