android设计模式之mvp详解

1，mvp模式介绍
mvp全称model，view，presenter，目前mvp在 android应用开发中越来越屌，大家对mvp模式讨论也越来越多，如果做了n年开发以后你还是简单的调用api，简单的堆代码，就太丢丢了，mvp能够有效的降低view的复杂性，避免业务逻辑被塞进view，使得view变成一个混乱的大泥坑，mvp模式会解除view和model的耦合，同时又带来良好的扩展性，可测试性，保证了系统的整洁性，灵活性，可能对于简单的app来说mvp稍显麻烦，各种各样的接口和概念，使得整个app充满着零散的接口，但是对于比较复杂的app来说，mvp模式是一种良好的架构模式，她能够非常好的组织app架构，让app变得灵活！
mvp模式可以分离显示层和逻辑层，他们之间通过接口进行通信，降低耦合，理想化的mvp模式可以实现统一分逻辑代码搭配不同的显示界面，因为他们之间并不依赖具体，而是依赖抽象，这使得presenter可以运用于任何实现了view接口的ui，使之具有更广泛的适用性，保证了灵活性！
我们知道在android上，业务逻辑和数据存取是紧耦合的，很多菜鸟很可能会将各种各样的业务逻辑塞进某个Activiy，Fragment或者自定义的view中，使得这些组件单个类型相当臃肿，其中又含有一些异步任务，导致某个类超过千行代码，当然，对于功能复杂的app来说，一个类超过千行代码并不是大惊小怪的事，我们所要指出的重点是业务逻辑与view元素严重耦合导致了类型膨胀的问题！
对于一个可扩展，稳定的app来说，我们需要定义分离各个层，主要是ui层，业务逻辑层和数据层，毕竟做产品的，pm随时会脑洞大开，不知道会加入什么逻辑，是从本地检索获取数据？还是远程获取？我们的ui，数据库是否会被替换，例如：随着app的升级，我们的ui可能会被重新设计，若UI发生了变化，此时由于业务逻辑耦合在view中，ui变化导致我们修改新的view控件，此时你就需要到原来的view中抽离具体的业务逻辑，这将是一件非常非常痛苦又蛋疼的事情！到最终你还是需要将业务逻辑抽离开来
mvp模式可以让ui界面和数据分离，我们的app至少分为3层，这样使得我们也可以对这三层进行独立的单元测试（这里吐槽一下，国内很少有单元测试），mvp模式可以让我们从activity，fragment等view角色中分离大部分代码，使得每个类型的代码量大幅度减少，职责单一，易于维护
mvp并不是一个标准化的模式，它可以很多实现方式，我们也可以根据自己的需求和自己认为对的方式去修正mvp的实现方式，它可以随着presenter的复杂程度变化，只要保证我们是通过presenter将view和model解耦合，降低类型的复杂度，各个模块可以独立测试，独立变化，这就是正确的方向，在android开发中，大多数人可能会把activity，fragment作为view角色来看待，因为他的职责是加载并处理一些简单的与view相关的逻辑，她组织与管理view集合，我们可以把他看成是粗粒度的view，当然你也可以把他们看成presenter！

2，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——数据的存取
对于一个结构化的app来说，model角色主要是提供数据的存取功能，presenter需要通过model层存取，model就像是一个数据仓库，更直白的说，model是封装了数据库dao或者网络获取数据的角色，或者两种数据获取方式的集合
3，与mvc，mvvm的区别
三种交互图如下



1，mvc特点
（1） 用户可以向view发送指令，再由view直接要求model改变状态
（2） 用户也可以直接向controller发送指令，再由controller发送给view
（3） controller起到事件路由的作用，同时业务逻辑全部部署在controller
可以看出mvc的耦合性还是相对较高，view可以直接访问model，导致3者 之间构成回路，因此，mvp和mvc的主要区别是，mvp中的view不能直接访问model需要通过presenter发出请求，view和model不能直接通信
2，mvvm特点
mvvm与mvp非常相似，唯一的区别是view和model进行双向绑定，（data－bingding），两者之间有一方发生变化则反应到另一方上，而mvp与mvvm的主要区别是，mvp中的view更新需要通过presenter，而mvvm则不需要，因为view和model进行了双向绑定，数据的修改回直接反映到view角色上，而view的修改也会导致数据的变更，此时，viewmodel的角色需要做的只是业务逻辑的处理，以及修改view或者model的状态，mvvm的模式有点像listview和adapter，数据集的关系，这个adapter就是viewmodel的角色，她与view进行了绑定，又与数据集进行了绑定，当数据集发生变化时，调用adapter的notifydatasetchanged之后view直接更新，他们之间没有直接的耦合（这里吐槽一下，很多逗比认为这个模式是mvc）

3，mvp的实现
下面我们通过一个简单的客户端实例来直观体会下mvp在开发中的运用，
如图，是一个简单的新闻客户端，进入应用之后，首先会从服务端下拉最新的20篇文章，然后将每个文章的简介显示到列表上，当用户点击某项数据时进入到另一个页面，该页面加载这篇文章的详细内容，因此，我们的业务逻辑大概有下列2项
（1）向服务器请求数据，并存储到数据库中
（2）从数据库中加载文章列表
我们的主界面（HomeFragment）就是一个RecyclerView和进度条，在加载数据时显示进度条，加载完成之后隐藏，网络请求使用的是Volley，我们先从Presenter相关的类型入手，用户需要从网络端获取文章，因此，需要一个数据获取接口，我们可以从本地数据库获