EventBus与callback,哪些使用时?

我有很多活动提高后台任务; 活动将自动进行,因为已经实现了监听器callback,所以后台任务可以在活动中引发事件。 这些活动反过来可以在用户界面上显示一些信息,表明后台活动已通过或失败。

或者,我可以使用一个EventBus ,其中我得到活动注册自己作为一个听众/订户。 我可以有一个后台任务在EventBus上引发事件,而监听它的Activity可以处理它。

彼此有什么优势? 你什么时候使用一个? (代码清洁?性能?注意事项?)


跟进 – 我最终使用EventBus。 代码肯定是更清洁,没有callback挂在四处。 IDE(IntelliJ)认为onEvent方法是未使用的,所以我创build了一个注释

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

并把它放在我的onEvent方法上。 然后Alt +点击它,并要求IntelliJ不要把它当作未使用。

 @EventBusHook public void onEvent(MyEventType myEventType){ 

Solutions Collecting From Web of "EventBus与callback,哪些使用时?"

使用EventBus的好处:

  • 你的代码看起来更干净
  • 您的代码将变得更加模块化,这将使您可以轻松地为您的代码创buildtesting用例
  • 避免从locking对象的错误对象引用泄漏内存,并且不允许垃圾收集器清理它
  • 一次可以有一个以上的接收器,就像广播一样
  • 将多个接口简化为一个EventBus
  • 在接口类中,您需要重写inheritance的类中的每个方法。 有了EventBus,你可以只听一个你真正想要的事件

但不好的部分是你可能会更加头痛,因为IDE不能帮助你完成自动完成function。

我的build议是,如果你发现你必须创build一个自定义的监听器,那么请考虑EventBus,对于大多数(如果不是全部)你的需求/情况来说,这可能是一个更好的select。

无论如何,这毕竟是你所有的select=)

我不同意@nnuneoi的回答。

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

还有几个缺点:

  1. 组件通过依赖于事件总线和特定事件types变得松散耦合
  2. 上面#1中描述的耦合不强
  3. 上面#1中描述的耦合不明显
  4. 事件总线在简单的callback中引入了性能开销
  5. 如果事件总线对订阅者有很强的参考(例如GreenRobot的EventBus ),那么未注册的订阅者将会导致内存泄漏

鉴于所有这些缺点,简单的callback应该是默认的实现select。

事件总线只能在不需要直接耦合或难以实现的情况下使用。 例如:

  1. Service发送事件到Activity
  2. 在独立Fragments之间交换事件
  3. 应用程序广泛的事件(例如用户login/注销)

如果通信组件已经“知道”彼此的存在,则不需要通过事件总线进行通信。

你应该检查你的事件是否在语义视图上是全局唯一的。 用户是否对该事件感兴趣。 如果不是,他不应该订阅。

事件总线机制是正确的,如果你真的有一个发布者 – 用户关系。 事件必须完全独立于接收器。

因此,出于任何责任理由(“即使我已经注册,我也不负责任”)的用户丢弃该事件是使用事件总线错误的有力指标。 那么你应该考虑使用专用的监听器。