我对 Android 中的 EventBus 和 RxJava 之间的区别感到困惑。我需要为我的问题实现其中一个，即在完成某些更改时通知某些组件，以便它们可以更新其状态。
另外，我读到 EventsBus 已经被 RxJava 弃用了，我不知道这个信息是否真实。
【问题讨论】：
EventBus 和RxJava 的性质不同。
EventBus 只是一个bus，顾名思义——它提供了订阅和发布事件到“总线”的机制，而不用关心接线是如何完成的，这个“总线”实际上是什么等等. 在 Android 的上下文中，EventBus 只是处理发送和接收 Broadcast 消息的一种更简单的方法，并且样板更少。
另一方面，RxJava 比这强大得多。是的，您可以订阅和发布事件，但是您可以更好地控制流程 - 频率、所有事情发生在哪个线程上等。RxJava（在我看来）的主要功能是您可以操纵正在发布的数据非常简单，使用其中的一些 operators。
总而言之 - 如果您只关心发布一些事件并在收到时执行一些操作 - 您可能最好使用两者中最简单的一种，即某种 Bus，甚至是普通的旧 @987654332 @s。如果您还将受益于转换数据、处理线程或简化错误处理 - 选择RxJava 方法。请记住，RxJava 通常具有陡峭的学习曲线，因此需要一些时间来适应它的概念。
【讨论】：
EventBus 的任何具体缺点——它总是归结为你的任务。正如我在回答中所说 - 如果您只需要发送一些/响应一些事件 - 总线将完美地完成工作。如果您的任务比这更复杂 - 也许值得探索其他解决方案。诀窍是为任务找到合适的工具，因此如果您只需要 1-2 个 BroadcastReceivers，就无需将自己推入 RxJava ...
RxJava 的强大之处在于它的运算符 - 在这里查看它们：reactivex.io/documentation/operators.html。如您所见，您可以超级轻松地转换、过滤、链接、缓冲、处理错误以及做很多其他事情。
要理解 RxJava，请考虑一个列表。今天，使用函数式方法（map、groupBy 等）可以轻松地操作列表，如转换、拆分、合并。 RxJava 使用相同的原则，只是它的主要目标不是列表而是流。 Stream 是异步的，通常是实时数据，例如 websocket 频道或在线电影。
事件总线来自于解耦类的需求，这些类在 Android 中往往与生命周期绑定。网络回调和 Activity 的视图作为实例的紧密耦合是导致大量空指针异常的原因。事件总线及其发布者-订阅者模式缓解了这个问题。
它是如何与 RxJava 混合的？ 首先，RxJava 包含了 Observable 模式。这里一个 Observer 监视一个 Observable 并在事件到达时做出反应。 Observable 有几个子类，其中 Subject 具有 Observable 和 Observer 的属性。由于它通过捕获事件并将其发布给订阅者来工作，因此它在技术上充当事件总线。
使用 RxJava 作为事件总线是否明智？不会。为了更简单的目的，RxJava 会引入不必要的复杂性。仅当应用程序确实操作流时才使用它。例如，将电影流中的帧和另一个流中的字幕配对。如果应用程序只是使用 REST API 并且需要将回调与活动/片段分离，那么事件总线就足够了。
【讨论】：
Live @Vesko 写道，RxJava 和事件总线的性质不同，可能用于解决不同的问题。尽管如此，在某些情况下，它们都可以解决同一个问题（尽管成本不同），这可能是许多人混淆这两个概念的原因。
RxJava 在概念上类似于不久前发布的 Android LiveData，为了更好地理解这些概念以及事件总线，我建议你阅读我的帖子。在这篇文章中，我回顾了这些概念，描述了我们应该使用一个而不是另一个的场景以及使用一个而不是另一个的优缺点。我认为它可能对你有用：
【讨论】：
如果您想从服务器获取数据并更新 UI，请使用 RxJava + Refrofit。如果在不获取数据的情况下更新 UI 或者做一些操作，EventBus 就足够了。
【讨论】：