目录
MVP那些事儿(5)……中介者模式与MVP的关系【知识点】
MVP那些事儿(6)……MVC变身为MVP
MVP那些事儿(7)……Kotlin实现MVP【知识点】
MVP那些事儿(8)……当MVP遇到Lifecycle【知识点】
MVP那些事儿(9)……探究MVP的最佳实践
MVP那些事儿(10)……MVVM双向绑定
MVP那些事儿(11)……基于MVVM的Architecture Components
引言
随着这几年移动互联网的快速发展，移动互联网技术也得到了推动，辅助架构设计型的框架和思想层出不穷，从井喷的2015年到现在，开发者们越来越离不开这些高性能、高效率的工具，而制造这些工具的公司或个人，也被推到神坛，受猿们的膜拜。与此同时，Google在今年的io大会上发布了自己的官方框架Architecture Components【译】，可以说是相当的应景了。时不我待，了解架构的知识，并且灵活的应用是我们程序员未来必不可少的技能，这系列文章是介绍MVP架构的，希望能对阅读此文的朋友们带来些收获。
1、如何实现一个MVP框架的基本原则，以及MVP的使用场景，是我想写这篇文章的初衷，同时也是对我自己学习的知识做一个总体的融合。
2、为了避免一上来生硬的开场，我先以一个简单的开发例子作为引子，以初学者的角度去看待问题，同时也能兼顾到初学者，到后面我们会一步步提示。所以你也可以选择直接跳转到。。。。
3、因为讲架构，多是场景描述，所以代码量比较少，习惯于通过代码理解的同学，我尽量多些并反复描述。
场景
假设实现一个商品的列表展示功能，我们首先需要一个用户界面，包含一些控件来供用户操作，比如列表展示。我们大多数情况下使用一个Fragment作为控件的载体，在Fragment中直接调用网络请求的工具并等待回调方法被执行后去刷新UI去展示数据，所以对于这个需求的代码量并不是很多。现在需求增加了，要加入下拉刷新和上拉加载更多，一般是监听这两个事件，在相应的回调中处理数据，没几行代码，依旧写在Fragment中，而需求又一次增加了，要加入排序，紧接着我们处理排序逻辑，代码依旧写在Fragment中，接着又增加需求了，加入详情页的跳转，可能跳转前要处理些业务逻辑，接着又要增加需求了，列表视图可以从宫格式转变为瀑布式，需要改变控件的样式，……接着新需求又来了，可编辑的列表项，可以删除和修改列表项，同时数据要同步到服务器，需求又来了，编辑列表项需要动画功能……直到这个时候我们回头再看看我们的Fragment，这个时候我们可能无法容忍Fragment里混乱复杂的逻辑了。
从功能性需求的角度来说，功能完整、软件正常运行，这是没有问题的，但回过头来我看了一下代码觉的并不是那么“没问题”，在不使用架构的情况下，我们无感知的将逻辑代码业务以及视图代码都堆积到了Activity当中，这样的角色可以说是相当的臃肿的，同时非常不利于未来的扩展，于是非功能性的需求需要满足：Activity优化与扩展性。
我们再梳理一下这个场景的需求列表：
1、列表展示
2、列表支持下拉刷新，上拉加载更多
3、列表要可以排序，可能会有n个条件
4、列表的item点击跳转到详情页面
5、列表展示需要多样化，瀑布流变宫格
6、列表可编辑，也许包括CURD，同时要同步服务器
7、编辑列表时，加上动画效果
下一章节，我们首先使用加入架构的方式来处理上面的需求，其中会介绍Model的定义，Controller的职责，以及它们如何通过控制反转来进行解耦，如果你对MVC有了足够的了解，可以直接跳转到MVP的章节。
