老生常谈MVP架构

原生框架问题

由于原生 Android 开发应该已经是一个基础的 MVC 框架，所以在初始开发的时候并没有遇到太多框架上的问题，可是一旦项目规模到了一定的程度，就需要对整个项目的代码结构做一个总体上的规划，最终的目的是使代码可读，维护性好，方便测试。

只有项目复杂度到了一定程度才需要使用一些更灵活的框架或者结构，简单来说，写个 Hello World 并不需要任何第三方的框架

原生的 MVC 框架遇到大规模的应用，就会变得代码难读，不好维护，无法测试的囧境。因此，Android 开发方面也有很多对应的框架来解决这些问题。

构建框架的最终目的是增强项目代码的可读性 ，维护性 和方便测试 ，如果背离了这个初衷，为了使用而使用，最终是得不偿失的

从根本上来讲，要解决上述的三个问题，核心思想无非两种：一个是分层 ，一个是模块化 。两个方法最终要实现的就是解耦，分层讲的是纵向层面上的解耦，模块化则是横向上的解耦。

对于经典的 Android MVC 框架来说，如果只是简单的应用，业务逻辑写到 Activity 下面并无太多问题，但一旦业务逐渐变得复杂起来，每个页面之间有不同的数据交互和业务交流时，activity 的代码就会急剧膨胀，代码就会变得可读性，维护性很差。

MVP好处

（1）MVP模式会解除View与Model的耦合，有效的降低View的复杂性。同时又带来了良好的可扩展性、可测试性，保证系统的整洁性和灵活性。

（2）MVP模式可以分离显示层与逻辑层，它们之间通过接口进行通信，降低耦合。理想化的MVP模式可以实现同一份逻辑代码搭配不同的显示界面，因为它们之间并不依赖与具体，而是依赖于抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI，使之具有更广泛的适用性，保证了灵活度。

MVP角色划分

（1）Presenter – 交互中间人：Presenter主要作为沟通View与Model的桥梁，它从Model层检索数据后，返回给View层，使得View与Model之间没有耦合，也将业务逻辑从View角色上抽离出来。

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

（3）Model – 数据的存取：Model 角色主要是提供数据的存取功能。Presenter 需要通过Model层存储、获取数据，Model就像一个数据仓库。更直白的说，Model是封装了数据库DAO或者网络获取数据的角色，或者两种数据方式获取的集合。

MVC与MVP对比

示例类图分析

MVP进阶

生命周期管理

presenter持有view对象，退出时销毁
弱引用对象处理
使用Lifecycle处理生命周期

Model层处理

android-architecture中model层设计

我们升级一下model层，Repository作为数据逻辑层，可以在该类通过逻辑和算法控制数据来源，其中包含了一个cache内存缓存对象，Local data source顾名思义是本地数据源，关联本地数据库。Remote data source则是远程数据源，用于网络请求。

android-boilerplate 中model层的设计

android-boilerplate也是一个基于MVP架构的框架，加入EventBus(Otto)，RxJava,Retrofit，SqlBrite等。其中的model层有很多值得借鉴的地方。这里再从这整个架构图来学习一下相应的思路。

参考

https://github.com/googlesamples/android-architecture

https://github.com/ribot/android-boilerplate

https://developer.android.com/topic/libraries/architecture/guide.html