MVP2
在上篇文章中，我写了一种比较常见的MVP模式的实现方式，它有许多优点，也比较方便后期的维护与优化。
但是：
从另一个角度来说, activity 有一个很复杂的生命周期(fragment的生命周期可能会更复杂), 而这些生命周期很有可能对你项目的业务逻辑有非常重大的影响. Activity 可以获取上下文环境和多种android系统服务. Activity中发送Intent，启动Service和执行FragmentTransisitons等。而这些特性在我看来绝不应该是视图层应该涉及的领域(视图的功能就是现实数据和从用户那里获取输入数据，在理想的情况下，视图应该避免业务逻辑).
这也是我一直比较困惑的一点，如果Activity/Fragment作为视图（View）层的话，那关于Service的绑定与启动，BrocastReceiver的注册与注销该如何处理呢？
本文参考来源
这篇文章的作者尝试使用Activity/Fragment作为Presenter。
其他
（1）在常规的MVP实现模式下，前一种方式是通过接口的方式在View与Presenter之间解耦，也可以在Presenter中持有View（Activity）的引用，需要注意的就是在onDestroy()取消引用，防止内存泄露的发生。
参考文章2
（2）MVVM
MVP
MVVM
