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框架模式的处理关系:

Android开发框架模式MVC、MVP使用总结_第1张图片

MVP框架模式的处理关系:

Android开发框架模式MVC、MVP使用总结_第2张图片

       其实最明显的区别就是,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来从后台读出用户信息并显示。
Android开发框架模式MVC、MVP使用总结_第3张图片
       页面布局很简单,就不介绍了。下面根据MVP原则来进行编码:
先来看看java文件的目录结构:
Android开发框架模式MVC、MVP使用总结_第4张图片
       可以发现,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。

你可能感兴趣的:(android,框架模式)