安卓MVP浅析及Presenter的生命周期问题

现在来说,mvp不算是个新鲜的东西了,很多了都开始练手或者已经用到项目去了

对于mvvm,databinding框架,用了下,发现很多问题,代码写起来也不友好,暂时不考虑

m : model 模型.

很多人理解成bean对象,我觉得不全是, 用获取数据比较贴切.

在以前写mvc的时候,我习惯抽成initData()来表示modle.

public interface Model {

  Bean load(String url,params)

}

modle,我推荐用retrofit2+rxjava来写,完全适用啊,对比一看,是不是感觉几乎没区别?

传送门:retrofit2+rxjava

v:view视图

在mvp中,有人把activity/fragment理解成presenter,

我觉得还是理解成v好一点,

比较纠结是,activity有生命周期,怎么就是单纯的v呢.

但如果理解成presenter的话,那么和mvc区别就不大了吧.

具体使用:
1.写一个view接口

public interface View {

 //抽取相对的activity里面的各种行为

//如:

 void show();

 void bindData(Bean b);

}

2,activity实现这个设计好的view接口

public class MainActivity extends Activity implements View{

Presenter presenter;

@Override

 protected voidonCreate(Bundle savedInstanceState) {

           super.onCreate(savedInstanceState); 

           setContentView(R.layout.activity_main);

          presenter = new Presenter(this);

}

 public void show(){

 }

 public void bindData(Bean b){

      ........

     //等待数据,设置view.

 }

}

3,实现每个行为的逻辑:对某个控件做什么事.

public void show(){

//具体操作.比如弹个toast啥的,设置某个控件啥的

}

4.持有presenter

这里有点难理解,持有presenter是什么意思?

我们不管做什么操作,都是一次事件

而这个事件由谁接收,当然是activity接收了.

如果activity不持有presenter,怎么告诉presenter,我需要获得数据.

对于view的功能设计

想好这个界面有哪些操作了.这个也不是很难,

拿着效果图,分析一下就出来了,

比如textview设置个内容啊,点击事件啊,选中啊,button弹出对话框啊

就拿TextView来说吧,Textview这个控件是不是有settext(),setColor().setTextsize()…..方法.

在mvp模式里面,我们把activity理解成View,假设Activity里面有settext(),setColor().setTextsize()方法

我们写这个view接口就相当于把这些方法从Activity抽取出来,

这个接口和Activity写好了一般是不需要改的,除非界面大改.那没办法,只能两边一起改了

因为xml都改了,控件啥的都改了,对应的Activity和view接口能不改么.

不过由于分离开了,改起来也简单.因为没有逻辑操作.

p:控制 presenter

一般写法:

public interface Presenter {

   void loadData();

}

public interface PresenterImpl implements Presenter {

 View v;

 public PresenterImpl(View v){

      this.v = v;

}

publc void loadData(){    

     Modler  modle   =    new  Modle();//创建modle

     Bean  bean =  modle.load("url",params);//获得数据 

     v.bindData(bean);//数据绑定view

}

}

既然view关心本身有哪些行为,那么p就是控制view了

通过事件触发,presenter去连接model获得数据,然后将model与view绑定,

也可以只是调用view的单个或多个操作.

结构图:

总结:

presenter和view相互持有调用,presenter可以同时操作Modle和View,但是Modle和View之间不能调用.

mvc的纠结的地方就是,其实只有mv,没有c,因为c和v是几乎是一个东西,activity/fragment嘛.

很多时候除了bean,mvc其实整个都在Activity里面- -

Presenter生命周期

这个问题很揪心,我想很多人懵逼的地方就在这

举个例子:

Presenter控制逻辑,也就是控制网络操作,绑定数据,一系列逻辑都在这.

那么,当activity关闭以后,Presenter怎么处理网络请求,异步操作呢?

比如上面的loadData(),如果acitivity已经关闭了,而网络操作又没走完.

就会内存泄漏.会不会空指针不好说.

view虽然持有p,但是也不能在Activity的onDestroy里面直接的将p=null吧

对象=null也只是断开引用而已,还并不是真的释放.

这样没用的,而且p还持有view呢,异步也不会因此结束,

所以得有个接口告诉p,我要挂了,你也自杀吧.

所以:

interface BasePresenter {

  void onStart();

   void onDestroy();

}

让所有的Presenter都继承BasePresenter,然后在activity中相应的生命周期里面调用

在相应的方法里面,初始化,结束异步操作,释放资源,将view=null;

而在activity里面,由于Presenter并没有view的引用了,

所以p随着activity的销毁也就跟着销毁了.不会造成上下文的泄漏等.

mvp的优点:

1.真正用起来,会发现模块很清晰,

2.解耦,模块清晰,耦合度自然就低了,但是耦合度低不代表改起来就很方便,哈哈

需求改动大的话,其实改起来还是麻烦,不过比起在上千行的activity里面改代码,还是舒服很多的,

比较推荐的写法:

public class Contract {

public interface View {

    void show();

    void bindData();

}

public interface Presenter extends BasePresenter{

     void loadData();

}

public interface Model {

  void load(String url,params)

}

用一个Contract集中对应acitivity的所有mvp用到的接口,

所有功能一目了然,改起来也方便.

如果改需求,肯定先改接口,再去改实现类嘛.

android studio 已经有mvpHelper插件,可以很方便生成的mvp的接口类以及实现类.

mvp的缺点:

类会非常多,每一个acitivity或者fragment要对应1个或者多个Presenter,真的很多

小项目费力,有时不如mvc方便,界面如果非常简单,用mvp反而显得繁琐了.

---

写个文章做个笔记,哈哈.