Android 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基础架构示例)
  • 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层和业务层可以分别进行单元测试;最后是可维护性和可扩展性,由于架构的引入,虽然代码量有了一定的上升,但是由于界限非常清晰,各个类职责都非常明确且单一,后期的扩展,维护都会更加容易。有了这个架构之后,我们再回头看下之前的实现是不是有很多不足,没有关系,那么接下来就是在项目中进行实践的时间了。

时间: 2024-10-10 01:32:10

Android MVP架构分析的相关文章

Qualcomm Android display架构分析

Android display架构分析(一) http://blog.csdn.net/BonderWu/archive/2010/08/12/5805961.aspx http://hi.baidu.com/leowenj/blog/item/429c2dd6ac1480c851da4b95.html 高通7系列硬件架构分析 如上图,高通7系列 Display的硬件部分主要由下面几个部分组成: A.MDP 高通MSM7200A内部模块,主要负责显示数据的转换和部分图像处理功能理,如YUV转RG

开源项目Philm的MVP架构分析

前言 最近一直在研究ChrisBannes的开源项目Philm,其整体架构是一套MVP的实现,因为自己也确实没有遇到过整个项目利用MVP搭建的架构,看到的更多是一些代码片段,这里就探讨Philm是如何结合Android实际问题来实现一种MVP架构,如有分析不准确的地方,欢迎指出,大家一起探讨. 项目地址:https://github.com/Juneor/philm Philm项目运行效果图(典型的Material Design风格): 1.简单谈一谈MVP 在无任何模式下的开发时,Activi

【理论】【转】App工程结构搭建:几种常见Android代码架构分析

关于Android架构,因为手机的限制,目前我觉得也确实没什么大谈特谈的,但是从开发的角度,看到整齐的代码,优美的分层总是一种舒服的享受的. 从艺术的角度看,其实我们是在追求一种美. 本文先分析几个当今比较流行的android软件包,最后我们汲取其中觉得优秀的部分,搭建我们自己的通用android工程模板. 1. 微盘 微盘的架构比较简单,我把最基本,最主干的画了出来: 第一层:com.sina.VDisk:com.sina(公司域名)+app(应用程序名称) . 第二层:各模块名称(主模块VD

Android应用架构分析

一.res目录: 1.属性:Android必需: 2.作用:存放Android项目的各种资源文件.这些资源会自动生成R.java. 2.1.layout:存放界面布局文件. 2.2.strings.xml:字符串资源文件: 2.3.colors.xml:颜色资源文件: 2.4.dimens.xml:尺寸资源文件: 2.5.drawable-ldpi,drawable-mdpi,drawable-hdpi:分别是小.中.大三种尺寸图片文件. 3.使用: 3.1.访问资源: 1.使用:@资源类名/资

Android MVP 架构一 View与Presenter

View:主要负责界面的显示及跟数据无关的逻辑,比如设置控件的点击事件等 Presenter:主要负责View与Model的交互 Model:数据部分 ------- MVP的核心是: View层不持有Model层对象任何引用,当然参数里面和临时变量里可以有Model层对象,只持有Presenter层对象引用,任何需要更新或者操作数据的,都间接通过Presenter对象去操作数据.而Model层想要操作View层是无法实现的,必须通过Presenter层. Presenter层持有View层对象

Android官方MVP架构解读

综述 对于MVP (Model View Presenter)架构是从著名的MVC(Model View Controller)架构演变而来的.而对于Android应用的开发中本身可视为一种MVC架构.通常在开发中将XML文件视为MVC中的View角色,而将Activity则视为MVC中的Controller角色.不过更多情况下在实际应用开发中Activity不能够完全充当Controller,而是Controller和View的合体.于是Activity既要负责视图的显示,又要负责对业务逻辑的

如何更高效的使用MVP以及官方MVP架构解析

转载请标明出处: http://blog.csdn.net/dantestones/article/details/51445208 Android mvp 架构的自述中我简单的介绍了mvp,以及怎么写mvp.我自己也将mvp运用到了项目中,其实mvp并没有固定的写法,正确的去理解架构的思想,都可以有自己独特的mvp写法.git上也有很多例子,比如google的android-architecture,simple哥的Android 源码设计模式解析与实战中也有mvp的讨论.这里参考了simpl

MVP架构-Android官方MVP项目和响应式MVP-RxJava项目架构分析对比解读

介绍 MVP这个架构一直是Android开发社区讨论的焦点,每个人都有自己的分析理解众说纷纭.直到GitHub上Google官方发布用MVP架构搭建的项目.感觉是时候分析了. MVP架构简介 这不是本文重点,所以摘抄自李江东的博文 MVP架构简介 对于一个应用而言我们需要对它抽象出各个层面,而在MVP架构中它将UI界面和数据进行隔离,所以我们的应用也就分为三个层次. View:对于View层也是视图层,在View层中只负责对数据的展示,提供友好的界面与用户进行交互.在Android开发中通常将A

Android中的MVP架构初探

说来惭愧,MVP的架构模式已经在Android领域出现一两年了,但是到今天自己才开始Android领域中的MVP架构征程.闲话不多说,开始吧! 一.架构演变概述 我记得我找第一份工作时,面试官问我"android是否属于MVC架构模式,简述一下".确实,Android的整体设计结构就是MVC的设计模式,在J2EE的开发中,使用的也是MVC模式,MVC模式是一个经典,经历了几十年的考验.Android项目中的MVC架构: View:是应用程序中处理数据显示的部分,对应于layout文件下