Android开发框架模式MVC、MVP使用总结

一．基础概念

Android中最常用的框架开发模式是MVC和MVP。

这里要区分设计模式和框架模式。设计模式有23种,比如单例模式，工厂模式，适配器模式等等，都是java的设计思想相关的。本地主要对Android框架模式做详细介绍。

（一）MVC

MVC (Model-View-Controller)：M是指逻辑模型，V是指视图模型，C则是控制器。

一个逻辑模型可以对于多种视图模型，比如一批统计数据你可以分别用柱状图、饼图来表示。一种视图模型也可以对于多种逻辑模型。使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式，而C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新，这与《设计模式》中的观察者模式是完全一样。

MVC好处：从用户的角度出发，用户可以根据自己的需求，选择自己合适的浏览数据的方式。比如说，对于一篇在线文档，用户可以选择以HTML网页的方式阅读，也可以选择以pdf的方式阅读。从开发者的角度，MVC把应用程序的逻辑层与界面是完全分开的，最大的好处是：界面设计人员可以直接参与到界面开发，程序员就可以把精力放在逻辑层上。而不是像以前那样，设计人员把所有的材料交给开发人员，由开发人员来实现界面。在Eclipes工具中开发Android采用了更加简单的方法，设计人员在DroidDraw中设计界面，以XML方式保存，在Eclipes中直接打开就可以看到设计人员设计的界面。

Android中界面部分也采用了当前比较流行的MVC框架，在Android中：

1) 视图层（View）：

一般采用XML文件进行界面的描述，使用的时候可以非常方便的引入。当然，如何你对Android了解的比较的多了话，就一定可以想到在Android中也可以使用JavaScript+HTML等的方式作为View层，当然这里需要进行Java和JavaScript之间的通信，幸运的是，Android提供了它们之间非常方便的通信实现。

2) 控制层（Controller）：

Android的控制层的重任通常落在了众多的Acitvity的肩上，这句话也就暗含了不要在Acitivity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Acitivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。

3) 模型层（Model）：

对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。

在Android SDK中的数据绑定，也都是采用了与MVC框架类似的方法来显示数据。在控制层上将数据按照视图模型的要求（也就是Android SDK中的Adapter）封装就可以直接在视图模型上显示了，从而实现了数据绑定。比如显示Cursor中所有数据的ListActivity，其视图层就是一个ListView，将数据封装为ListAdapter，并传递给ListView，数据就在ListView中现实。

（二）MVP

M-Model-模型、V-View-视图、P-Presenter-表示器。

MPV 是从经典的MVC模式演变过来的，其基本思路都是相通的。其中M是model模型，提供业务数据；P和MVC中的C担当的角色相似，是Presenter控制者，进行逻辑处理。V是View视图，显示数据。MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。

二．两个框架模式的区别

MVC框架模式的处理关系：

MVP框架模式的处理关系：

其实最明显的区别就是，MVC中是允许Model和View进行交互的，而MVP中很明显，Model与View之间的交互由Presenter完成。还有一点就是Presenter与View之间的交互是通过接口的（代码中会体现)。

在MVC框架中，View是可以直接读取Model模型中的数据的，Model模型数据发生改变是会通知View数据显示发生相应的改变。而在MVP中Model和View之间的没有任何联系，是两个完全独立的模块，当Model模型发生数据改变时，通过Presenter通知View视图发生相应的UI改变。因此，个人觉得：MVP才是正真的视图和模型完全分离，也就是Model模型进行业务数据处理和View视图显示没有任何关联。

三、利用MVP进行Android开发的例子

现在我们来实现这样一个Android上的Demo(如图)：可以从EditText读取用户信息并存取，也可以根据ID来从后台读出用户信息并显示。



页面布局很简单，就不介绍了。下面根据MVP原则来进行编码：

先来看看java文件的目录结构：



可以发现，Presenter与Model、View都是通过接口来进行交互的，既降低耦合也方便进行单元测试。

(1)首先我们需要一个UserBean，用来保存用户信息

public class UserBean {
private String mFirstName ;
private String mLastName ;
public UserBean (String firstName, String lastName) {
this .mFirstName = firstName;
this .mLastName = lastName;
}
public String getFirstName() {
return mFirstName ;
}
public String getLastName() {
return mLastName ;
}
}

(2)再来看看View接口：

根据需求可知，View可以对ID、FirstName、LastName这三个EditText进行读操作，对FirstName和LastName进行写操作，由此定义IUserView接口：

public interface IUserView {
int getID();
String getFristName();
String getLastName();
void setFirstName (String firstName);
void setLastName (String lastName);
}

(3)Model接口：

同样，Model也需要对这三个字段进行读写操作，并存储在某个载体内(这不是我们所关心的，可以存在内存、文件、数据库或者远程服务器，但对于Presenter及View无影响),定义IUserModel接口：

public interface IUserModel {
void setID (int id);
void setFirstName (String firstName);
void setLastName (String lastName);
int getID();
UserBean load (int id);//通过id读取user信息,返回一个UserBean
}

(4)Presenter:

至此，Presenter就能通过接口与View及Model进行交互了：

public class UserPresenter {
private IUserView mUserView ;
private IUserModel mUserModel ;

public UserPresenter (IUserView view) {
mUserView = view;
mUserModel = new UserModel ();//多态的使用
}

public void saveUser( int id , String firstName , String lastName) {
mUserModel .setID (id );
mUserModel .setFirstName (firstName );
mUserModel .setLastName (lastName );
}

public void loadUser( int id ) {
UserBean user = mUserModel .load (id );
mUserrView .setFirstName (user .getFirstName ());//通过调用IUserView的方法来更新显示
mUserView .setLastName (user .getLastName ());
}
}

(5)UserActivity:

UserActivity实现了IUserView及View.OnClickListener接口，同时有一个UserPresenter成员变量：

public class UserActivity extends Activity implements OnClickListener ,
IUserView {

private EditText mFirstNameEditText , mLastNameEditText , mIdEditText ;
private Button mSaveButton , mLoadButton ;
private UserPresenter mUserPresenter ;
重写了OnClick方法：
@Override
public void onClick(View v) {
// TODO Auto-generated method stub
switch ( v. getId()) {
case R .id .saveButton :
mUserPresenter .saveUser (getID (), getFristName (),
getLastName ());
break ;
case R .id .loadButton :
mUserPresenter .loadUser (getID ());
break ;
default :
break ;
}
}

可以看到，View只负责处理与用户进行交互，并把数据相关的逻辑操作都扔给了Presenter去做。而Presenter调用Model处理完数据之后，再通过IUserView更新View显示的信息。

View剩下的方法及UserModel类不是我们所关心重点。UserModel类做数据的实际存储操作，可以是保存在数据库，也可以保存在本地文件，这个和界面完全没有关系。

定义接口能够非常清楚的看到我们创建的全部方法和需求，这个在大工程项目中是很有用的；并且定义好接口后，使用多态的方法来调用是非常方便的。

四.总结：

MVP框架模式完全将Model模型和View视图分离，从而使得代码的耦合性低，利用MVP框架写项目达到解耦作用。 MVP和MVC最大的区别是:MVC中的V可以从M中获取数据，而MVP中M和V完全分离，互相不知道对方的存在，Presenter通过接口通信方式将V和M通信。 在Android中MVP框架 Activity担当View视图层和MVC框架模式不一样Activity担当控制器。

(一)MVP模式的核心思想：

MVP把Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。

这就是MVP模式，现在这样的话，Activity的工作的简单了，只用来响应生命周期，其他工作都丢到Presenter中去完成。从上图可以看出，Presenter是Model和View之间的桥梁，为了让结构变得更加简单，View并不能直接对Model进行操作，这也是MVP与MVC最大的不同之处。

（二）MVP模式的作用

MVP的好处都有啥？

1.分离了视图逻辑和业务逻辑，降低了耦合

2.Activity只处理生命周期的任务，代码变得更加简洁

3.视图逻辑和业务逻辑分别抽象到了View和Presenter的接口中去，提高代码的可阅读性

4.Presenter被抽象成接口，可以有多种具体的实现，所以方便进行单元测试

5.把业务逻辑抽到Presenter中去，避免后台线程引用着Activity导致Activity的资源无法被系统回收从而引起内存泄露和OOM

（三）其中最重要的有三点：

Activity 代码变得更加简洁

相信很多人阅读代码的时候，都是从Activity开始的，对着一个1000+行代码的Activity，看了都觉得难受。

使用MVP之后，Activity就能瘦身许多了，基本上只有FindView、SetListener以及Init的代码。其他的就是对Presenter的调用，还有对View接口的实现。这种情形下阅读代码就容易多了，而且你只要看Presenter的接口，就能明白这个模块都有哪些业务，很快就能定位到具体代码。Activity变得容易看懂，容易维护，以后要调整业务、删减功能也就变得简单许多。

方便进行单元测试

一般单元测试都是用来测试某些新加的业务逻辑有没有问题，如果采用传统的代码风格（习惯性上叫做MV模式，少了P），我们可能要先在Activity里写一段测试代码，测试完了再把测试代码删掉换成正式代码，这时如果发现业务有问题又得换回测试代码，咦，测试代码已经删掉了！好吧重新写吧……

MVP中，由于业务逻辑都在Presenter里，我们完全可以写一个PresenterTest的实现类继承Presenter的接口，现在只要在Activity里把Presenter的创建换成PresenterTest，就能进行单元测试了，测试完再换回来即可。万一发现还得进行测试，那就再换成PresenterTest吧。

避免 Activity 的内存泄露

Android APP 发生OOM的最大原因就是出现内存泄露造成APP的内存不够用，而造成内存泄露的两大原因之一就是Activity泄露（Activity Leak）（另一个原因是Bitmap泄露（Bitmap Leak））。

采用传统的MV模式，一大堆异步任务和对UI的操作都放在Activity里面，比如你可能从网络下载一张图片，在下载成功的回调里把图片加载到 Activity 的 ImageView 里面，所以异步任务保留着对Activity的引用。这样一来，即使Activity已经被切换到后台（onDestroy已经执行），这些异步任务仍然保留着对Activity实例的引用，所以系统就无法回收这个Activity实例了，结果就是Activity Leak。Android的组件中，Activity对象往往是在堆（Java Heap）里占最多内存的，所以系统会优先回收Activity对象，如果有Activity Leak，APP很容易因为内存不够而OOM。

采用MVP模式，只要在当前的Activity的onDestroy里，分离异步任务对Activity的引用，就能避免 Activity Leak。