27

I have many Activities which raise background tasks; the Activities will pass themselves in as having implemented a listener callback, so that the background tasks can raise an event on the Activities. The Activities in turn can show something on the UI to indicate that a background activity passed or failed.

Alternatively, I could use an EventBus, wherein I get the Activity to register itself as a listener/subscriber. I can have a background tasks raise an event on the EventBus and the Activity listening to it can handle it.

What are the advantages of one over the other? When would you use one over the other? (Code cleanliness? Performance? Caveats?)

Follow up - I did end up using EventBus. The code is definitely a lot cleaner and there aren't callbacks hanging out everywhere. The IDE (IntelliJ) thinks that the onEvent methods are unused, so I created an annotation

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

and placed it over my onEvent methods. Then Alt+Clicked on it and asked IntelliJ to not treat it as unused. 

@EventBusHook
public void onEvent(MyEventType myEventType){
4

4 回答 4

52

I disagree with @nnuneoi's answer.

Event bus has just one single advantage: it allows for communication between components which are "unaware" of each other's existence.

And there are several disadvantages:

  1. The components become loosely coupled by dependency on both event bus and specific event type
  2. The coupling described in #1 above is not strong
  3. The coupling described in #1 above is not evident
  4. Event bus introduces performance overhead over simple callbacks
  5. If event bus holds a strong reference to subscribers (as is the case with e.g. GreenRobot's EventBus), then unregistered subscribers will cause memory leaks

Given all these disadvantages, simple callbacks should be the default implementation choice.

Event bus should be used only when direct coupling is not desired or hard to implement. For example:

  1. Sending events from Service to Activity
  2. Exchanging events between independent Fragments
  3. Application wide events (e.g. user login/logout)

If the communicating components are already "aware" of each other's existence, there is no need for them communicating via event bus.

于 2017-04-28T13:08:04.107 回答
26

Benefits of using EventBus:

  • Your code will look much more clean
  • Your code will become more modular which will allow you to easily create test case for your code
  • Avoid memory leaks from bad object references which lock the object and does not allow Garbage Collector to clean it up
  • Could have more than one receiver a time, that it much like broadcasting
  • Simplify multiple interfaces into a single one, EventBus
  • In an interface class, you need to override every single method in the class that is inherited. With EventBus, you can listen for just an event that you really want

But bad part is you might be a little bit more headache with the function declaration since IDE couldn't help you with auto-complete.

My suggestion is, if you find that you have to create a custom listener, then please consider EventBus, it might be a better choice for most of (if not all) of your requirements/cases.

Anyway, it is all your choice after all =)

于 2015-03-12T11:32:17.030 回答
1

You should check if your event is globally unique on the semantic view. Either an subscriber is interested in the event or not. If not he shouldn't subscribe.

Event-Bus mechanism is right if you really have a publisher-subscriber relationship. The event must be totally independent of the receiver.

So a subscriber that discard the event for any reason of responsibility ("I am not responsible the event even if I am registered") is a strong indicator that using an Event-Bus is wrong. Then you should consider using dedicated listeners.

于 2017-06-14T16:14:41.613 回答
1

I would go with the EventBus because of the loose coupling and cleaner code. Also, the fact that using an EventBus such as Greenrobot automatically does all the boilerplate for me and allows me to register & deregister observers right from Activity Lifecycle methods (onStart and onDestroy|onStop) is great. Implementing callbacks and still managing to control Activity lifecycle management for those callbacks is an unnecessary headache and involves a lot of unnecessary boilerplate.

Also, apparently all garbage collectors think weak reference is great-Event bus gives your observers and components exactly that. Its the basis of the Observer pattern.

于 2019-08-20T17:55:46.490 回答