android - 事件总线 : What are some differences among each thread modes?

Question

根据 EventBus doc ，EventBus用来传递线程的线程模式有4种:

• onEvent()

  • PostThread
  • Good for simple tasks

• onEventMainThread()

  • MainThread
  • a.k.a. UI Thread
  • Good for UI changes

• onEventBackgroundThread()

  • BackgroundTread
  • Using single thread, delivering events sequentially.
  • Good for execution requiring moderate amount of time.

• onEventAsync()

  • Async
  • Using separate threads.
  • Good for execution requiring longer time

问题

1. 在使用 onEventBackgroundThread() 而不是 onEventAsync() 之前，我应该检查哪些标准，反之亦然？使用一个比另一个具有明显优势的例子有哪些？

2. 以下每个函数应使用哪种线程模式？

   • 获取设备状态 -- 设备的 GPS 位置(即 android.location)、互联网连接状态(即 ConnectivityManager、NetworkInfo).

   • 发出简单的 HTTP 请求以接收文本(例如 JSON)，耗时 1000 毫秒到 5000 毫秒之间，平均 2000 毫秒。

   • 发出简单的 HTTP 请求以加载文件大小在 50kb 到 1500kb 之间的图像(在向服务器发出请求之前，客户端不知道确切大小)。

   • 将数据缓存到内部数据库(例如 SharedPreferences、SQLite 等)。

Answer 1

What are some criteria I should examine before I use onEventBackgroundThread() over onEventAsync(), or vice versa? What would be some examples of using one over the other with obvious advantages?

好吧，这与项目符号概述的差不多。如果您不介意排队、一次一个处理(或者您想要它以实现更简单的线程安全)，请使用 onEventBackgroundThread()。如果您需要并行执行其中的几个，特别是如果它们受 I/O 限制，您可以使用 onEventAsync()。

Which thread modes should each of the following functions use?

GPS location of the device (i.e. android.location)

以上都不是。 LocationManager 和融合位置 API 有自己的异步选项；我会用那些。获得传递给您的位置后，您可以发布带有位置数据的事件，但线程由该事件的订阅者而不是发布者决定。

Internet connectivity status (i.e. ConnectivityManager, NetworkInfo)

以上都不是，因为 AFAIK getNetworkInfo() 不是一个昂贵的调用。

Making simple HTTP requests to receive text (e.g. JSON), taking anywhere between 1000ms to 5000ms, average 2000ms.

以上都不是。我会使用 Retrofit 或其他提供异步选项的 HTTP 客户端库。如果出于某种原因您绝对必须自己执行 HTTP I/O，那将取决于这种情况发生的频率。例如，如果您可能因为快速连续触发其中的几个而落后，请使用 onEventAsync() 以便它们可以并行运行。

Making simple HTTP requests to load images with file sizes between 50kb to 1500kb (exact sizes are unknown to client, before making requests to server).

以上都不是。使用 Picasso、Universal Image Loader 或任何其他图像加载库，因为它们都有异步选项，而且图像处理逻辑确实需要这些。如果出于某种原因您绝对必须自己执行 HTTP I/O，它会遵循我在上一项中描述的相同规则。

Caching data to internal database (e.g. SharedPreferences, SQLite, etc).

假设您在这里没有使用一些可能提供异步操作的包装器库，这可能可以通过 onEventBackgroundThread() 来处理。这也将为您提供确保序列化操作的优势。