回顾上一篇文章
《Android应用架构概述》
，我们知道，Android App 本质上抽象成两个层次：视图和数据。为了App在发展过程中快速的适应变化，方便维护和快速迭代，我们要将数据和视图解耦，而在解藕方面我们的前辈们在漫长的软件开发经验中为我们提供了两套流行的指导框架：MVC和MVP，其中MVP近年来在Android应用开发上逐渐流行。接着上一篇的内容，本章我将结合具体例子说清MVP解藕的实现。所以本章的思路是：以登录为业务场景，分析对比“非MVP”和MVP的实现方式。demo地址：
https://github.com/liuguangli/MVPTeach
简单的登录场景。提交登录信息（用户名和密码），处理登录逻辑，返回用户信息并保存。
在没有任何分层的指导思想下，我们往往或把视图逻辑数据逻辑都耦合到Activity中来实现。
登录按钮的响应方法：
登录检查：
登录到服务器：
在这里，Activity和Http框架（android－ansyc－http）以及整改数据请求逻辑耦合了。如果以后登录逻辑变化了，那么App所有和登录逻辑相关的页面都会受到牵连；或者Http框架更换了，所有Activity都要受到牵连。（本demo只有一条业务场景一个Activiy体现不出影响的严重性，一个完整的App就能体现出来了）
保存数据：
沿着《Android应用架构概述》的思路，我们先把登录这个业务场景实现的层次图画出来。
数据请求和处理逻辑交出去了。至此，Activity变的简单，只负责UI的变化行为，数据请求和处理逻辑的具体实现对它没有影响。
LoginManager才是正真处理业务逻辑的家伙，它和两个模块有直接联系。它的职责：一、把来自UI的数据解析成网络框架层所需格式并调用网络框架层请求服务器数据。二、调用本地数据访问层（DAO）存取数据。三、向Presenter传递数据。
任何东西都有两面性，mvp虽然为数据视图解耦提供了很好的指导思想，但是我门发现层次变多了，调用栈变多了。着就要求开发人员能够清晰的认识业务划分，清楚的知道MVP中，那个层次该做什么、哪个层次不该做什么。例如：就就面的实现，我门做一点变化：
正如图注释所诉，虽然在形式结构上作了MVP的设计，但因为层次职责没化清，View层作了Mode该作的事情，并没有达到解耦的目的。
demo: https://github.com/liuguangli/MVPTeach
业务场景
非MVP的实现
登录按钮的响应方法：
登录检查：
登录到服务器：
在这里，Activity和Http框架（android－ansyc－http）以及整改数据请求逻辑耦合了。如果以后登录逻辑变化了，那么App所有和登录逻辑相关的页面都会受到牵连；或者Http框架更换了，所有Activity都要受到牵连。（本demo只有一条业务场景一个Activiy体现不出影响的严重性，一个完整的App就能体现出来了）
保存数据：
数据保存的方式有很多中，也可能会随着需求的变化而选择不同的方式，同理，如果所有的Activiy都这样耦合，那么日后想要切换更合适的存储方式将变得寸步难行。
MVP的实现
类图：
LoginActivity的实现
数据请求和处理逻辑交出去了。至此，Activity变的简单，只负责UI的变化行为，数据请求和处理逻辑的具体实现对它没有影响。
LoginPresenter的实现
LoginPresenterImp作为LoginPresenter的实现类。它的任务和职责是：一、接受LoginActivity提交的登录指令并向LoginManager传递任务（真正的请求在LoginManagerImp中执行）。二、接受LoginManagerImp回调的结果。
LoginManager的实现
用好双刃剑
正如图注释所诉，虽然在形式结构上作了MVP的设计，但因为层次职责没化清，View层作了Mode该作的事情，并没有达到解耦的目的。
demo: https://github.com/liuguangli/MVPTeach
