1.MVP：先模仿照抄，搬运工来啦
上面的跟帖中赞同最多的作者写了系列介绍，觉得不错，很清晰的思路：；
学而不思则罔，思而不学则殆。编程和练功一个道理，有时天天写代码就像天天练武，但不思考不看书就仅仅是花拳绣腿，没有感悟就无法提升。但基础不足就看到很深的理论，连个类都封装不好就去看设计模式和架构那肯定也像过早的得到了武功秘籍却怎么看都像天书不知所云。不能一味闷头去写，也不能每天什么都看，加点思考和对比~这么多语言学不过来的，触类旁通掌握住主体思想才是终极策略。
花了两天时间看了些博客的分享，还有一些利用MVP思想实现的例子，因为代码的功底不是太扎实所以只能照葫芦画瓢似的自己实现的小的Demo，以前看过：不能因模式而模式，可能很多App功能简单，小到用起来某种结构反而变的复杂。如android在NDK的帮助文档里写到，不一定用了Jni就可以加速了，需要实际的平衡性能和使用场景。不管怎么样，理解了思想以后才有更多的思考空间，技多不压身嘛~
而且，这种采蜜似的blog大搜罗真的有点像研究生时代为了准备一个讨论版ppt或者是一篇小论文而集中精力研读相关paper的日子，由一篇开始，然后根据它的引用继续一篇篇的追溯，这种链式的发散似的学习场景常常进度延迟，但坚持完成往往会有意想不到的收获。希望以后的过程中能把这些学到的东西以学习笔记或者代码demo的形式记录下来，升华为表达出来的东西才不容易忘记。
我看到的MVP：
翻译的内容：MVP并不算是一个架构模式，因为它只着重于表现层。MVP的主要作用是将View和数据源解耦，一般将app至少分为三层。具体的实现形式很多，主要看我们委托给Presenter层职责情况，比如开始设计的时候：VIew是否要管理进度条的显示或者隐藏和acrionbar上action等等。
面向接口的编程，降低View和Model的耦合度，基本它俩不用直接打交道了，都交给中间人Presenter来办。具体实现上可能要写的类的数目一下子增加了1-2倍，但是每个类的短小精悍，而且更好的体现了 设计模式的SRP单一职责原则。
事件驱动event drive，被动视图passive view，逻辑由Presenter来办，具体实施上，一种方法：以一个登陆Activity为例
View：IView：定义所有login页面上所有View可能的的动作接口，与逻辑相关的接口
Model：IUser：用到的数据接口，定义View交互对数据影响的接口
UserModel：IUser的实现类
Presenter：IPresenter：定义所有login页面上View和数据Model的逻辑相关的操作
PresenterCompl：IPresenter的实现类，IView和IUser都将作为它的成员变量，当然实例化的时候用各自的实现类也就是相应的Activity和UserModel，并且在实现IPresenter中的方法时调用，Activity：LoginActivity，需要实现IView接口。
需要IPresenter作为成员变量，当然实例化的时候用PresenterCompl。
这样的结构的话，Activity中基本的click、滑动等基本事件触发时就能用PresenterCompl定义的逻辑处理，一般此时会用到数据Model的接口对接数据的变化。当逻辑执行完毕后PresenterCompl中会驱动IView中的接口，因为Activity实现了这个接口，当然也就能至执行到相应的代码。
