奥托与本地广播：答案

【问题标题】：Otto vs LocalBroadcast:奥托与本地广播：
【发布时间】：2014-05-17 06:19:18
【问题描述】：

我是 Square 对 Android 社区所做的开源贡献的忠实粉丝，并且正在研究他们的最新贡献 Otto（事件总线）

深入挖掘，我发现 Otto 使用反射并且没有有序广播（未使用的消息从一个接收器传递到下一个接收相同类型事件的接收器的模式） Otto 相信更多的是火和忘记模型。

现在 android 在它的 v4 支持库中有 LocalBroadcastManager (LBM) 用于相同的目的，尽管它更庞大并且对传递的对象有更多限制。但从好的方面来说，它确实支持有序广播，并且更类似于正常广播。

Otto 和 LBM 都在同一个进程空间内，所以就速度而言，我猜两者都是一样的。我能看到的唯一真正区别是 Otto 允许您定义自定义事件，并且您不必序列化/打包 Objects 。

因此，我真正的问题是，如果 LBM 做同样的事情，你什么时候会使用 Otto。

参考资料：

【问题讨论】：

【解决方案1】：

但好的一面是它确实支持有序广播

不是真的。 LocalBroadcastManager上没有sendOrderedBroadcast()，IntentFilter上的优先级似乎没有被使用。如果您的意思是“广播将按照我注册接收者的顺序传递”，那可能是当前的行为，但不能保证它会保持这种状态。

Otto 和 LBM 都在同一个进程空间内，所以就速度而言，我猜两者应该是一样的

它们会很相似，但可能并不完全相同。

因此我真正的问题是，如果 LBM 做同样的事情，你什么时候会使用 Otto

比较这两者，Otto 有一个更简洁的 API，恕我直言。

就我个人而言，我会在其中任何一个上使用greenrobot's EventBus，因为它提供了更灵活的线程模型。

【讨论】：

是的，我已经纠正了，LBM 上没有 sendOrderedBroadcast()，这是我注册接收器的方式。也会看看 greenrobot 的 EventBus。感谢您的提示
GreenRobot 看起来真的很有趣，尤其是帖子粘性部分。你推荐它用于解决方向改变的问题吗？例如，确保活动在娱乐完成后始终从服务中获得结果？一个简单的例子是使用 volley 将服务调用添加到队列以检索一些数据，然后我旋转设备......然后返回 volley 的结果并使用 greenrobot 作为粘性广播发布，而我的活动尚未创建（正在重新启动）活动重新启动，然后可以检索所需的数据。你认为这似乎是合法的？
@NaderAyyad：如果活动将通过 EventBus 消息从服务接收此数据，那么粘性事件可能对配置更改有用。
@CommonsWare 是的，它对此有好处，但是在方向更改后检查结果是否已从服务发送是否有用？因为在某个时刻，服务可以返回活动的数据，但活动将不存在。使用粘性将确保，如果活动不是为了在重新创建活动时保留数据，你曾经这样使用它吗？吃完后能去掉粘稠的吗？
Activity 的释放和重新创建会在事件队列中一个接一个地发生，因此来自外部的事件不会在两者之间进行处理。

【解决方案2】：

Otto 和 LBM 都在同一个进程空间内，所以就速度而言，我猜两者都是一样的。

我发现注册 Otto 事件非常昂贵，有时注册事件订阅者需要超过 16 毫秒（这意味着您会降低 1 FPS！）。这在某种程度上是意料之中的，因为在 Otto 中订阅事件是通过反射完成的。而对于 LBM，注册只需要几百微秒，几乎快了 32 倍。（traceview 的结果，三星 Galaxy S4）

当然，使用 Otto 可以编写更少的代码，这是一个权衡。

【讨论】：

【解决方案3】：

【讨论】：