MVC 、MVP 、MVVM 这些开发框架相信大家都已经听说并或多或少的用过了，在项目中，我也用到了MVP开发模式，在此结合网上一些介绍，做一个关于MVP的总结。
一 、android中的MVC是什么？存在什么问题？
网上关于MVC是什么的图片分析不少，但是看到一句话：自古图片留不住，总是代码得人心，哈哈，那就上实际点的代码，这里应用了参考文献中的代码。
看样子很符合MVC的架构，
Model : Hotel,HotelLoader
View : mHotelNameView，mHotelAddressView ，mHotelStarView
Controller: HotelActivity
有的人会说这里的View 就是Activity，所以认为这里的Activity同时承担了View 和Controller的角色，在页面逻辑变得很复杂时，会导致Activity里的代码急剧变大，难以阅读和维护。
当然很多时候，我们会对View进行一些封装，这样会使得Activity中的一些业务逻辑代码转移到了自定义的View中，这样可以减少Activity中的代码，可读性和维护性也更好。
那MVC的问题究竟在哪里呢？
有人说会不利于单元测试，确实，由于没有View 没有与Model，Controller完全解耦，在不考虑View的情况下（美工还没有出高保真图，界面只有大概轮廓），会不利于测试用例单独测试我们写的业务逻辑是否正确，但是大多数公司的项目应该都是没有用到单元测试，通常我们如果只是想使用假数据的话，MVC模式也可以满足。
但是由于MVC模式中，View中会夹杂有很多业务逻辑和Model层的代码，导致View的重用性几乎为0，并且由于这些夹杂，后期会连假数据都很难测试，更不用说顺利进行单元测试了。所以，当项目复杂到一定程度，还是使用MVP架构能使得代码结构更清晰，便于维护。
**
二 、android中的MVP是什么？存在什么问题？
关于MVP的一些基本概念，大家可以看一下文末的参考链接，其实相比MVC的主要变化，就是View不能再直接访问Model了，而是通过Presenter层来访问Model，由Presenter来完成View和Model的交互，
MVP中的View可以指的是Activity，Fragment或者我们的自定义View，以Activity为例，代码仍然来自参考链接。
主Activity里的代码：
下面是抽取的View接口：
Presenter层的代码：
这里可以看到，Presenter层中持有View和Model层的应用，这里Model使用了TaskManager替代，下面看一下TaskManager中的相关代码和其中涉及的几个class
从以上代码中，我们可以看出，View层完全和Model层隔离开来，View层并不关心数据到底是如何得到的，只处理接收数据后的显示，
TaskManager的构造中传入的是Model层的接口，通过这种形式，TaskManager可以返回真实数据或者假数据，这样就可以无需等待服务端同学把接口开发完，我们就可以先完成主体界面和逻辑的开发工作了。
同时View层由于不再含有Model层的代码，且业务逻辑主体也交给了Presenter层，所以View层就可以达到复用了，只要再配合不同的Presenter层和Model层即可。
至此，一个基本的关于MVP的框架就已经具备了，当然，接下来还有一些问题要处理，比如，我们上面代码中Model层获取网络数据的代码没有写，通常我们会在Model层的获取数据方法的参数中，以接口回调的方式返回网络数据，这里可以使用如Volley+OKHttp的形式。
但是由于获取网络数据是耗时操作，有可能在返回数据前，页面已经退出或者View已经不在了，那么Presenter中就会发生内存泄漏和空指针的问题，在Android中的MVP架构总结（二）中会介绍如何处理该问题以及如何简单的封装一下MVP。
参考链接：