Otto vs LocalBroadcast:

问题:

I am a huge fan of open source contributions square has done to the Android community and was looking into their latest contribution Otto (event bus )

http://square.github.io/otto/

Digging deeper I see that Otto uses reflection and there is no ordered broadcast ( a pattern where a unconsumed message is handed down from one receiver to the next receiver listening on the same type of event ) Otto believes in more of a fire and forget model .

Now android has LocalBroadcastManager (LBM ) in its v4 support library which serves the same purpose , though it's more bulkier and has more restrictions on the objects that are passed . But on the brighter side it does support ordered broadcast and its more akin to the normal broadcast.

Both Otto and LBM are within the same process space so in terms of speed I guess both would be same. The only real difference I could see is that Otto allows you to define custom events and you do not have to serialize/Parcel the Objects .

Hence my real question is when would you use Otto if LBM does the same things .

References :

http://nick.perfectedz.com/otto-event-system/

Using Intents or an event bus to communicate within the same app

https://plus.google.com/107049228697365395345/posts/6j4ANWngCUY

回答1:

But on the brighter side it does support ordered broadcast

Not really. There is no sendOrderedBroadcast() on LocalBroadcastManager, and the priority on the IntentFilter does not appear to be used. If you mean "the broadcasts will be delivered in the order that I registered the receivers", that might be the current behavior, but there is no guarantee that it will stay that way.

Both Otto and LBM are within the same process space so in terms of speed i guess both would be same

They would be similar, though probably not identical.

Hence my real question is when would you use Otto if LBM does the same things

Comparing those two, Otto has a cleaner API, IMHO.

Personally, I'd use greenrobot's EventBus over either of those, because it offers more flexible threading models.

回答2:

Both Otto and LBM are within the same process space so in terms of speed i guess both would be same .

I've found that registering Otto events are quite expensive, sometimes it takes more than 16 milliseconds to register event subscribers (That means you drop 1 FPS!). That's somewhat expected, as event subscribing in Otto is done by reflection. While for LBM, it only takes a few hundred µs only for registering, which is almost 32x faster. (Result from traceview, Samsung Galaxy S4)

But of course, using Otto can write less code, there's a trade off.

回答3:

1. otto makes code cleaner, smaller
2. otto makes testing easier