对于mvp模式，我之前也有过简单了解，知道他的核心思想是解耦，但一直没有怎么深入学习。总觉得，这种模式需要创建太多的类和接口,并且每次通信都需要繁琐的通过接口传递信息，总之，太麻烦了！
然而，最近几天对mvp的学习及了解却让我改变了这一看法(虽然上述问题依然存在。。)，现在觉得这种方式真是太妙了，必须将自己的理解记录学习下。
首先简单介绍下MVP
M：数据层（数据库、文件、网络等等...）
V：UI层（View、Activity、Fragment以及它们子类）
P：中介，通过P层将M和V进行关联
然后当然是撸码逐步实现MVP咯，这里我写了一个获取手机归属地的例子，查询完毕后将返回的结果显示在界面上（EditText输入要查询的手机号，然后点击按钮查询）
普通代码这样写：
看下效果如下：
不用MVP模式的情况下是这样实现的，整个逻辑都是在activity中实现的，那如果我想使用MVP模式解耦该怎么整呢?
接下来我们就用MVP来改进，将UI层和M层分离
M层：数据库操作、网络请求等等（这里是查询手机号码的请求）
其中，onHttpResultListener是网络请求的回调
V层：UI层（View、Activity、Fragment以及它们子类），以接口的形式表现，接口内部定义你需要的方法，然后由Activity去实现
P层：中介（MVP设计目的：为了将UI层和数据层进行解耦和），通过P层进行关联
既然P层是链接M层与V层的中介，那必然需要持有M层与V层的引用，由M层去调用接口然后在V层里回调，代码如下(类名没改过来)：
最后再来看一下V层Activity中的代码，实现MyView的接口，在接口的回调里处理你自己的逻辑(更新UI等等)，然后在onCreate()里初始化presenter
然后再点击事件里调用presenter的queryNum方法
ok,大功告成，现在看一下效果：
可以看出，跟之前效果是一样的。但是，这种方式已经将M层与V层成功分离了
当然，由于案例比较简单，代码量也比较少，所以感受不出MVP优势，但是，但是，但是重要的是我们要通过这个小case学习代码的思想，要了解的是这个思路
接下来需要对这块儿代码进行优化：UI层和M层解除绑定，在presenter中添加两个方法
Activity的onCreate中綁定，然後在onDestroy中解綁
这样，就完全解耦了，再对presenter的公用部分进行提取
写到这里，可能细心地同学就已经发现问题了，上面的BasePresenter对应的V是QueryView，那我还有登录注册的LoginView、registView等等不是就不能用了么？而且每个activity都需要复写onDestroy，不是太过于冗余么，而且的确如此，所以这里还需要再用泛型重新设计下我们的BasePresenter
对于Activity，可以抽象一个BaseActivity,复写onDestroy并让子类继承，由于BaseActivity并不知道具体需要哪个P跟V，所以同样需要传入P跟V的泛型，然后提供一个创建P和V的抽象方法由子类去实现
Activity继承BaseActivity，实现两个抽象方法
这样，一个简单的mvp使用案例就完成了，对一般的开发来说都没什么问题了，当然，如果想继续扩展据说还可以在这个基础上使用双重代理模式+动态代理模式(等研究透了再来分享，偷笑)
PS:上面代码是根据自己这几天的学习和理解写的(思路是借鉴看的一点视频、博客和示例代码的)，有什么不合理的地方还请大家及时指出，共同学习
