android 中的框架,聊聊 Android 中的三大框架

为什么我们要用到开发模式，如果单单说写一些 Demo 或者一个工程只有几个Java文件，其实也没有别要去想太多的架构问题，直接撸代码就完事了。但是如果一个项目代码量比较多、业务比较繁琐、扩展性高。那么我们前期的规划是必不可少的，更加需要我们关注架构层面。

接下来我们看下 Android 现有的几大架构

一、MVC ———— Model-View-Controller

M：Model(模型)   M层是用来处理数据以及业务逻辑关系

V：View(视图)   V 层是用来数据的显示

C：Controller(控制器) C 层是把M和V之间的桥梁

在 Android 开发中，Activity 本身并不是一个标准的 MVC 模式中的 Controller，它的首要职责是加载应用的布局和初始化用户界面，并接受并处理来自用户的操作请求，进而作出响应，这样就会难免出现在Activity去处理数据。在数据处理和业务逻辑越来越多的情况下，View也就是Activity或Fragment就会很臃肿，代码量蹭蹭的往上涨，不太利于后期的开发和维护。这就会我们引进MVP。

举个例子:

比如说我们要实现这样的一个功能，当点击“登陆”按钮时，查询自己的账号余额。

对于MVC 实现，应该是这样的：

先定义一个 model，需要有通知View更新的能力，在model加载成功以及获取数据之后，通知View进行UI更新：

为了更好的理解MVC，将Activity进行了拆解，提取了一个简单的Controller：

点击事件，并且传递给Controller，同时根据Model回调的方法进行UI更新：

二、MVP  ————  Model-View-Presenter

M：提供数据

V：显示数据

P：处理逻辑

其实MVP就是MVC延伸出来，同样是划分三层，不过MVP的Presenter让Activity更加专注于处理页面显示。这样做的好处就是：让Activity只做UI的处理，数据处理和业务逻辑全丢给Presenter来完成。但是有个缺点就是我们要写很多的接口类，增加代码量。

还是上面的例子，我们使用MVP进行改写：

先对MVCModel进行封装，通知Presenter：

再定义Presenter ，逻辑处理，然后通知View更新UI：

对于Activity，把Model对象变成Persenter：

三、MVVM ———— Model-View-ViewModel

M：model  实体模型

V：view  UI交互层(Activity、fragment)

VM：ViewModel  负责View与Model之间的交互，业务逻辑处理

首先MVVM是一种模式，而实现这种模式的就要用到Data Binding(关于这个可以在网上搜索学习，这里不多介绍)。然后View和ViewModel是可以通过Data Binding来实现视图和数据的双向绑定，从而达到MVVM这样的效果。

例子暂无

对于个人来言，我更倾向于使用MVP模式来作为开发，不过这些都是相对于项目的难易程度来说的，不能一味死板套公式，灵活应变才是硬道理。