死磕安卓前序：MVP架构探究之旅—基础篇
前言
了解相关更多技术，可参考《我就死磕安卓了，怎么了？》，接下来谈一谈我们来学习一下MVP的基本认识。
大家对MVC的架构模式再熟悉不过。今天我们就学习一下MVP架构模式。
MVC和MVP之间的对比
什么是MVP(Model View Presenter)模式?
- 1、为了使得视图接口可以与模型和控制器进行交互，控制器执行一些初始化事件
- 2、用户通过视图（用户接口）执行一些操作
- 3、控制器处理用户行为(可以用观察着模式实现)并通知模型进行更新
- 4、模型引发一些事件，以便将改变发告知视图
- 5、视图处理模型变更的事件，然后显示新的模型数据
- 6、用户接口等待用户的进一步操作
MVP的优势
- 1、模型与视图完全分离，我们可以修改视图而不影响模型
- 2、可以更高效地使用模型，因为所以的交互都发生在一个地方——Presenter内部
- 3、我们可以将一个Presener用于多个视图，而不需要改变Presenter的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
- 4、如果我们把逻辑放在Presenter中，那么我们就可以脱离用户接口来测试这些逻辑（单元测试）
MVP的问题
由于对视图的渲染放在了Presenter中，所以视图和Persenter的交互会过于频繁。
还有一点你需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的 联系过于紧密。一旦视图需要变更，那么 Presenter也需要变更了。比如说，原本用来呈现Html的Presenter现在也需要用于呈现Pdf了，那么视图很有可能也需要变更。
一个简单的登陆实例
效果图：
目录结构
mpv目录结结构
服务器对岸用例测试LoginService
v层
M层
看起来要复杂的比较多。代码量也相对比较大。但是如果用到大项目中我们就能显示出优势了。接下来进行mvp的封装。
时间久了，我们就会发现mvp会带来极大的方面：在MVP中，由于业务逻辑都在Presenter里，我们完全可以写一个PresenterTest的实现类继承Presenter的接口，现在只要在Activity里把Presenter的创建换成PresenterTest，就能进行单元测试了，测试完再换回来即可。万一发现还得进行测试，那就再换成PresenterTest吧。
总结
M、V、P三层各有什么特点。
Model层：
这一层主要就是负责向数据源(一般为服务器/数据库，下同)发起获取数据请求，并且把获取的数据或者错误信息回调给持有的Presenter。除了发起请求功能外，一般我们还需要一个取消请求的方法。
所以Model层主要的功能是:
- 向数据源发起请求；
- 取消该请求；
- 通知Presenter处理结果。
Presenter层：
这层主要负责通知Model层向服务器发起请求并接收Model层回调的数据或者错误信息，并且这一层还要负责把数据或者错误信息处理后回调到View层，由View层负责显示。
一般在网络请求中的错误信息分为两种，一种是网络设备的网络状态错误，无法发送请求；另外一种是服务器拒绝了这次请求。所以Presenter的主要功能是：
- 通知Model层向服务器发起请求；
- 接收Model层返回的数据（服务器可能返回数据或者拒绝服务信息）；
- 接收Model层返回的网络错误信息；
- 通知Model层取消这次请求；
- 通知View接收处理后的数据。
View层：
在MVP模式中，View层是一个接口。它的首要任务是把Presenter处理后的数据传到具体的原生控件中显示，并且控制是否显示加载进度条。
所以View层的主要功能是：
- 显示／隐藏进度条。
- 接收Presenter处理后的正确数据。
- 接收Presenter返回的网络错误信息。
- 接收Presenter返回的服务器拒绝服务信息。
MVP模式的核心思想
MVP把Activity中的UI逻辑抽象成View接口，把业务逻辑抽象成Presenter接口，Model类还是原来的Model。
在MVP模式中Activity的功能就是响应生命周期和显示界面，具体其他的工作都丢到了Presenter层中进行完成，Presenter其实是Model层和View层的桥梁。
项目地址：https://github.com/androidsta...
服务端测试项目地址：
http://download.csdn.net/down...
参考链接：
遗留问题：
- 如果代码量比较多，是否考虑mvp怎么复用的，如果复用是否会增加耦合度？
总结：过多的追求模式有时候也会适得其反，MVC应用有时候也有太多的宽泛。
mvp参考
MVP+Dagger2+Retrofit2.0+Rxjava看这一个例子就够了
如果您觉得很有帮助，欢迎随时撩我。