通常一个App的开发过程要经历三个阶段：
第一阶段：先用最少的成本和时间快速把东西做出来。
第二阶段：积累一定用户量之后在小步快跑的迭代功能。
第三阶段：在性能和体验上逐步求精。
好多项目在第二阶段和第三阶段耗费了好多本来不应该浪费的人力成本、时间成本，究其原因就是因为前期忽略了合理的架构，因此在项目前期采用合理的架构显得尤为重要。本文主要讨论一下目前比较流行的三种架构：MVC，MVP，MVVM。
MVC（Model-View-Controller）
Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
各部分之间的通信方式如下。
1.View 传送指令到 Controller
2.Controller 完成业务逻辑后，要求 Model 改变状态
3.Model 将新的数据发送到 View，用户得到反馈MVP（Model-View-Presenter)
V：Activity为代表，这时候的Activity更为简单了，只负责UI的绘制和刷新。
P：负责传达指令。向上接收V的事件指令并需要的时候传达给M，向下接收M的指令并通知V刷新UI。
M：只负责出来数据逻辑。其实还可以细分一些东西，比如Http请求，很多时候我们的Http框架都是用的第三方开源框架，如果有一天更优秀的框架出现了，要更换，怎么才能做到不影响其他层次？如果我门做了分层隔离那么，我门可以很轻松的换掉，如果没有做分层隔离，那么我门可能要在每一个功能模块的M中修改代码，修改代价是巨大的，所以一遍第三方开源框架我都不会直接使用而是在业务上做一层抽象隔离。同理，本地数据的存储，也有必要做响应的封装或隔离，因为今天是用Litepal，也许某一天想用GreenDao了，只需要修改封装类的代码就好了。
各部分之间的通信方式如下。
1. 各部分之间的通信，都是双向的。
2. View 与 Model 不发生联系，都通过 Presenter 传递。
3. View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
MVP类图：
我们把每一层都抽象成一个接口，例如V层，我们定义一个接口为View（不要和Android API里的View弄混了），让后Activity为这个View的具体实现。每一层对另一层的依赖都是接口依赖，并不关心另一层的具体实现，每一层我们都可以写不同的实现，随时切换，这就意味着，有一天如果有一层不好用了，我们可以轻松的重写另一个实现来替换掉，而不是如履薄冰的修改。
MVVM (Model-View-ViewModel)
MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。
唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。Angular 和 Ember 都采用这种模式。
MVP与MVC的异同
MVC模式与MVP模式都作为用来分离UI层与业务层的一种开发模式被应用了很多年。在我们选择一种开发模式时，首先需要了解一下这种模式的利弊：
无论MVC或是MVP模式都不可避免地存在一个弊端： 额外的代码复杂度及学习成本。
这就导致了这两种开发模式也许并不是很小型应用。
但比起他们的优点，这点弊端基本可以忽略了：
(1)降低耦合度
(2)模块职责划分明显
(3)利于测试驱动开发
(4)代码复用
(5)隐藏数据
(6)代码灵活性对于MVP与MVC这两种模式，它们之间也有很大的差异。有一些程序员选择不使用任何一种模式，有一部分原因也许就是不能区分这两种模式差异。以下是这两种模式之间最关键的差异：
MVP模式：
•View不直接与Model交互，而是通过与Presenter交互来与Model间接交互
•Presenter与View的交互是通过接口来进行的，更有利于添加单元测试
•通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑
MVC模式：
•View可以与Model直接交互
•Controller是基于行为的，并且可以被多个View共享
•可以负责决定显示哪个View
