最近这一年,RxJava/RxAndroid 实在太火了。火到了什么程度?🔥到16年之后每一个星期的Android Weekly都会至少发布两篇以上的Rx相关的文章(没有订阅的同学建议可以订阅一下,每个星期的推送都可以学到新的知识)。
RxJava之所以被大家认为是一个优秀的异步library,很大一部分原因是其简洁的链式调用,还有方便的线程切换。这篇文章我打算简单的介绍一些RxJava的use case,在哪些情况下,使用RxJava会有优势?这篇文章的前提是假设你已经使用过RxJava,知道一些Rx的operator的前提下。如果还没使用过/了解过的同学建议先看看
1.RxJava基础,操作符《RxJava Essentials》
2.抛物线大牛的神作《给Android开发者的RxJava详解》
那么,RxJava到底有什么优势呢?在哪些情况下使用会更方便呢?我们先从一些例子入手:
1.用flatmap()解决nested callback/ callback hell
在前段调用后端的API时,经常会出现回调嵌套的情况。假设我们有两个API,queryA 和 queryB. 并且queryB的运行依赖于queryA的结果。那么我们的程序在一般的情况下可能是这个样子。想象有如下的代码:
是不是感觉非常不舒服?假如嵌套的API再多几层,那么这将是个灾难。一个人开发的时候可能不觉得有什么问题,但是可以想象做code review或者新入项目组的同事看到你这复杂的嵌套时的表情。
是时候让flatmap出现啦!让我们把程序稍微改造一下,在Server类里面把makeRequest的方式变成RxJava的Observable的形式(我会在例子之后解释为什么要用flatmap()):
看上去好像没觉得有都简洁是么?你等着我给你看看假如嵌套多几层之后:
看到了么?在RxJava的链式调用下,所有之前需要嵌套的地方都被flatMap()隔开了。代码可读性大大增加!假如你的IDE支持java 8的话,你可以体验更美妙的事情:lambda!
在抛弃了可恶的匿名类之后,代码更加简洁了!
此时此刻,想必在看到你新重构的代码之后,表情是这样的:
看来很多同学都不太理解为何要用flatmap来解决嵌套回调。那咱们就深入点:
flatMap()究竟是用来干嘛的?简单的说,flatmap把一个Observable变成多个Observable,然后把得到的多个Obervable的元素一个个的发射出去。
假设你有一个API queryA,用这个query可以通过一个userID得到一个指定用户的所有关注的明星的userID(但是原始数据只是String),你需要把这些userID一个个打印出来。
那么我们在调用queryA的时候就已经构建了一个Obervable了,我们暂且叫他O1.在O1每发射结果的同时,我们需要调用把返回的String结果变成另一个Observable,O2,O2含有所有的明星userID,并且一个个发射出去。代码例子:
大家可以看到,新的observable2是一个JsonObject类型的。因为在第三行注释之后,我们返回了一个(可以是多个)新的包含所有userID的observable,RxJava会将这个(或者多个)Observable平铺发射.
或者大家可以参考抛物线大神文章中的学生和课程的例子 大概在文章的中间
总之flatmap最核心的功能大家可以理解为:转换,可一个Obervable转换成多个Observable,再讲结果平铺发射。
在我们的例子中,是一个observable(O1)变成另一个observable(O2),是一对一的关系,因为queryA只会返回一个String s的结果,所以我们只会将一个observable(O2)平铺并发射。
所以这和nested callback有什么关系呢?
关系大了!
再想想,我们的刚刚做的和nested callback不同的地方差在哪里?唯一不通的地方是在获取所有明星userID的时候,我们是一个同步的操作,也就是说userID全部都包含在queryA返回的结果里面。我们用同步的方法把其封装成一个JSONArray.
假如queryA返回的只是用户关注明星userID的url呢?假如在第二部我们需要再做一步API call呢?
是的,就算我们还需要一步API call,程序的结构还是一样的:
还是那句话:flatmap最核心的功能大家可以理解为:转换,可一个Obervable转换成多个Observable,再将结果平铺发射。
至于转换的Observable里面的操作是同步还是异步,我们不需要去过多的思考,Rxjava已经完美的解决了。
2.使用RxJava把不同异步操作合并
假设你有十个异步任务,程序需要在这十个异步任务完成之后发送一个通知。通常的做法可能是使用java里面的countdownlatch来实现。
但是问题是,countdownlatch是没有上下文的,也就是说,它只支持当countdown数到了的时候启动通知,而你并不能确定是哪一些任务完成了。当任务数,种类都增多的时候,麻烦就来了。假如你有很多个不通的任务组,每组又有若干个任务,这时候管理每个组的countdownlatch就显得非常麻烦。
而RxJava的mergeWith() 方法完美的解决了这个问题,把不同的任务merge到一起,在所有任务执行完毕并且发送完结果之后,在同一个subscriber里面发送onComplete()。我们还是使用上面的代码,假设我们有六个query:
看到了吧!让若干Observable互相merge,并且共享同一个subscriber,那么我们便可以在subscriber的onComplete()里面执行我们本来要使用countdownlatch发送的通知。
哈哈爽!
今天就暂时更新到这里,下周我会继续介绍RxJava的开山始祖Netflix(现在好像已经跳槽去FB了)的Ben Christensen在GotoConference大会上介绍的在Netflix中使用RxJava的一个例子。