如何实现自己的Android MVP框架
作为MVC的进化版本，MVP在Android开发中越来越受到关注。但是，在项目开发中选择这样的软件设计模式需要谨慎。一旦你决定使用MVP作为你的App的开发模式，你最好坚持下去。如果在使用MVP模式的开发过程中发现问题，坑越来越大，那么你想用MVC重新设计，基本相当于推倒重来。要知道Android上的MVP并没有统一的标准或框架，不像SSH是支持Java EE开发的成熟、稳定、强大的三剑客。所以在使用MVP的时候，一定要做好自己的理解，尽量预测你的App各个模块的需求(客户说我们会改:-()以便提前做好设计工作。当然，既然MVP能出现，肯定有它的优势。不然谁会关注这个弹出来的东西？下面就Android中的MVP做一些说明。
MVP简介
相信大家对MVC都很熟悉:M-Model- model，V-View- view，C-Controller- controller。作为MVC的进化版本，MVP也是用户界面(用户层)的一种实现方式，所以类似MVP对应的含义是:M-Model- model，V-View- view，P-Presenter- presenter。从MVC和MVP的结合来看，controller/Presenter在MVC/MVP中扮演逻辑控制处理的角色，控制所有的业务流程。MVP和MVC最大的区别就是M和V没有直接关系，模型和视图没有直接关系。它们之间有一个呈现者层，负责调节视图和模型之间的间接交互。MVP的结构图如下所示，不必把对这个图的理解局限于规则。毕竟不同场景会有一些出入。Android中很重要的一点是，UI的操作基本上需要异步完成，即UI可以在MainThread中操作，所以将视图从模型中切割分离出来是合理的。此外，通过使用接口定义交互操作，演示者、视图和模型之间的交互可以进一步松散耦合，通过接口可以更方便地进行单元测试。
？MVP结构图
MVP模型
模型是用户界面需要显示的数据的抽象，也可以理解为从业务数据(结果)到用户界面(业务规则、数据访问、模型类)的抽象。在本文中，Demo直接将业务放入相应的模型中进行简单处理。
MVP视图
这一层视图很薄，只负责显示数据，提供友好的界面与用户交互。MVP下的活动和片段都体现在这一层。Activity一般做一些加载UI视图、设置监控、交给Presenter等工作，所以需要持有对应Presenter的引用。例如，在滚动活动列表时隐藏或显示Acionbar(工具栏)也应该在这一层。另外，在对View中输入的数据进行一些判断时，比如EditText的输入数据如果是简单的非空判断，可以作为View层的逻辑，而当需要对EditText的数据进行比较复杂的时候，比如从数据库中获取本地数据进行判断，显然需要经过Model层返回，所以这些细节需要自己权衡。
MVP的主持人
表示层处理程序的各种逻辑的分布。视图层的UI接收到反馈命令、定时命令、系统命令等指令后，将分发处理逻辑交给业务层进行具体的业务操作，然后将得到的模型展示给视图。
演示
不如开始写代码。Demo很简单，还是上图比较直观。输入城市代码，点击按钮获取该城市的天气信息，然后显示出来。网络操作用的是凌空框架，分析用的是Gson，剩下的都是手写。整个项目的包装设计如下:
？数据包结构
项目效果预览
包图中有三个明显的层:模型包、Presenter包、UI包，三者都实现了自己的结构，模型是WeatherModel，Presenter是WeatherPresenter，视图是Weather，所以具体的实现类在impl包中，视图层是Activity。另外，app和util包无关，可以忽略。可以看出，采用MVP设计后，项目中明显有很多东西，这是不可避免的。用原来的方法可以让项目更容易打开，但是以后会有维护，测试，添加功能。。。
entity中的实体属性和json中的基本对应，代码就不贴了。
视图中的界面:
公共接口天气视图{
void show loading()；
void hide loading()；
void show error()；
void setWeatherInfo(天气天气)；
}
WeatherPresenter的界面:
公共接口WeatherPresenter {
/**
*了解天气的逻辑
*/
void getWeather(字符串city no)；
}
WeatherModel接口:
公共接口WeatherModel {
void loadWeather(字符串cityNO，onweathelistener listener)；
}
prestener中还有一个OnWeatherListener，在Presenter层实现，回调模型层，改变视图层的状态，保证模型层不直接操作视图层。如果weatherpresentempl中没有实现这个接口，weatherpresentempl只有对View和Model的引用，那么Model怎么把结果告诉View呢？当然，这只是一种解决方案。在实际项目中，可以结合Dagger、EventBus、Otto等第三方框架，实现更松散耦合的设计。
WeatherListener {
/**
*成功时回调
*
* @param天气
*/
void onSuccess(天气天气)；
/**
*失败时回调，简单处理，什么都没做
*/
void on error()；
}
所以demo: Activity的代码流做了一些UI初始化，需要实例化WeatherPresenter对应的引用和实现WeatherView的接口，并监控接口动作。按下Go按钮后，会接收天气查询事件，在onClick中接收时，会通过WeatherPresenter的引用交给WeatherPresenter进行处理。当WeatherPresenter接收到天气查询的逻辑后，就知道需要查询天气，然后将天气查询的具体业务实现交给WeatherModel来实现，同时将WeatherListener本身传递给WeatherModel。WeatherModel查询天气服务后，通过WeatherListener回调将结果通知WeatherPresenter，WeatherPresenter将结果返回给视图层的活动，最后活动显示结果。就是这样。请轻拍砖块。
结束
采用哪种软件设计模式来实现以下目标，最好能找到合适的来使用:
易于维护
易于测试
松散耦合度
高重用性
强大而稳定
-
以上内容参考互联网，希望以上知识对你有所帮助。