Android 珍藏版 MVP架构 Demo（这就是你最想要的）

新年新气象，祝大家2018年越来越旺！

长话短说，本人最近换了一份工作，工作中用到MVP架构，以懒成名的我，不得不去学习新的东西，索性公司妹子不错，心情大好
特此发上福利。

最近很喜欢白茶的公众号 》》》》 吾皇万睡

每当坚持不下的时候，是它支持着我，所以我要把它分享给大家。

进入正题，MVP 架构的优点和缺点

从MVP方面来说：

随着UI创建技术的功能日益增强，UI层也履行着越来越多的职责。为了更好地细分视图(View)与模型(Model)的功能，让View专注于处理数据的可视化以及与用户的交互，同时让Model只关系数据的处理，基于MVC概念的MVP(Model-View-Presenter)模式应运而生。

从MVC和MVP比较来说：

MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。

在MVC里，View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。

MVP模式的优点：
(1)降低耦合度
(2)模块职责划分明显
(3)利于测试驱动开发
(4)代码复用
(5)隐藏数据
(6)代码灵活性
MVP模式的缺点：
由于对视图的渲染放在了Presenter中，所以视图和Presenter的交互会过于频繁。还有一点需要明白，如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了。

我们有些了解了，那么久进入实战吧！！！
链接：https://pan.baidu.com/s/1mjpwkli