曾露

摘要：传统的MVC模式在Android的应用开发中存在诸多不足，主要表现在Android应用开发的关键类Activity会充当Controller和View的合体，既要负责业务逻辑，又要负责显示，造成Activity的职责过多，耦合度高。MVP模式是MVC模式演进而来，引入了Presenter彻底分离Model和View层，在解决Activity臃肿的问题同时，还有助于后期的测试与维护。本文分析MVC对于Android开发的不足，并探索MVP模式在Android开发中的可行性，以及优劣势，最后实现MVP模式在Android开发中的应用。

关键词：Android；MVP；模式

引言

GUI（Graphical User Interface）应用程序出现之后，应用程序也变得更加复杂，为了管理这种复杂性，基于职责分离的思想而孕育而出了MVC模式。在Android开发过程中，同样会采用MVC模式的思想，将访问和数据的表现分离。一般的处理是将进行界面描述的XML文件作为视图层（View），使用的时候可以非常方便的引入，同时便于后期界面的修改。将Activity等类作为控制层（Controller），来控制View层和Model层的通信，以此来达到分离视图显示和业务逻辑层，其中与业务相关的数据结构类作为模型层（Model），用来处理数据库的操作、网络请求等操作。但其实Activity并不是一个标准的MVC模式中的Controller，它的首要职责是加载应用的布局和初始界面，以及接受并处理来自用户的操作请求，并做出响应。随着界面及其逻辑的复杂度不断提升，Activity类的职责不断增加，以致变得庞大臃肿。不仅如此，在Android中，允许View和其它线程共存于Activity内，造成的问题是Activity中同时存在业务逻辑和UI逻辑，成为包罗万象的“上帝类”，这大大增加了应用后期的测试和维护成本。为了使Android应用开发简单，各层次职责清晰，增加可读性和复用性，减少后期的测试、维护成本，本文在Android开发应用中引人MVP模式。

1 MVP模式

MVP从MVC演变而来，通过表示器将视图与模型巧妙地分开。在该模式中，视图通常由表示器初始化，它呈现用户界面（UI）并接受用户所发出命令，但不对用户的输入作任何逻辑处理，而仅仅是将用户输入转发给表示器。通常每一个视图对应一个表示器，但是也可能一个拥有较复杂业务逻辑的视图会对应多个表示器，每个表示器完成该视图的一部分业务处理工作，降低了单个表示器的复杂程度，一个表示器也能被多个有着相同业务需求的视图复用，增加单个表示器的复用度。表示器包含大多数表示逻辑，用以处理视图，与模型交互以获取或更新数据等。模型描述了系统的处理逻辑，模型对于表示器和视图一无所知。

1.1MVP模式的引入

在Android开发应用中，MVP的结构划分：视图（View）负责绘制uI元素、与用户交互，在Android开发中对应于Activity相关的类；模型（Model）类似于数据加工处理厂，负责对数据的获取，数据的解析，数据的存储，数据的分发，数据的增删改查等操作；表示器（Presenter）作为View与Model交互的中间纽带，处于MVP的中间层，表示器会把视图递交的命令进行一定的校验等操作，然后交给模型层处理，模型层处理完数据之后，会通知表示器，表示器主动去获取数据处理的结果递交给视图层显示。因此表示器有封装业务，更新UI界面和持有线程等功能。各模块数据的交互见图1。

从上图可以看出，MVP的分层结构特别类似于网络的七层协议，每层只知道自己依赖层的细节。层与层之间的耦合性低，模块的复用性高，可维护性高，降低了测试的复杂度。

按照View和Presenter的交互方式和View本身的职责，可以将MVP划分为PV（PassiveView）和SoC（Superviding Controller）。其中PV中的View是被动的，由Presenter来推送和获取数据，这也是普遍的用法，本文研究的MVP模式也属此种模式。MVP模式的变种Passive View中各模块的依赖关系如图2所示。

在被动视图（passive View）模式中，表示器通过接口与视图交互。采用这种方案可以使表示器自身成为一个可重用性和可测试性均很高的类。首先，表示逻辑独立于所使用的UI技术，其次，针对某一接口为表示器编码，该表示器可以与实现该接口的任何对象交互，而实现该接口的可能是Activity对象、Fragment对象等，这意味着只要视图接口不变，视图的任何更新都不会影响到表示器。这就能使单个表示器只专注于它自己的职责，使得表示器层结构简单，逻辑清晰，符合面向对象的单一职责原则，当程序需要修改时，大大降低了修改的成本。再者，同一表示器可以处理同一应用程序的不同视图。最后，如果将应用逻辑混合于UI代码中，由于应用程序中的UI代码非常难以自动测试，从而导致整个应用的难以测试。因此，从UI分离出视图接口，将UI中的逻辑从视图中移除，通过模仿视图对象，可以方便地测试表示器。因此，表示器层是作为MVP体系的控制中心，而视图仅仅是用户交互请求的汇报者，不维护数据的状态。表示器直接依赖View的接口。

1.2MVP模式的优缺点

MVP与MVC的主要区别是View与Model不直接交互，而是通过与Presenter来完成交互，这样可以修改视图而不影响模型，达到解耦的目的，实现了Model和View真正的完全分离。视图的变化总是比较频繁，将业务逻辑抽取出来，放在表示器中实现，使模块职责划分明显，层次清晰，一个表示器能复用于多个视图，而不需要更改表示器的逻辑（当然是在该视图的改动不影响业务逻辑的前提下），这增加了程序的复用性。数据的处理由模型层完成，隐藏了数据，在数据显示时，表示器可以对数据进行访问控制，提高数据的安全性。以前的Android开发是难以进行单元测试的，但是随着项目变得复杂，测试时保证应用质量的关键，MVP模式中，表示器对视图是通过接口进行的，可以利用测试驱动，模拟出视图对象，实现视图相对于表示器的接口，就可以对表示层进行不依赖于UI环境的单元测试了，这大大降低了Android应用开发中的业务逻辑测试难度和复杂度。MVP模式的引人，视图层完全不依赖与模型层，相当于将视图从特定的业务场景中脱离出来，做到了对业务完全不可知的状态，因此可以将视图层组件化，提供一系列接口供表示层操作，这样就可以做出高度可复用的视图组件了。

MVP的明显缺点是增加了代码的复杂度，特别是针对小型Android应用的开发，会使程序冗余。Presenter中除了应用逻辑以外，还有大量的View->Model，Model->View的手动同步逻辑，会导致Presenter臃肿，维护困难。视图的渲染过程也会放在Presenter中，造成视图与Presenter交互过于频繁，如果某特定视图的渲染很多，就会造成Presenter与该视图联系过于紧密，一旦该视图需要变更，那么Presenter也需要变更了，不能如预期的那样降低耦合度和增加复用性。

2MVP模式的应用

2.1MVP模式中的模型

模型从黑盒的角度来说就是输入/输出数据。模型在Android应用中，主要负责从网络，数据库，文件，传感器，第三方等数据源读写数据，以及对外部的数据类型进行解析，转换为应用程序内部数据，并交由上层处理，还对数据进行临时存储和管理，协调上层数据请求。

对于不同的数据处理，一般的，建立一个单例，进行数据的初始、设置、检查以及处理。

public interface IManager{

void onAppCreate（）；//应用创建时

void set（）；//提供数据

void handle（）；//处理数据

void check（）；//数据检查

}

在模型层中，会存在大量的实体，用于提供数据的存储方式，如下所示：

public abstract class Entity{

private String mid；

public String getld（）{

return mid；

}

protected abstract void setld（String id）；

}

2.2 MVP模式中的视图

前文提到，视图层主要负责UI交互，在表示器的控制下修改UI，将业务事件交由表示器处理，不存储数据，也不与模型层交互。视图层与表示器的任何交互都必须通过视图接口进行，用户的任何命令都必须转发到表示器，并由其进行处理，因此要为每个视图定义接口。

IView接口是每个视图需要实现的接口，表示器通过此接口控制View，代码如下所示：

publicinterfaceIView{

void initViews（）；//初始视图

}

在Android应用中，用来显示页面的类一般是Activity、fragment等，这些类在使用时都需要继承上述的接口，且需要依赖表示器，见BaseActivity所示：

public abstract class BaseActivity extends Frag-mentActivity{

private SetmAllPresenters；//一个activity有可能有多个IPresenter

protected abstract int getLayoutResld（）；//获取layout的id

protected abstract void onlnitPresenters（）；//初始化presenters

Protected abstract void parseArgumentsFromln-tent（Intent argIntent）；//从intent中解析数据

@Override

protected void

onCreate（Bundle savedln-stanceState）{

super.onCreate（savedlnstanceState）；

//周期onCreate

}

//…其他生命周期方法也是类似，调用IPresenter中相应的生命周期方法…

}

2.3 MVP模式中的表示器

表示器起到连接视图与模型的桥梁作用，视图中的控件将捕获任何用户操作并触发视图中的事件，例如按钮单击或索引选择更改事件，视图会直接向表示器递交获捕获的数据，交由表示器层处理。

表示器通常通过其初始函数接收对视图的引用。视图保留对表示器的引用，表示器保留对视图接口的引用，表示器不依赖于具体的视图对象。

首先将IView和IPresenter组合在一块，建立IContract接口。

public interface IContract{

mtertace lConcreteView extends lVlew{

//具体view的UI操作

}

interface IConcretePresenter extends IPre-senter{

//Presenter所需要处理的业务逻辑

}

}

表示器的初始函数接收并保存对视图的引用，使用约定所表示的公共接口初始化视图。表示器类还包含大量方法，执行这些方法可响应来自UI的任何请求，任何单击或用户操作都与表示器类的方法绑定。表示器的接口还提供了对应于Activity或Fragment的生命周期的方法，这是为了根据视图生命周期的不同提供相应的逻辑业务。如下所示：

public interface IPresenter{

void onStop（）；

void onResume（）；

void onDestroy（）；

void onPause（）；

void onStart（）；

void init（V view）；

}

3总结

在Android应用开发过程中，MVC框架并不能很好的契合Android的开发架构，因此本文采用MVP的模式开发Android应用，介绍了MVP模式应用于Android开发的可行性，同时通过编程，实现了MVP应用于Android开发的思想。具体在应用的过程中，还有很多许多细节需要注意，例如模型层对于复杂的数据处理，还需要根据不同的数据源、不同的业务请求而进行细分等。