使用像 Otto 或 EventBus 这样的事件库是处理活动、片段和后台线程之间关系的推荐方法

Is using event library like Otto or EventBus a recommended way to handle relations between Activities, Fragments, and background threads

大部分情况下,在处理case的时候

到目前为止,从许多可靠的来源,我可以看到推荐的方式是使用 保留片段

来源

我时常听说事件总线库很适合处理 Activity、Fragment 和后台线程之间的关系。 (请参考 https://github.com/greenrobot/EventBus。它指出 在 Activity、Fragment 和后台线程中表现良好

我遇到了一些非常流行的事件总线库

我想知道,在处理 Activity、Fragment 和后台线程之间的关系时,事件总线方法与 Retained Fragment 方法有何不同?

推荐的方式有哪些?

Android 开发人员指南未 "recommended ways" 事件总线和 Otto,主要是因为它们是 第三方库 以简化任务。而且我相信 Otto 是相当新的,所以旧指南显然没有使用它。

我个人喜欢 Otto,这是我使用的,到目前为止我没有遇到任何问题。但当然,那是因为它适合我的用例。

我有一个关于如何使用 Otto 的例子 here

从未来编辑: 如果你需要一个事件总线,greenrobot/EventBus is better than Otto. Also, in some cases, LiveData<T> 就足够了,而不是使用事件总线(它不会向任何人发出事件,只发送给订阅者)。

I was wondering, when comes to handle relations between Activities, Fragments, and background threads, how is event bus approach different from Retained Fragment approach?

Which ways is a recommended way?

我认为你误解了两个概念:

1) 防止在您旋转设备时重复创建任务

2) 将消息从线程发送到 activity 或从服务发送到片段或...

当我们将任务放入片段中时,我们只是不想在旋转时再次启动它。我们还想从中获取结果,例如我们想更新一个 imageView,但是如果您将 imageView 传递给一个 asynctask 然后旋转您的设备,如果您将 imageView 存储为弱引用,那么您的 imageView 在 activity 已经被销毁,如果你将它存储为强引用,那么你就会泄漏 activity。所以更好的想法是将它放在片段中并将视图存储为弱引用,如果调用 activity onCreate 更新该引用。

EventBus 和 Otto 是非常好的库,可以在任何组件或线程之间发送消息。您可以使用这些或 android 本机解决方案,例如创建接口或 localBroadcastManager 或处理程序。

how is event bus approach different from Retained Fragment approach?

我没有查看这些源代码,但我认为他们创建了一个单例队列对象并将您的消息存储在其中并将其出队以将您的消息传递给他们的听众。

简单的 ActivityFragment 之间的通信可以通过多种方式轻松建立,但最优雅的方式是创建和使用简单的 interface class。但是对于像 activity 这样的场景,它托管一个使用 viewpager 显示另一个片段的片段,那么这个子片段需要与父片段 activity 或片段 通信,这是可以使用 EventBus 的地方,因为您无法与之通信。 EventBus 只应在没有其他方式将数据发送到另一个 class.

时使用

EventBus 一如既往的好。

Otto 现已弃用。

来自 otto 的 link:

This project is deprecated in favor of RxJava and RxAndroid. These projects permit the same event-driven programming model as Otto, but they’re more capable and offer better control of threading.

If you’re looking for guidance on migrating from Otto to Rx, this post is a good start.