这是第二篇的优化篇，原文地址：http://mp.weixin.qq.com/s/z0mx1tXWf_rDhrWQ2BbW8g
第二篇是一个简单的MVP实例，但是在我们的真实工作中项目往往是很大的，为了减少代码量我们必须要做抽取，这篇优化篇就是在上一篇的基础上进行了基类的抽取，解决了当Activity销毁后，Presenter还持有Activity造成的内存泄漏的问题。还有泛型的运用。话不多说，直接上图。
分包：
Model和上一篇一样，是运用接口回调模拟请求数据：
核心就是那个接口回调，要记住一个核心 -- 接口或者抽象类这类不能实例化的一定要看它的实现类！
View层
在真实项目中我们肯定会有很多的界面，加入我们有很多请求网络的界面，当然每一种这类界面都会有显示和隐藏ProgressBar的逻辑，我们就有必要将这两个方法抽取出来：
然后就是我们相对具体的UI效果了，在这里我们选中的是弹吐司和显示ListView：
接口是可以继承另一个接口的，这样它也拥有父类接口的方法，接口还是可以多继承的，http://www.jianshu.com/p/36b11055c299可以参考我篇文章。
因为Activity界面需要绑定Presenter，所以我们先分析Presenter然后再分析Activity。
Presenter层
往往Presenter层也是有一些共有的逻辑的，这样我们就可以抽取出来，这里我们考虑的事每一个Activity都有相应的生命周期，我们将Activity创建的时候和Presenter关联起来，在Activity销毁的时候将Presenter持有的Activity置为null。
你可能对那个泛型有疑问，泛型一般是为了限制创建对象时传递的参数的，但是这里更多的是一个类似一个抽象的概念，正如我注释掉的那些成员一样，我可能是IView接口，也有可能是其他接口，为了让BasePresenter能适用于任何View就加入了泛型。注意我们这里是抽象的类，而不是接口，我们在MVP中会用到很多接口，不要混淆了，其实抽象类和接口也很好分辨，接口是没有方法体的，它只能定义一个抽象的方法，而抽象类是有具体的方法体的，可以在里面进行逻辑处理，它只是和接口一样不能被实例化，继承抽象类的子类是可以继承抽象类的方法的。
接下来创建一个Presenter来继承这个抽象的BasePresenter。
这里传入的泛型是IView，就代表实现了IView接口的类有了BasePre中的两个方法。我们会在IView的实现类相应的生命周期方法中调用这个两个方法。
View层
分析完Presenter就下来就是界面的调用了，每一个Activity都有相应的生命周期，我们需要在每一个onResume（）中去关联Presenter；为了避免内存泄漏又要在onDestory（）中将View置为null。所以我们有必要将这两个方法抽取出来。
注意我们是继承了AppCompatActvity，拥有了Activity的所有生命周期，我们只要重写onResume（）和onDestory（）即可。
这里同样用到了泛型，上面我们也说了这里的泛型更多的是一个抽象的概念，是为了有更好的扩展性。可以适用于任何的Presenter和View，注意调用Presenter或者View中的方法时，一定要先实例化，具体的实例化可以交给子类去实现。
最后就只要在Activity实例化相应的对象和调用相应的方法就可以了，注意我们的内存优化已经在 BaseActivity中完成。
这个例子中运用了继承和泛型的，是一个很不错的例子。多敲几遍相信很让你收获很多。Just have a code！
