EventBus vs Callbacks，什么时候使用？

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's EventBus的情况），则未注册的订阅者将导致内存泄漏

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

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

1. 从Service向Activity
发送活动
2. 在独立Fragments
之间交换事件
3. 应用程序范围事件（例如用户登录/注销）

如果通信组件已经意识到＆＃34;彼此的存在，他们没有必要通过事件总线进行通信。

Answer 2

使用EventBus的好处：

• 您的代码看起来会更干净
• 您的代码将变得更加模块化，这将使您能够轻松地为代码创建测试用例
• 避免来自锁定对象的不良对象引用的内存泄漏，并且不允许垃圾收集器清理它
• 一次可以有多个接收器，就像广播一样
• 将多个接口简化为单个接口，EventBus
• 在接口类中，您需要覆盖继承的类中的每个方法。使用EventBus，您可以只收听您真正想要的活动

但不好的是，您可能会对功能声明感到头疼，因为IDE无法帮助您自动完成。

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

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

Answer 3

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

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

因此，订阅者因任何责任原因而放弃该事件（＆＃34;即使我已经注册，我也不负责该事件＆＃34;）是一个强烈的指示，即使用事件总线是错误的。那么你应该考虑使用专门的听众。

Answer 4

由于松散的耦合和更简洁的代码，我会选择EventBus。同样，使用诸如Greenrobot之类的EventBus自动为我完成所有样板工作，并允许我直接从Activity Lifecycle方法（onStart和onDestroy | onStop）注册和注销观察者的事实。实现回调并仍然设法控制这些回调的活动生命周期管理是不必要的麻烦，并且涉及许多不必要的样板。

此外，apparently all garbage collectors think weak reference is great-事件总线为您的观察者和组件提供了确切的信息。它是Observer pattern的基础。