代码重构,MVP+RxJava+Retrofit

1. Android开发框架的选择


我们知道原生Android开发已经是一个基础的MVC框架,其中xml部分被认为是View层,Activity层是Control层,所以在项目刚开始开发的时候并没有遇到太多问题。

但是在实际项目中,Activiy层除了做C层的工作以外,还会有承担部分View层的工作,这样导致了很容易出现一个Activity的超级类,维护起来十分复杂。目前我们自己的项目比这个情况更糟糕,Activity一个类直接写了所有的业务逻辑,导致这个类错综复杂,没有任何层级划分,代码阅读和修改都十分的困难。

需要解决这些问题,需要做2个维度的解耦工作

1.分层

2.模块化

两种的方式最终目的是一样的,只不过一个是纵向层面上的解耦,一种是横向层面上的解耦。

目前android主流架构中MVC已经不太适用了,比较流行的是MVP和MVVM,但是MVVM需要用到谷歌的databinding,而目前这部分技术不太成熟,有许多问题。而MVP的架构已经足以满足我们的需求和后续扩展了,所以选用MVP架构。


2.分层架构MVP和模块化的实现


MVP实际上是在MVC的基础上实现的,在android端具体思路就是将activity层作为一个view层剥离出来,Presenter层作为中间层,主要做的是一些逻辑上的处理和消息的传递,Model用来存储数据。


代码重构,MVP+RxJava+Retrofit_第1张图片

这是一个比较典型的MVP架构的结构图,用户事件由View层响应,然后通过presenter进行消息传递,最后从model层获取数据,再从presenter层返回给view层做数据刷新。

具体如何实现呢,下面将用代码直接说明:


代码重构,MVP+RxJava+Retrofit_第2张图片

通过包结构,我们可以看一个MVP结构的大致划分,主要有接口有。

View层接口:ICreditView


代码重构,MVP+RxJava+Retrofit_第3张图片

主要是一些进行UI刷新和状态的处理。

View层的具体实现

代码重构,MVP+RxJava+Retrofit_第4张图片

Activity里面包含了2个类,一个是View层的对外接口ICreditView,一个是P层的CreditPresenter。

从上面的所有代码可以看到,View层将自己的接口ICreditView交给了Presenter, 而Presenter层持有Model层的也只是一个接口。通过Presenter层将业务层与展现层隔离了开来,这样的好处是什么?

我们知道接口的一个作用通常是用来抽象行为,对外部屏蔽实现细节。所以对于View层来说,业务细节被屏蔽了,对业务层来说,展示细节被屏蔽了。而对于处于中间的Presenter层来说,它就像一个接口拼装器,把View层发出的请求传递给业务层,把业务层返回的数据又送还给View层展示,至于前后两端怎么实现的,它才不用关心。

接口的第二个作用是可以用来切换实现。我们先看下面的代码。

Model层接口:ICreditDataSource

代码重构,MVP+RxJava+Retrofit_第5张图片

主要是一些数据存储和数据提取的处理。

我们可以通过实现这个类来实现一些我们需要的model数据

代码重构,MVP+RxJava+Retrofit_第6张图片

这里的数据都是本地的,获取和存储都没有任何问题,但是在我们实际工作中,很多数据是从我们的服务端获取的,这在做需求的时候就会有个问题。服务端的同学还没来得及做好相关的接口,我们可以直接自己定义一个Test的Model实现类,这样就可以先做好逻辑和界面,等服务端做好后,再直接进行联调,就OK了。

类似的应用场景其实有非常非常多,这里我们就看到了使用接口解耦的一个好处了,不仅把业务层和展示层解耦开来,还把Android开发同其它的一切的外部数据依赖都解耦开来。

到现在为止一个基于MVP简单框架就搭建完成了,但其实还遗留了一个比较大的问题。

我们从Model层获取数据,大部分都会是一个耗时操作,而android又规定主线程不能做耗时操作和网络请求,否则会出现ANR甚至直接报错。

正常情况下,我们想要做耗时操作,都会启动一个线程,然后完成后做一次线程切换,回到主线程做处理,按照android给我们的一些方式,可以用Handler,用可以用runOnUiThread,例如这样:

代码重构,MVP+RxJava+Retrofit_第7张图片

这里其实看起来还算OK,但是存在2个隐患。

1、多次调用这个方法,会多次启动线程,造成不必要的资源浪费

2、如果线程多次切换,这样写就会有非常多的嵌套,十分影响代码体验。

好在有了RxJava ,可以比较方便的解决这个问题。


3. 使用RxJava来进行线程控制


RxJava是一个天生的做异步的工具,他的详细介绍可以去看扔物线大神的这篇介绍,写的非常详细,很适合初次学习RxJava的同学去看。

http://gank.io/post/560e15be2dca930e00da1083

还是回到刚才的那段线程切换的代码,如果我们需要用RxJava做要怎么做呢?

代码重构,MVP+RxJava+Retrofit_第8张图片

简单解释下,mDataSource就是我们的Model层,Schedulers.io是RxJava提供的IO管理线程,这样就解决了我们之前的第一个问题,线程被反复调起浪费资源的问题。同时AndroidSchedulers.mainThread是android线程,我们可以反复在他们之间切换,这样按照RxJava的书写规范,完全就可以避免多层嵌套的问题。

当然RxJava的使用场景远远不止这些。下面列出了一些常见的RxJava的常用场景,其实还有更多的其它功能等待着大家去挖掘。

1、取数据先检查缓存的场景

2、需要等到多个接口并发取完数据,再更新

3、一个接口的请求依赖另一个API请求返回的数据

4、界面按钮需要防止连续点击的情况

5、响应式的界面

6、复杂的数据变换

4、Retrofit的使用


Retrofit是一个基于okHttp的网络框架,他的优点在于基于注解的接口式编程,不用写具体的实现,这样更进一步的解耦了Presenter层和Model层。但是需要使用到这个框架,有一些前提条件,就是服务端必需支持REST风格。我们自己的服务端接口目前并没有对这方面进行支持,但是调用第三方的接口中,Face++对REST进行了支持,而且老的接口使用的是asyn-http,这个是一个基于httpClient的框架,谷歌在6.0以后放弃了对这部分的支持,所以这次重构也对这部分代码做了一次重构。

具体的retrofit的使用可以网上搜到,有很多相关的教程,这次算是一次项目中的实践,可惜的是我们的服务端目前没有时间做出对REST的支持,后续如果支持到,会更多的研究里面很多的细节性问题了。

你可能感兴趣的:(代码重构,MVP+RxJava+Retrofit)