专栏名称: Java爱好者
分享android开发编程知识和相关技术应用
51好读  ›  专栏  ›  Java爱好者

我为什么不再推荐用RxJava

Java爱好者  · 公众号  ·  · 2019-08-28 09:48

正文

作者: W_BinaryTree

链接: https://juejin.im/post/5cd04b6e51882540e53fdfa2

距离上一次更新也有一段时间了,其实这篇文章我早就想写,碍于一直没来得及总结(懒)。所以一直没有成文。来总结一下我RxJava遇到的坑,或者说我为什么不在推荐使用RxJava。相信熟悉或者关注我的朋友,绝大多数都是因为RxJava。所以看到这个标题你已经会惊讶。作为RxJava坚定的拥护者,或者说自干五?为什么突然不再支持RxJava了呢?

先讲讲历史

在我的文章中已经讲过很多次RxJava诞生之初就是因为异步。再后来借鉴LINQ的思想借用Monad的力量使得 Rx可以使用操作符进行组合将各种复杂的请求简单化。可以说,RxJava的设计初衷就是围绕着Asyhconization和Composition。当年的Netflix也是为了增加服务器的性能和吞吐量来编写RxJava并开源。才使得RxJava问世。详细关于这段可以参考我的知乎回答:你会在实际工作中使用 rxjava 吗?( https://www.zhihu.com/question/53151203/answer/164427549

再聊聊异步

在那个RxJava刚刚火爆的年代,那是一个荒蛮的年代。我们在异步方面资源匮乏,手头仅有ThreadPool,AsyncTask和Handler这些基础封装的异步库。所以当我们看见RxJava这个新奇的小玩意,当我们看到异步还可以这么简单,轻而易举的解决Concurrency问题。我们当然如获至宝。


而我们现在选择就更多了,无论是Java 8本身提供的 CompletableFuture 。还是后起之秀Kotlin上的 Coroutine ,还有Android 上官方提供的 LiveData (这里说下:虽然本质上线程管理仍需用户自己,但是常见的比如Room数据库,Retrofit等等都有现成的LiveDataAdapter,实际上并不需要我们过多操心线程问题)。相比之下,RxJava优势并不那么明显,相反劣势却很突出。

RxJava 门槛太高

相信多数Android开发者并没有了解过或者说深入了解过(我自己也没深入了解过)函数式相关的知识。但是如果不了解这些,那么而几乎可以说不可能融会贯通RxJava的一些概念。举个例子,一个很著名的Googler: Yigit Boyar 。也就是每次IO的那个大胡子,他的代表作有很多。比如RecyclerView,再比如Architecture Component。这样一个Android界名人,水平怎么也有平均以上。但是他在实现LiveData和RxJava适配的时候,同样出现了由于理解上出的问题,造成错误的实现方式。


RxJava的门槛过于高,就连我自己推广这么久,自己也不敢说对RxJava了解有多深刻。经常在常见操作符的使用中出现了或多或少的unexpected behavior。再者,无论国内国外的RxJava教程水平都参差不齐。新手很难鉴别哪些人说的是对的哪些人说的是错误的。在这样鱼龙混杂的条件下学好这个高门槛的异步库更是变得难上加难。很多教程在自己没有精通的情况下,很容易误导其他人(包括我自己的文章)。

投入高,收获少

虽然这点存疑,因为我自己钻研RxJava之后确实觉得收获很大,尤其是经由RxJava窥探了函数式的大门。但是功利的看,RxJava在解决异步处理这个问题上,的确是投入高,收获少。异步问题是Android开发必不可少的一个环节,可以说掌握异步应该是成为入门Android开发的敲门砖。而RxJava归根到底是通过响应式的方式配合Monad来解决异步问题。但是仅仅为了解决异步问题,学习并精通RxJava并不是必不可少的。相反,精通RxJava需要大量时间和精力,在现在异步编程逐步完善的情况下,完全没有必要。

你永远无法预测你同事的RxJava水平

上面几点可能有点抽象,而这点和接下来的几点都是我在实际工作中遇到的实际情况。首先就是你并不能预测或者要求你的同事RxJava到达什么样的水平。我之前的公司使用了一个简单的类redux框架。其中RxJava是核心部分,他承载了中间render层和view层的连接。具体关于这个架构可以看我这里的项目实例:Twivy( https://github.com/wbinarytree/Twivy )。在Review同事的代码之后,我才发现RxJava还能这么玩?


各种奇思妙想的作用让我不得不佩服法国同事的丰富想象力。而这些错误使用就像一颗颗定时炸弹一样埋在代码里。随时可能爆炸。但是反过来一想,并不是所有人都像我一样喜欢研究RxJava。他们可能仅仅是因为使用了这个架构而接触Rx。而RxJava的掌握并不是一个Android开发的必要条件。他完全可以一点RxJava也不会也成为一个优秀的Android Developer。

RxJava的行为并不可预

RxJava还有一大毛病就是光看方法名你很难知道他的真正意思。在初学RxJava时候,两个一直纠缠不清的问题就是 map flatMap 的区别。还有 flatMap concatMap 的区别。简单的讲 map 是一对一, flatMap 是一对N的map然后在进行 flatten 操作。还有些教程直接写出 flatMap 无序, concatMap 有序。其实这些都只是简单总结,而实际的行为照着相差甚远。比如 flatMap 在第一个error的时候会不会继续继续触发第二个?如果我想继续,将如何操作?再比如 concatMap 在遇到第一个 Observable 不会中断的时候,怎么继续下一个?


这些都几乎是要看源码或者做多次实验对比才能得出结论的问题,而实际工作中并不想去因为这个工具而去浪费太多时间,得不偿失。但是如果不做,就像前文提到的定时炸弹一样。上线直接增加错误几率。

RxJava太容易出错

Uncle Ben 说过:

with great power comes great responsibility. RxJava就是这样。在简单易用的同时他太容易被滥用了。我在实际工作中碰到的例子:


val stationId = "5bCP6Iqx"
val statoin:Observable = staionRepo.getStationById(stationId)
val stationLine:Observable = station.flatMap{station ->stationRepo.getLine(station)}

return Observable.merge(station.map






请到「今天看啥」查看全文