前言
相信大家在软件开发中，都会用各种设计。在Android应用开发的早些年间，一个APP的整体架构并没有得到很好的重视，毕竟当时懂Android开发的人并不多，资深的开发者更是少之又少，大家的主要精力都集中在如何更好的使用Android SDK提供的API，来完成APP的功能需求。随着多年以来的发展和积累，Android应用开发的UI架构模式经历了MVC、MVP到MVVM的演进。
UI架构模式是面向开发者的，它在一定程度会存在性能的损耗，但好处是代码具有更高的可阅读行、可测试性、可维护性以及可复用性。
MVP的基本概念
传统中的Android应用开发中，View层（Activity、Fragment或自定义View）承载了太多的责任，它不仅要完成界面的更新、复杂动画的渲染等UI相关的操作，还要处理各种业务逻辑，例如从网络获取数据、将用户输入保存到本地数据库中。由于职责不单一，View层的代码往往显得很庞大，一个Activity或者Fragment的代码行数可能要好几千行。这种模式显然不是长久之计，随着一个类的代码量逐渐增加，维护和升级将变得越来越困难，牵一发而动全身。为了更好的组织并对代码进行分层设计，我们有必要引入MVP模式。
MVP的全称是Model、View、Presenter，顾名思义，它将整个应用分为三层：
· View层： 视图层，包含界面相关的功能，例如各种Activity、Fragment、View、Adapter等，该层专注于用户的交互，实现设计师给出的界面，动画等交互效果。View层一般会持有Presenter层的引用，或者也可以通过依赖注入（例如 Dagger）的方式获得Presenter的实例，并非UI的逻辑操作委托给Presenter。
· Presenter层：逻辑控制层，充当中间人角色，用来隔离View层和Model层，该层是通过从View层剥离控制逻辑部分而形成的，主要负责View层和Model层的控制和交互。例如接收View层的网络数据加载请求，并分发给对应的Model处理，同时监听Model层的处理结果，最终将其反馈给View层，从而实现界面的刷新。
· Model层：封装各种数据来源，例如远程网络数据，本地数据库数据等，对Presenter层提供简单易用的接口。
MVP与MVC的区别
MVP是经典MVC的延伸和改进，从MVC的关系图和MVP的关系图相比，可以看出最大的不同在于：
· MVP中View层和Model层并没有直接通信，而是通过中间人Presenter来间接通信；Presenter和View以及Model的交互都是通过接口进行的；通常View与Presenter是一对一的，当然，复杂的View可能需要多个Presenter来共同处理，这些需要根据具体的业务需求而定。
· MVC中Model层和View层是直接通信的，而且Controller是基于行为的，可以被多个View共享。
MVP的好处
使用MVP组织代码架构，并对代码实施分层管理，有以下好处：
· 如果界面发生变化，甚至是全新改版，只需修改对应的View即可，Presenter和Model层无需改动。
· 如果业务逻辑或者数据获取方式发生变化，只需要修改对应的Model。
· 如果控制逻辑发生变化，只需修改对应的Presenter层。
· Presenter层、View层和Model层的交互都是基于接口实现的，这有助于Presenter进行单元测试，同时由于是面向接口编程，只 需事先定义好接口，每一层的实现可以交由不同的开发人员并行实现，最终再一起联调，能够明显加快某一功能的开发进度。
· 团队的新成员拿到项目的代码，能够很容易的读懂现有的逻辑，快速上手。
· 如果你正在开发一个对外的SDK，根据市场需求，需要提供带UI版本和不带UI的纯接口版本，那么使用MVP模式，将UI部分代码 放在View层，将接口部分代码放在Model层，打包的时候可以轻松实现是否将View层打包进去，从而避免接口版本混入UI相关的 代码。
MVP存在的问题
1、增加代码类的数量
2、由于进行了三层划分，函数的调用栈变深了，如果开发人员没能非常清楚的了解哪一层具体该负责哪些功能，那么可能存在因为层次职责辨认不清等原因导致不同层之间的代码乱入，从而没能达到MVP充分解耦各层的目的。