前情提要：前一篇文章写道，本人目前两年半工作经验，就职于手机公司，做过framework，做过整个系统的主题样式，控件等。做过原生App。长期与源码打交道，.mk编译的那种。就今年才正儿八经开始用IDEA工具进行开发，真香，好用。
这也导致了我根本不怎么会上层的app开发，更不知道互联网应用具体是个什么样子的，三方框架基本没用过。为了打破这种僵局，准备写个互联网类型的app。用上流行的框架。MVP+Dagger2+Retrofit+Rxjava+Dagger2+jetpack等。先挨个分析清楚，然后动手写APP。
先来说说MVP吧，（本次MVP全部拿计算1+1来讨论，简洁明了）网上很多关于MVP架构的文章，个人挺喜欢用MVP，代码简洁，耦合度低，方便维护。给我的感觉缺点就是比较冗余，因为要写多个presenter，model。新人看了一脸懵逼，点进去全是接口。
这里就不讨论传说中的MVC了，因为MVC是啥我也不知道。O(∩_∩)O.....
以下全是个人总结出来的见解，请大佬海涵。
各层的功能职责，用下面的一张图来表示，就是做一个最简单的加法，画的有点丑哈。因该都看得明白，主要利用回调机制
最简单的MVP流程图
MVP有这几个版本，其实核心一样的，封装不同而已
1.最原始的MVP
2.加入Contract的MVP
3.加入动态代理的MVP
一：先来说说最简单的一种MVP 新手都是从这种看起的，这里拿一个最简单的加法计算来讨论。所有流程上面的图就可以概括，结合上面的图来看，很清晰的。
敲黑板：这种方式很少用了 个人感觉太Low了，没得牌面。写代码就是为了让别人看了觉得高大上的。
这里仅仅阐述原理，核心就是这个，明白了原理接下来的两种MVP就很清晰了
比如你的Activity里面有一个View负责输入数字。分包如下
包结构
View（activity）
View接口
Presenter
model
model接口
结果
PS：其实在Activity里面直接new Presenter 是不符合规范的，增加耦合，可以用Dagger2依赖注入的方式，这里不做讨论，仅仅看MVP的流程
看完上面的先来张图放松一哈，你就当做是我就行了，这样看的更有激情
二：加入Contract的MVP
上面的MVP核心弄清楚之后，继续看加入Contract的MVP 我们继续来研究1+1.....
这里加入Contract 契约类。这是Google推荐的MVP方式。Google在GitHub上发布的demo链接：
GitHub - googlesamples/android-architecture at todo-mvp
这是一个类似于记事本的demo，较为复杂，这里还是拿1+1来讨论
如果是初学者，建议先去看下Java泛型机制，推荐一个链接：java 泛型详解-绝对是对泛型方法讲解最详细的，没有之一 - little fat - 博客园
Google推荐把Presenter和View接口放在一起。放在Contract契约类中，这样逻辑更加的清晰。
继续改造上面的1+1Demo。
之前Presenter直接new出来的，并没有抽出接口，通过View接口注入进去
这里说的比较抽象。再来一张图吧。估计看此文的大部分是新手，稍微有点绕哈，尽量通俗易懂，不搞花里胡哨的名词
加入Contract
这里详细说明一下。之前Presenter是通过直接new出来的，现在给Presenter实现一个接口IPresenter，和View的接口放进一个契约类里面，并且加上一个基础接口BasePresenter和BaseView。
给presenter加接口的目的就是为了降低耦合，代码结构更加清晰
BasePresenter和BaseView。做的一些项目里面公共的功能，抽进去，然后Presenter实现IPresenter,然后不再new出mPresenter，而是在初始化的时候通过view的接口把presenter对象直接注入进Activity。这样得到的mPresenter再去调用add方法，add 定义在IPresenter接口里被Presenter重写，这样符合MVP独有的“点进去都是接口”的特点⊙﹏⊙‖∣。。。完事后继续调用model计算1+1，再通过view回调结果给界面。
这里的接口实现接口有点类似于Adapter设计模式 在Framework用的比较多，这里不做拓展，有兴趣的可以百度下
代码结构如下，
包结构
view（Activity）
契约类
基础的Presenter接口
View的基础接口
presenter媒介
model层没做改动，就不贴了。
然后是计算结果
结果
然后按照惯例，看一波美女。
图片发自简书App
作者：网恋被骗8000块
链接：https://www.jianshu.com/p/3e9509c53ae7
随时随地看视频
