EventBus, otto, LocalBroadcast的选择

原文链接
greenrobot的EventBus
square的otto
android support包里提供的LocalBroadcast
三者都是类似订阅/发布的模式，降低了耦合度。与callback比起来，这种事件总线的模式使得两个类没有直接的依赖关系，对架构来说进行了解耦，把双向依赖变成了单向依赖，在大型项目中尤其显得重要。
Why publish/subscribe
一方面，callback很容易产生内存泄露，如I/O、网络操作持有了Activity/Fragment的引用，导致不能及时释放，而团队中也很难保证每个成员都足够优秀在写callback的时候能使用弱引用或静态变量。相比起来订阅/发布者模式则比较简单，直接在BaseActivity的onDestroy释放掉，避免了可能的坑。
另外，从可扩展性、可维护性的角度来说，callback也更局限，比如以前某个接口是告诉上层网络数据拉回来了，现在我们希望扩展，这个接口也支持直接告诉上层数据库拉回来了，向上层屏蔽数据来源，如果用callback，则在一次回调结束后，没有办法再次进行回调了。页面必须自己去处理数据来源和拉数据的逻辑。
虽然有些over-architect的嫌疑，但是Android-CleanArchitecture 确实是一种很clean的architecture，而其也正是通过观察者/订阅者模式来实现了单向依赖。
比较
EventBus的github上就有其和otto的比较： EventBus vs Otto
总的来说，两者功能差的不多，otto多了Event producers (e.g. for coding cached events)，而EventBus则多了各种线程的处理、订阅者继承、sticky event等。
但从性能来说，由于otto使用了基于反射的annotation，而和EventBus产生了一定的差距（内部应该还有一些其他问题导致的性能差异，待研究）
三者都不支持跨进程，LocalBroadcast内部其实使用的是Handler，所以其实更像是一个utils类。
如果要做选择的话，LocalBroadcast更轻量，otto相比起api更好用，而EventBus则拥有很棒的线程模型，我投EventBus一票，因为onEvent的各种线程回调真的很方便。