MVC设计架构
用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。其中M层处理数据，业务逻辑等；V层处理界面的显示结果；C层起到桥梁的作用，来控制V层和M层通信以此来达到分离视图显示和业务逻辑层。
Android中的MVC
Android中界面部分也采用了当前比较流行的MVC框架，在Android中：
视图层(View)
一般采用XML文件进行界面的描述，这些XML可以理解为AndroidApp的View。使用的时候可以非常方便的引入。同时便于后期界面的修改。逻辑中与界面对应的id不变化则代码不用修改，大大增强了代码的可维护性。控制层(Controller)
Android的控制层的重任通常落在了众多的Activity的肩上。这句话也就暗含了不要在Activity中写代码，要通过Activity交割Model业务逻辑层处理，这样做的另外一个原因是Android中的Actiivity的响应时间是5s，如果耗时的操作放在这里，程序就很容易被回收掉。模型层(Model)
我们针对业务模型，建立的数据结构和相关的类，就可以理解为AndroidApp的Model，Model是与View无关，而与业务相关的（感谢@Xander的讲解）。对数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的。就是应用程序中二进制的数据。
MVP模式（Model-View-Presenter）
是MVC模式的一个衍生。在使用mvc框架的时候，Activity本身需要担负与用户之间的操作交互，界面的展示，不是单纯的Controller或View。而且现在大部分的Activity还对整个App起到类似IOS中的【ViewController】的作用，这又带入了大量的逻辑代码，造成Activity的臃肿。为了解决这个问题，让我们引入MVP框架。主要目的是为了解耦，使项目易于维护。
View:负责绘制UI元素、与用户进行交互(在Android中体现为Activity)
Model:负责存储、检索、操纵数据(有时也实现一个Model interface用来降低耦合)
Presenter:作为View与Model交互的中间纽带，处理与用户交互的负责逻辑。
*View interface:需要View实现的接口，View通过View interface与Presenter进行交互，降低耦合，方便进行单元测试
比较
MVP模式：
View不直接与Model交互 ，而是通过与Presenter交互来与Model间接交互
Presenter与View的交互是通过接口来进行的，更有利于添加单元测试
通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑
MVC模式：
View可以与Model直接交互
Controller是基于行为的，并且可以被多个View共享
可以负责决定显示哪个View
mvp的核心优势是实现了view和model 的完全解耦，更改ui界面并不影响model,但是presenter持有view的引用，容易造成内存泄漏，所以在使用时要使用弱引用，来避免内存泄露的发生；
参考文章：http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0603/2992.html
https://blog.csdn.net/jdsjlzx/article/details/51174396