关闭

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

标签: androidmvpandroid开发架构
276人阅读 评论(0) 收藏 举报


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

由于没有一套权威的架构实现,现在很多App项目中在架构方面都有或多或少的问题。第一种常见问题是没有架构,需求中的一个页面对应项目中的一个activity或一个fragment,所有的界面响应代码、业务逻辑代码、数据请求代码等等都集中在其中。第二种常见的问题是架构实现的不断变化,不断在各种架构间摇摆,一直找不到一个适合自己的架构。

就在近日,google在官方示例中给出了一系列不同架构的app实现,这对于一直困惑于到底该用何种架构的android开发者来说确实是福音,开发者只要根据自己项目的情况,在不同的实现中选择一种即可,当然google也明确表示了这些示例只是用来做参考,而并不是要为了当做标准,下面先为大家简单介绍下此项目。

项目介绍

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

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





源码分析

项目代码组织方式

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


0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:9541次
    • 积分:146
    • 等级:
    • 排名:千里之外
    • 原创:5篇
    • 转载:1篇
    • 译文:0篇
    • 评论:0条
    文章存档