Android学习笔记MVP模式框架

Android学习笔记MVP模式框架

1.MVP模式介绍：
在上一次学习中，我简单的介绍了MVC构架，这次我来简单的介绍下什么是MVP。对于MVP，他其实就是MVC的一个演化版本，MVP全称Model View Presenter。目前MVP在android应用开发中越来越重要了，相信不少的开发者也在各种讨论关于MVP的理论了。那么这个MVP模式他到底有哪些应用的好处呢？首先MVP能够有效的降低View的复杂性，避免业务逻辑被塞进View中，使得View代码优化了不少。MVP模式会解除View与Model的耦合，同时又带来了良好的可扩展性、可测试性，保证了系统的整洁性、灵活性。可能对于简单的应用，你会觉得MVP会稍微显得有点麻烦，因为他提出了各种各样的接口概念，是的整个应用充斥着零散的接口，但是对于比较复杂的应用来说，MVP模式是一种良好的构架模式，它能够非常好的组织应用结构，使得应用变得灵活
　
　
2. MVP简单结构图：

从上图可以看出，MVP模式很好的分离显示层和逻辑层，他们之间通过接口进行通信，降低耦合。理想化的MVP模式可以实现同一份逻辑代码搭配不同的显示界面，因为他们之间并不依赖于具体，而是依赖与抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI，使之具有更广泛的使用性，保证了灵活度。
　
3. MVP模式的三个角色：

3.1 Presenter——交互中间人

Presenter主要作为沟通View和Model的桥梁，它从Model层检索数据后，返回给View层，是的View
和Model直接没有耦合，也将业务逻辑从View角色上抽离出来，相比MVC模式，就很好的减少了View
中的逻辑实现代码。

　
3.2 View——用户界面

View通常是指Activity、Fragment或者某个View控件，它含有一个Presenter成员变量。通常View需要
实现一个逻辑接口，将View上的操作通过会转交给Presenter进行实现，最后，Presenter调用View逻辑
接口将结果返回给View元素。
　
　

3.3 Model——数据的存储

对于一个结构化的App来说，Model角色主要是提供数据的存取功能。Presenter需要通过Model层存
储、获取数据，Model就像一个数据仓库。更直白地说，Model是封装了数据库Dao或者网络获取数据的
角色，或者两种数据获取方式的集合。

　
4. MVP的代码实现：

关于具体的实现我就不在这里重复写了，有想了解的大家可以参考我的这些MVP模式框架的代码：

Android-缓存网络图片（MVP模式）学习笔记

Android之SqliteDatabase（MVP模式）实现用户登录注册功能

Android MVP模式 解析JSON 显示到ListView上

　
5. 关于MVP与Activity、Fragment的生命周期：

综合上面的代码，我们可以很清除的知道，MVP有很多有点，例如易于维护、易于测试、松耦合、复用性高、健壮稳定、易于扩展，但是，由于Presenter经常性地执行一些耗时操作，例如，我们上述的缓存网络请求网络图片。由于Presenter持有了MainActity的强引用，如果在请求结束之前Activity被销毁了，那么由于网络请求还没有返回，导致Presenter一直持有MainActivity对象，是的MainActivity对象无法被回收，此时就会发生内存泄露。那么对于这种问题如何解决呢？答案是可以通过弱引用和Activity、Fragment的生命周期来解决这个问题。首先建立一个Presenter抽象类，我们把它命名为BaseAdapter，他是一个泛型类，泛型类类型为View角色要实现的接口类型。具体代码如下。

BasePresenter.java

public class BasePresenter {

    protected WeakReference weakReference;//View接口类型的弱引用

    public void attach(V t){
        weakReference = new WeakReference<>(t);//每次将需要关联的View接口类型的类与其建立联系
    }

    public void deAttach(){//如果Activity、Fragment等View控件销毁时调用该方法，解除他们之间的关联
        if(weakReference != null){
            weakReference.clear();
            weakReference = null;
        }
    }
    public boolean isViewAttached(){
        return weakReference != null && weakReference.get() != null;
    }
    public V getView(){
        if(weakReference != null){
            return weakReference.get();
        }
        return  null;
    }

以上的四个方法，分别是建立关联、解除关联、判断是否与View建立了关联、获取View。View类型通过Presenter的泛型类型传递过来，Presenter对这个View持有弱引用。通常情况下这个View类型应该是实现了某个特定接口的Activity或者Fragment等类型。接下来还需要创建一个BaseActivity基类，通过这个基类的生命周期方法来控制它与Presenter的关系。相关代码如下。

BaseActivity.java

public abstract class BaseActivity<V extends ViewInter,T extends BasePresenter> extends AppCompatActivity {

    protected T basePresenter;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        basePresenter = getBasePresenter();
        basePresenter.attach((V)this);
    }

    public abstract T getBasePresenter();

    @Override
    protected void onDestroy() {
        basePresenter.deAttach();
        super.onDestroy();
    }
}

BaseActivity含有两个泛型参数，第一个是View接口类型，第二个是Presenter的具体类型。通过泛型参数，使得一些通用的逻辑可以被抽象到BaseActivity类中。下面看看具体要使用的MainActivity类的实现。

MainActivity.java

//主界面启动，展示数据等。
public class MainActivity extends BaseActivity<MainActivity,Presenter> implements ViewInter<Bean.NewslistBean> {

    private String path = "http://apis.baidu.com/txapi/mvtp/meinv?num=10";
    private GridView mGrid;
    private MyAdapter adapter;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        init();
        basePresenter.load(path);
    }

    private void init() {
        mGrid = (GridView) findViewById(R.id.mGrid);
    }

    @Override
    public Presenter getBasePresenter() {
        return new Presenter();
    }

    private void showListData(List data) {
        if (adapter == null) {
            adapter = new MyAdapter(data, R.layout.list_item);
            mGrid.setAdapter(adapter);
        } else {

        }
    }
    //通过presenter代理类为我们提供数据
    @Override
    public void getAdapterData(List data) {
        showListData(data);
    }
}

通过上面的代码，大家可以看出，在BaseActivity中的onCreate方法中，会通过getBasePresenter方法创建一个具体的Presenter，这个Presenter的类型就是BasePresenter类型。构建Presenter之后调用attach方法与Activity建立关联。而在onDestory方法中，则会与Activity解除关联，从而避免内存泄露。有些人可能会问，如果在onDestory中解除了对Activity的引用，那么就没有必要再用弱引用了。对于这个问题的答案是，并不是在任何情况下Activity的onDestroy都会被调用，一旦这种情况发生，弱引用也能够保证不会造成内存泄露。而通过BaseActivity的封装维护Presenter与View关联关系的代码，使得子类可以避免重复的代码，上面的代码正是如此。Presenter的创建以及View建立关联等操作都被封装到BaseActivity中，消除了子类重复代码的同时又避免了Activity的内存泄露问题。所以，在以后的设计中，你都可以为Activity、Fragment等类型都建立一个类似这样的基类，这样一来你就可以将这种思想运用到更广阔的范围了。

最后，从整体效果来说，MVP是开发过程中非常值得推荐的构架模式，他能够将各组件进行解偶，并且带来了良好的扩展性、可测试性、稳定性、可维护性，同时使得每个类型的职责相对单一、简单，便面了大量的“胖”程序存在，例如数千行的Activity类。他有效的业务逻辑、数据处理等工作从Activity等View元素中抽离出来，使得每个类尽可能简单，同时每个模块能够独立进行演化。它的思想也非常好的体现了面向对象的设计原则。