【知识必备】浅淡MVP在Android项目中的实战演习，让代码结构更简单~-CSDN博客

写在前面

讲道理，这次是真的笔者很久都没有更新 blog 了，主要最近维护的框架问题也是层出不穷，而且对技术交流群的解答也让我身心疲惫，所以在这里跟关注我的人说声抱歉，没有定期给你们带来福利，那么这里就给大家带来一个重磅福利：爱吖妹纸 —— Retrofit & RxJava & MVP & Butterknife 的完整 App.

讲到最近让我身心疲惫的问题解答，无疑是让我在开源的路上越走越远，虽然我不是技术大牛，却依然被一些很简单的问题轮番轰炸，其实笔者的内心真的是拒绝的。不得不说，写给技术群内的你和群主，为什么你提问，而总没人回你！写的挺好。

概述

废话也不多说，对于 MVP（Model View Presenter），我相信大多数人都能说出一些的，“ MVC 的演化版本”，“让Model和View完全解耦”等等，但用过 MVP 的人一定会觉得，在 Android 中，代码很清晰，不过多了很多类。对于大多数人而言，在看 MVP 的 Demo 的时候，一眼便是慢慢的 nice，然而让自己来写个例子，却很头疼写不出来。但的确 MVC 模式写起来更加像是顺水推舟。只需要把自己的业务逻辑一股脑的放进 Activity 就成功完事儿。

不得不说，之前我们项目中的确也是用的 MVC 在编写的。很简单的会发现随便一个 Activity 代码都是几百上千行，甚至还有一万行以上的。看起来的确那么一回事儿，但是细想这个 View 对于布局文件，其实能做的事情特别少，实际上关于该布局文件中的数据绑定的操作，事件处理的操作都在 Activity 中，造成了 Activity 既想 View 又像 Controller，鄙弃代码上的不美观来说，对于后面的阅读代码真的是吃力。

不信？你瞧瞧。

也许业务逻辑比较简单的功能用 MVC 没什么，但是想没想过，如果你产品后面改需求怎么办？是的，你接受产品需求的强奸，但还是只有忍辱偷生。在日渐复杂的业务逻辑上，你的 Activity 和 Fragment 代码越来越多，最终导致代码爆炸，难以维护。

网上浏览一圈，发现讲 MVP 的文章比比皆是，可见 MVP 的欢迎度，但大多数文章都只是讲理论，稍微好点的会附带一个简单的登录的 Demo。然而，一个简单的 demo 很难让初次接触 MVP 模式的人掌握它的使用。所以爱吖妹纸应运而生。

爱吖妹纸的优势？

爱吖妹纸是运用 MVP，Retrofit，RxJava 等主流框架整合的干货 App，项目资源来源于代码家的干货集中营。代码量不多，但基本涉及了各个方面，界面采用 design 风格，所以也是学习 design 的良药。你还在等什么，猛戳链接吧！https://github.com/nanchen2251/AiYaGirl

什么是 MVP

当然不能跑题，前面对 MVP 做了简单的概述，下面还是用一个简单的图表示一下。

如上图所示，在项目中 View 和 Model 并不直接交互，而是使用 Presenter 作为 View 和 Model 之间的桥梁。其中 Presenter 中同时持有 View 层以及 Model 层的 Interface 的引用，而 View 层持有 Presenter 层 Interface 的引用，当 View 层某个页面需要展示某些数据的时候，首先会调用Presenter 层的某个接口，然后 Presenter 层会调用 Model 层请求数据，当 Model 层数据加载成功之后会调用 Presenter 层的回调方法通知 Presenter 层数据加载完毕，最后 Presenter 层再调用 View 层的接口将加载后的数据展示给用户。这就是 MVP 模式的核心过程。

这样分层的好处就是大大减少了 Model 与 View 层之间的耦合度。一方面可以使得 View 层和 Model 层单独开发与测试，互不依赖。另一方面Model层可以封装复用，可以极大的减少代码量。当然，MVP 还有其他的一些优点，这里不再赘述。