转：Android官方MVP架构示例项目解析

转自： http://www.infoq.com/cn/articles/android-official-mvp-architecture-sample-project-analysis

 

做者 吕英斌 发布于 2016年4月29日 | 注意:GTLC全球技术领导力峰会 帮助深具远见卓识的技术人审时度势，提高领导力！讨论

• 分享到： 微博 微信 Facebook Twitter 有道云笔记 邮件分享
• 稍后阅读
• 个人阅读清单

 

前段时间Google在Github推出了一个项目，专门展现Android引用各类各样的MVP架构，算是官方教程了。趁着还新鲜，让咱们来抛砖引玉一探究竟，看看在Google眼里什么样算是好的MVP架构。

App架构在Android开发者中一直是讨论比较多的一个话题，目前讨论较多的有MVP、MVVM、Clean这三种。google官方对于架构的态度一直是很是开放的，让开发者自主选择组织和架构app的方式，指望能留给开发者更多的灵活性。

因为没有一套权威的架构实现，如今不少App项目中在架构方面都有或多或少的问题。第一种常见问题是没有架构，需求中的一个页面对应项目中的一个activity或一个fragment，全部的界面响应代码、业务逻辑代码、数据请求代码等等都集中在其中。第二种常见的问题是架构实现的不断变化，不断在各类架构间摇摆，一直找不到一个适合本身的架构。

就在近日，google在官方示例中给出了一系列不一样架构的app实现，这对于一直困惑于到底该用何种架构的android开发者来讲确实是福音，开发者只要根据本身项目的状况，在不一样的实现中选择一种便可，固然google也明确表示了这些示例只是用来作参考，而并非要为了当作标准，下面先为你们简单介绍下此项目。

项目介绍

Google把这个项目命名为：Android架构蓝图。

项目地址为：https://github.com/googlesamples/android-architecture

下面的内容引用自项目说明：

项目目的是经过展现各类架构app的不一样方式来帮助开发者解决架构问题。项目中经过不一样的架构概念及方式实现了功能相同的app。你能够用示例来当作参考，或是干脆拿来当作建立app项目的基础。项目中，但愿你们能把关注点集中到代码结构、总体架构、可测试性、可维护性这四个方面。固然实现app有不少种方式，千万不要把它当作定式。

项目中有哪些示例

目前已经完成的示例有

• todo-mvp（mvp基础架构示例）

   

  相关厂商内容

  滴滴出行iOS客户端架构演进之路！

  微信客户端如何应对弱网络！

  函数式编程中的Swift与Swift中的函数式编程！

  AWS Webinar 5月24日在线课堂|利用AWS Lambda建立应用

  国际范 最前沿 不容错过的容器技术盛会

   

  相关赞助商

  GMTC全球移动技术大会2016年6月24日-25日，北京，点击了解详情！

   

• todo-mvp-loaders（基于mvp基础架构项目，获取数据部分使用了Loaders架构）

• todo-mvp-databinding（基于mvp基础架构项目，使用了数据绑定组件）

仍在进展中的示例有

• todo-mvp-contentproviders（基于mvp基础架构项目，使用了Content Providers）

• todo-mvp-clean（基于mvp基础架构项目，使用了clean架构的概念）

• todo-mvp-dagger（基于mvp基础架构项目，使用了dagger2进行依赖注入）

如何进行选择

这个仍是须要开发者本身来作决定，每一个项目的说明文件中都说明了该实现的特性。app规模、团队情况、维护工做量的大小、平板是否支持、代码简洁程度偏好，这些都会影响你的选择。

 

到了这里，想必你们都很想一探究竟了，到底官方示例是如何实现的呢？仍是那句话，源码面前，了无秘密。为了可以更好的理解官方mvp架构实现，下面咱们从源码的角度来分析todo-mvp（mvp基础架构示例）的实现。咱们先从项目的总体组织方式开始，再看项目究竟使用了哪些组件，最后固然是最重要的具体mvp的实现方式。

源码分析

项目代码组织方式

项目含一个app src目录，4个测试目录，分别是androidTest（UI层测试）、androidTestMock（UI层测试mock数据支持）、test（业务层单元测试）、mock（业务层单元测试mock数据支持）。src目录的代码组织方式彻底是按照功能来组织的，功能内部分为xactivity、xcontract、xfragment、xpresenter四个类文件(x表明业务名称)。

平时用到较多的另外一种组织方式是按照类型，好比按照activity、adapter、fragment、contract、presenter进行划分，不一样的类文件分别放到不一样的目录中，笔者以为两种方式没有什么太大的区别，彻底看我的喜爱了。

组件使用

因为项目是基于gradle进行编译的，因此咱们能够从build.gradle文件看到项目依赖的全貌。

Guava

项目中使用到了Guava库（https://github.com/google/guava），该库是Google在基于java的项目中都会引用到得一个库，库中包含大约14k的方法数，是个很大的库，其中包含了集合、缓存、并发、基本注解、字符串处理、io处理等等。项目中使用Guava库主要是处理null这种不安全的状况，由于通常咱们在使用有可能为null的对象时，通常会增长一次判断，代码以下：

而若是有Guava的时候，能够经过以下方式

这样面对空的时候，就不用再多写不少代码了，确实是方便了不少。可是不建议为了null安全直接引入如此大的一个库，由于咱们都知道android apk的65k方法数限制，若是要用的话能够把源码中涉及到得部分直接拿出来用。固然Guava中还有不少重要的功能，其余功能读者能够自行研究，关于Guava就先到这里了。

测试相关组件

示例项目在可测试方面作的很是好，因为对视图逻辑(view层)和业务逻辑(presenter层)进行了拆分，因此咱们就能够对UI、业务代码分别进行测试。为了进行UI测试引入了Espresso，为了对业务层进行单元测试引入了junit，为了生成测试mock对象引入了mockito，为了支撑mockito又引入了dexmaker，hamcrest的引入使得测试代码的匹配更接近天然语言，可读性更高，更加灵活。

项目MVP实现方式

这节咱们就具体来看官方示例究竟是如何实现mvp的。这里咱们先看下整体的轮廓，关于项目中业务代码咱们仅列出了任务详情页（taskDetail）的相关类，其余业务代码相似。

基类

咱们首先来看两个Base接口类，BasePresenter与BaseView，两类分别是全部Presenter与View的基类。

BasePresenter中含有方法start(),该方法的做用是presenter开始获取数据并调用view中方法改变界面显示，其调用时机是在Fragment类的onResume方法中。

BaseView中含方法setPresenter，该方法做用是在将presenter实例传入view中，其调用时机是presenter实现类的构造函数中。

契约类

与笔者以前见到的全部mvp实现都不一样，官方的实现中加入了契约类来统一管理view与presenter的全部的接口，这种方式使得view与presenter中有哪些功能，一目了然，维护起来也方便，实例以下

activity在mvp中的做用

activity在项目中是一个全局的控制者，负责建立view以及presenter实例，并将两者联系起来，下面是activity中建立view及presenter的代码

(点击放大图像)

咱们能够从上面看到整个建立过程，并且要注意的是建立后的fragment实例做为presenter的构造函数参数被传入，这样就能够在presenter中调用view中的方法了。

mvp的实现与组织

实例中将fragment做为view层的实现类，为何是fragment呢？有两个缘由，第一个缘由是咱们把activity做为一个全局控制类来建立对象，把fragment做为view，这样二者就能各司其职。第二个缘由是由于fragment比较灵活，可以方便的处理界面适配的问题。咱们先看view的实现，咱们只挑一部分重要的方法来看

(点击放大图像)

上面能够看到setPresenter方法，该方法继承于父类，经过该方法，view得到了presenter得实例，从而能够调用presenter代码来处理业务逻辑。咱们看到在onResume中还调用了presenter得start方法，下面咱们再看presenter的实现

(点击放大图像)

presenter构造函数中调用了view得setPresenter方法将自身实例传入，start方法中处理了数据加载与展现。若是须要界面作对应的变化，直接调用view层的方法便可，这样view层与presenter层就可以很好的被划分。

最后还剩下model层实现，项目中model层最大的特色是被赋予了数据获取的职责，与咱们日常model层只定义实体对象大相径庭，实例中，数据的获取、存储、数据状态变化都是model层的任务，presenter会根据须要调用该层的数据处理逻辑并在须要时将回调传入。这样model、presenter、view都只处理各自的任务，此种实现确实是单一职责最好的诠释。

总结

到这里咱们就基本分析完了，咱们再来总体看下官方的实现方式有哪些特性。

首先是复杂度，咱们能够从上面的分析看出总体的复杂度仍是较低的，易学的；而后是可测试性，因为将UI代码与业务代码进行了拆分，总体的可测试性很是的好，UI层和业务层能够分别进行单元测试；最后是可维护性和可扩展性，因为架构的引入，虽然代码量有了必定的上升，可是因为界限很是清晰，各个类职责都很是明确且单一，后期的扩展，维护都会更加容易。有了这个架构以后，咱们再回头看下以前的实现是否是有不少不足，没有关系，那么接下来就是在项目中进行实践的时间了。