从0开始写一个App（一）关于 Android MVP

2018-12-12 本文已影响37人 36360851f4da

前情提要：前一篇文章写道，本人目前两年半工作经验，就职于手机公司，做过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用的比较多，这里不做拓展，有兴趣的可以百度下

代码结构如下，