EventBus:每个线程模式之间有什么不同?

Question

根据EventBus文档，EventBus使用四种类型的线程模式来传递线程:

• onEvent()

  • PostThread
  • 适用于简单任务

• onEventMainThread()

  • MainThread
  • 选择。UI线程

onEventBackgroundThread()

• BackgroundTread

使用单线程，按顺序传递事件。

适合需要适度时间的执行。

onEventAsync()

• 异步

使用单独的线程。

适合需要较长时间的执行

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

2. 以下函数应该使用哪种线程模式?

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

   • 发送简单的HTTP请求来接收文本(例如JSON)，耗时在1000ms到5000ms之间，平均2000ms。

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

   • 缓存数据到内部数据库(如SharedPreferences, SQLite等)

Answer 1

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

嗯，它几乎和子弹大纲一样。如果您不介意排队、一次处理(或者您想要以简化线程安全)，请使用onEventBackgroundThread()。如果您需要并行执行其中的几个，特别是如果它们是I/o限制的，则使用onEventAsync()。

下面的函数应该使用哪个线程模式?

设备的GPS位置(即android.location)

以上皆非。LocationManager和融合位置API有自己的异步选项;我会用那些。一旦你得到了位置，你就可以发布一个带有位置数据的事件，但是线程是由该事件的订阅者决定的，而不是发布者。

Internet连接状态(即ConnectivityManager, NetworkInfo)

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

发送简单的HTTP请求来接收文本(例如JSON)，耗时在1000ms到5000ms之间，平均2000ms。

以上皆非。我会使用Retrofit或其他提供异步选项的HTTP客户端库。如果出于某种原因，您必须自己执行HTTP I/O操作，则取决于此操作发生的频率。例如，如果您可能因为快速连续发射几个而落后，请使用onEventAsync()以便它们可以并行运行。

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

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

缓存数据到内部数据库(如SharedPreferences, SQLite等)

假设这里没有使用可能提供异步操作的包装器库，这可能可以通过onEventBackgroundThread()来处理。这样还可以确保序列化操作。