MVP4Peelson

一个自用解决内存泄漏问题的MVP模式框架

索引

Why

MVP模式广泛运用于Android项目开发实战之中，具有易于维护、易于测试、松耦合、复用性高等特点，但是当Presenter进行一些耗时操作时，由于其持有了View的强引用，如果在耗时操作之前此View层被销毁会导致Presenter一直持有View对象而View对象无法收回，此时就发生了内存泄漏。

而通常的解决办法是通过自己实现一个ActivityCollector来解决：


public class ActivityCollector {
    public static List<Activity> activities = new ArrayList<>();
    public static void addActivity(Activity activity) {
        activities.add(activity);
    }
    public static void removeActivity(Activity activity) {
        activities.remove(activity);
    }
    public static void finishAll() {
        for (Activity activity : activities) {
            if (!activity.isFinishing()) {
                activity.finish();
            }
        }
    }
}

在BaseActivity中可以手动：

public class BaseActivity extends AppCompatActivity {
    private static final String TAG = "BaseActivity";
    private ForceOffLineReceiver receiver;
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        ActivityCollector.addActivity(this);
    }
    @Override
    protected void onDestroy() {
        super.onDestroy();
        ActivityCollector.removeActivity(this);
    }
}

当然这个方法很蠢。

How

现在有一个全新的思路来解决这一问题。就是通过弱引用和Activity、Fragment的声明周期来解决这个问题。

首先建立一个Presenter抽象，命名为BasePresenter，它是一个泛型类，泛型类型为View角色需要实现的接口类型：

public abstract class BasePresenter<V> {
    protected Reference<V> mViewRef;
    //与View建立关系
    public void attachView(V view) {
        mViewRef = new WeakReference<V>(view);
    }
    //获取View
    protected V getView() {
        return mViewRef.get();
    }
    //判断是否与View建立了关系
    public boolean isViewAttached() {
        return mViewRef != null && mViewRef.get() != null;
    }
    //与View解除关系
    public void detachView() {
        if (mViewRef != null) {
            mViewRef.clear();
            mViewRef = null;
        }
    }
}

BasePresenter有4个方法，分别与View建立关联、解除关联、判断是否与View建立关联、获取View。View类型通过BasePresenter的泛型类型传递进来，Presenter对这个View持有弱引用。通常情况下这个View类型应该是实现了某个特定接口的Activity或者Fragment等类型。
然后就是利用BaseActivity基类来控制它与Presenter的关系。

public abstract class BaseActivity<V, P extends BasePresenter<V>> extends Activity {
    protected P mPresenter;
    private static final String TAG = "BaseActivity";
    public Context mContext;
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mContext = this;
        mPresenter = createPresenter();
        mPresenter.attachView((V) this);
        //ButterKnife.bind(this);
}
    @Override
    protected void onDestroy() {
        super.onDestroy();
        mPresenter.detachView();
    }
    protected abstract P createPresenter();
}

BaseActivity含有两个泛型参数，第一个是View接口类型，第二个是Presenter的具体类型。通过泛型参数，会使得一些通用的逻辑可以被抽象到BaseActivity类中。例如，在BaseActivity的onCreate函数中，会通过createPresenter函数创建一个具体的Presenter，这个Presenter的类型就是BasePresenter<V>类型。构建Presenter之后会调用attachView函数与Activity建立关联。而在onDestroy函数中会与Activity解除关联，从而避免内存泄漏。那么，如果在onDestroy中解除了对Activity的引用那么就没有必要再用弱引用了，其实，并不是在任何情况下Activity的onDestroy方法都会被调用，一旦这种情况发生，弱引用也会保证不会造成内存泄漏。而通过BaseActivity的封装维护Presenter与View关联关系的代码，使得子类可以避免重复的代码。

例如PhotoInListFragment的代码实现如下：

public class PhotoInListFragment extends BaseFragment<PhotoInfoContract.View<PhotoInfo>,PhotoInfoPresenter> implements PhotoInfoContract.View<PhotoInfo>,PhotoInfoContract.RefreshPhotoInfoListener{
    private String param;
    public PhotoInListFragment(){}
    public static PhotoInListFragment newInstance(String param){
        PhotoInListFragment fragment=new PhotoInListFragment();
        Bundle args = new Bundle();
        args.putString("param", param);
        fragment.setArguments(args);
        return fragment;
    }
    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        if(getArguments()!=null){
            param=getArguments().getString("param");
        }
        super.onCreate(savedInstanceState);
    }
    @Nullable
    @Override
    public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, Bundle savedInstanceState) {
        View v=inflater.inflate(R.layout.fragment_photoinfoinlist,container,false);
        initView(v);
        return v;
    }
    private void initView(View v) {
    }
    @Override
    public void refreshPhotoInfoList(ArrayList<PhotoInfo> photoInfoList) {
    }
    @Override
    protected PhotoInfoPresenter createPresenter() {
        return new PhotoInfoPresenter(param,this);
    }
    @Override
    public void onPhotoInfoRefresh() {
    }
}

此时，Presenter的创建以及与View建立关联等操作都被封装到BaseFragment中，清除了子类重复代码同时又避免了Fragment（View）内存泄漏问题。

基于此实例请参Demo。
如有问题请在Issues中提出，或者与我联系。

参考

《Android源码设计模式实战与解析（第2版）》