我可以看到RX对Android和UI事件处理有好处。 我正在努力了解 RX 在后端提供了什么好处。
RX Java是为后端处理而设计的，还是这个概念走得太远了？
实际上，RxJava最初是为了解决服务器端问题而实现的。反应式扩展起源于.NET world，并由Netflix移植到Java作为后端。RxJava在Android上采用之前几年就成为服务器端Java编程的一部分。
当时，异步和非阻塞处理被证明可以大大提高服务器性能。可以使用回调来实现这一点，但回调不能很好地组合并导致回调地狱。RxJava以其函数式调用链风格提供了一个(好的)解决方案，并开始被采用。
然后它传播到Android来处理网络调用或UI事件。当我在Android上使用和享受它时，我总是发现RxJava在Android中比在服务器中更不合适。恕我直言，由于总体设计在概念上更接近其他服务器技术，即使我知道在 .NET 世界中从一开始就在客户端使用了反应式扩展。但也因为Android中的RxJava使用有它的缺陷。如果您不跟踪订阅，则很容易泄露Context。而且你必须在几乎所有地方添加.observeOn(AndroidSchedulers.mainThread())，你不时忘记并导致崩溃。我敢打赌，这是带领Android团队对Livedata on Architecture组件的观察者模式有自己的看法的原因。
除了解决回调问题，RxJava还为开发人员提供了：
- 观察者模式：这种模式非常适合将数据公开给其他模块。它给出了生产者和消费者之间的契约，具有定义和标准的行为，终止的处理和控制生产者的方式(取消订阅，背压)。当然，你不需要RxJava来实现这种模式，但RxJava把它带到了另一个层次。 错误处理
- ：在异步系统中，错误处理很棘手。
- 一套完整的算子：一百多个算子来转换、过滤和组合流。当你要执行数据操作时，通常后端围绕它，RxJava将你的代码归结为几个标准的显式运算符。
总而言之，RxJava非常适合后端处理，甚至比Android恕我直言。你可以在这里找到更多关于为什么Netflix在Java中实现反应式扩展以及他们的后端有什么好处。
至于说服务器端工程师是否需要它，我会说这不是必需的，但知道它会大大增强你的工具箱。如今的趋势越来越异步，越来越多的中间件、库和框架只提供异步 API。例如，Couchbase Java数据库API基于RxJava。加上反应式扩展不仅是Java，您将能够在大多数语言中利用这些知识。
我在API网关和更传统的微服务中使用RxJava。Rx 使并行计算(或 I/O 调用)具有局部和全局约束变得微不足道，而且我还没有找到同样有效的非响应式解决方案。
也就是说，没有微服务是孤立的，都需要联系其他东西 - 而 retrofit+rx 使这变得微不足道。
根据我的经验，测试并不是特别复杂;你确实需要一些额外的工具，但这是一次性投资。
我注意到大多数 rx 教程都专注于向您展示如何subscribe;我认为这是错误的抽象级别。IMO运营商级别的思考和测试更加有用。