EventBus 与回调，什么时候使用哪个？

Question

我有很多引发后台任务的活动；活动将在实现侦听器回调时将自身传入，以便后台任务可以在活动上引发事件。活动反过来可以在 UI 上显示一些内容来指示后台活动通过或失败。

或者，我可以使用EventBus，其中我让 Activity 将自身注册为侦听器/订阅者。我可以让后台任务在 EventBus 上引发事件，并且侦听该事件的 Activity 可以处理该事件。

其中一种相对于另一种有什么优势？你什么时候会使用其中一种而不是另一种？ （代码整洁？性能？注意事项？）

---

跟进 - 我最终使用了 EventBus。代码确实干净了很多，并且没有回调随处可见。 IDE（IntelliJ）认为

onEvent

方法没有被使用，所以我创建了一个注释

@Target({ElementType.METHOD})
public @interface EventBusHook {}

并将其放在我的

onEvent

方法上。然后 Alt+单击它并要求 IntelliJ 不要将其视为未使用。

@EventBusHook
public void onEvent(MyEventType myEventType){

Answer 1

我不同意@nnuneoi的回答。

事件总线只有一个优点：它允许在“不知道”彼此存在的组件之间进行通信。

还有几个缺点：

1. 组件通过对事件总线和特定事件类型的依赖而变得松散耦合
2. 上面#1中描述的耦合并不强
3. 上面#1 中描述的耦合并不明显
4. 事件总线比简单回调引入了性能开销
5. 如果事件总线对订阅者有很强的引用（例如GreenRobot的EventBus就是这种情况），那么未注册的订阅者将导致内存泄漏

考虑到所有这些缺点，简单的回调应该是默认的实现选择。

仅当不需要直接耦合或难以实现时才应使用事件总线。例如：

1. 将事件从

   Service

   发送到

   Activity

2. 独立之间交换事件

   Fragments

3. 应用程序范围的事件（例如用户登录/注销）

如果通信组件已经“意识到”彼此的存在，则它们不需要通过事件总线进行通信。

Answer 2

使用EventBus的好处：

• 你的代码看起来会更加干净
• 您的代码将变得更加模块化，这将允许您轻松地为代码创建测试用例
• 避免由于错误的对象引用而导致内存泄漏，这些引用会锁定对象并且不允许垃圾收集器清理它
• 一次可以有多个接收器，这很像广播
• 将多个接口简化为一个接口，EventBus
• 在接口类中，您需要重写继承类中的每个方法。使用 EventBus，您可以只监听您真正想要的事件

但不好的是你可能会对函数声明有点头疼，因为 IDE 无法帮助你自动完成。

我的建议是，如果您发现必须创建自定义侦听器，那么请考虑 EventBus，对于您的大多数（如果不是全部）需求/案例来说，它可能是更好的选择。

无论如何，这都是你的选择=）

Answer 3

您应该检查您的事件在语义视图上是否全局唯一。订阅者要么对该事件感兴趣，要么不感兴趣。如果不是，他就不应该订阅。

如果确实存在发布者-订阅者关系，则事件总线机制是正确的。事件必须完全独立于接收者。

因此，订阅者因任何责任原因而放弃事件（“即使我注册了，我也不对该事件负责”）强烈表明使用事件总线是错误的。那么你应该考虑使用专门的听众。

Answer 4

我会选择EventBus，因为它具有松散的耦合和更清晰的代码。此外，使用 Greenrobot 等 EventBus 会自动为我完成所有样板，并允许我直接从 Activity Lifecycle 方法（onStart 和 onDestroy | onStop）注册和取消注册观察者，这一点很棒。实现回调并仍然设法控制这些回调的活动生命周期管理是一件不必要的麻烦，并且涉及大量不必要的样板文件。

此外，显然所有垃圾收集器都认为弱引用很棒——事件总线为您的观察者和组件提供了这一点。它是观察者模式的基础。

Answer 5

用一句话来说，事件总线是一个经典的God Object，因此被认为是一种反模式，应该避免。