Android框架

Android框架

看到Google提出新的架构组件，想要按照我的角度写写Android框架。

MVC

从我接手Android开始，就一直有MVC框架。事实上，Android系统的搭建方式就是使用MVC。

• 应用

M：数据Model层，比如各种高大上的算法、网络请求、SD卡数据存取等等

V： 用户界面部分，在Android中就是各种的XML文件，这部分是Android系统为我们设计好的

C：业务逻辑层，Activity／Fragment，这一层也是Android系统为我们设计好的。控制用户界面数据的显示、model对象的更等等

• 优点

1. 耦合性低。利用MVC框架让View层和Model层很好的分离，达到解耦的目的
2. 可扩展性好。添加需求、扩展代码可以减少修改之前的代码
3. 模块职责划分明确。这一部分可以说是Android系统就提我们划分好了。

• 缺点

1. Activity/Fragment 特别的臃肿。按照MVC的设计方式，很多事情都需要通过Activity/Fragment操作

MVP

说完MVC，接着就会想到MVP。MVP是在MVC的基础上整理出来的。MVC是一种高大上的框架，但是对于Android开发而言，并不一定需要这么强的开发模式。

• 应用

M：业务逻辑层，比如各种高大上的算法、网络请求、SD卡数据存取等等。这一点相比MVC模式，其实并没有什么本质的区别

V： Activity和Fragment，视图层。从这里可以看到，在MVC模式中，Activity和Fragment都属于C层，也就是Controller层。但是在MVC模式下，Activity和Fragment特别臃肿。所以MVP主要在这里做了处理

P：presenter，其实相当于MVC模式中的Controller，但是和Controller有明显的区别

在MVP模式中，View和Model完全的隔离开了，中间只是靠P层进行交互。在MVP的设计中，P层不要持有任何的View对象，不能直接对任何的View进行操作

• 优点

1. 分离了试图逻辑和业务逻辑，降低了耦合性
2. Activity，Fragment更加的简单
3. 代码的可阅读性更高
4. 方便单元测试
5. 把业务逻辑抽到Presenter中，避免了后台线程引用Activity资源导致内存溢出

• 缺点

1. 业务复杂时，可能让Activity更加的复杂，会实现N个IView接口
2. 各个角色之间的通信变得复杂
3. 类文件数量过多，哪怕实现一个简单的功能，也要创建出过多的类文件

MVVM

MVVM和MVC有一点像，最主要的就是View和Data绑定在一起

Bind动作：DataBinding是一个support包。在使用它之后，XML文件不再时一个单纯的View，它新增加了一个data节点，通过这个节点，可以为一些View提供数据

具体示例如下：

http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0603/2992.html

• 应用

M：和MVC模式中的一样

V：和MVC模式中的一样，也是一些XML文件，不过这些文件中新增了一些数据绑定的对象

VM：ViewModel，我的感觉是和MVC模式中的Controller一样，但是它只专注于业务逻辑的处理，不去持有任何控件的应用

• 优点

1. 双向绑定技术，当Model变化时，ViewModel会自动更新，View也会自动变化
2. View的功能进一步强化，具有控制能力
3. 控制器进行了大量的瘦身，不用在写那么多的控制条件
4. 可以对View或者ViewController的数据处理部分抽离出一个函数处理Model，这样更加的简化

• 缺点

1. 数据绑定使得BUG很难被调试
2. 数据长期持有，不释放内存，会花费大量的内存
3. 数据双向绑定不利于代码重用

MVC，MVP，MVVM

	MVC	MVP	MVVM
Model	典型MVC中的Model与View存在耦合，一般情况下Model会通过事件监听的形式通知View数据发生了改变	MVP下Model和View没有任何直接的耦合，其更像一个数据仓库对外提供相应的数据	MVVM中的Model和MVP中的很相似，但是MVVM中的还会配合Binder绑定数据变化的监听
View	典型MVC中的View层比较简单，主要就是界面相关的逻辑，为了方便查询数据和监听数据变化，View还会和Model有一定的耦合	MVP下的View与MVC不同的是，View不再与Model由直接的联系。同时在一些情况下View还会依赖与接口进一步的解耦	MVVM中的View层除了处理UI相关的逻辑，还会配合Binder绑定数据和监听
--	Controller	Presenter	ViewModel
	典型MVC中的Controller主要处理用户交互逻辑，其接收View层的交互事件并根据事件的不同调用不同的Model层逻辑或者直接进行View层的切换。对于Controller而言，并不关心View层如何被展示，Controller只会修改对应的Model层，View层的刷新则由Model层通过观察者模式通知	Presenter的作用类似与MVC中的Controller，但是其会反作用与View层。Model层的数据更新首先会反馈到Presenter，在由Presenter优先处理并且决定是否刷新以及刷新那个View。也就是说：Presenter完全将View层与Model层隔离开，充当一个中间人的角色	相对于Controller和Presenter，ViewModel的指责更加的少，它将原来Controller和Presenter于View和Model交互的业务逻辑抽离到Binder处理。大部分情况下，Binder都会由对应的框架实现，对于开发者而言，自己实现的ViewModel部分就相对变少了