3

EventBus docによると、スレッドのEventBus配信に使用するスレッド モードには 4 つのタイプがあります。

  • onEvent()

    • 投稿スレッド
    • 単純なタスクに適しています

  • onEventMainThread()

    • メインスレッド
    • 別名UIスレッド
    • UIの変更に適しています

  • onEventBackgroundThread()

    • 背景トレッド
    • シングル スレッドを使用して、イベントを順次配信します。
    • 適度な時間を必要とする実行に適しています。

  • onEventAsync()

    • 非同期
    • 別々のスレッドを使用します。
    • より長い時間を必要とする実行に適しています

質問

  1. onEventBackgroundThread()overを使用する前にonEventAsync()、またはその逆を使用する前に検討すべき基準は何ですか? 明らかな利点がある一方を他方よりも使用する例は何ですか?

  2. 次の各関数は、どのスレッド モードを使用する必要がありますか?

    • デバイス ステータスの取得 -- デバイスの GPS 位置情報（android.location）、インターネット接続ステータス（ConnectivityManager、NetworkInfo）。

    • テキスト (JSON など) を受信する単純な HTTP 要求を作成すると、1000 ミリ秒から 5000 ミリ秒の間、平均 2000 ミリ秒かかります。

    • ファイルサイズが 50kb から 1500kb の画像をロードするための単純な HTTP リクエストを作成します (正確なサイズは、サーバーにリクエストを送信する前に、クライアントには不明です)。

    • 内部データベースへのデータのキャッシュ (例: SharedPreferences、SQLiteなど)。

4

1 に答える 1

4

onEventAsync() ではなく onEventBackgroundThread() を使用する前に、またはその逆を使用する前に、どのような基準を検討する必要がありますか? 明らかな利点がある一方を他方よりも使用する例は何ですか?

まあ、それは箇条書きの概要とほとんど同じです。キューに入れられた、一度に 1 つずつ処理することを気にしない場合 (または、より単純なスレッド セーフのためにそれが必要な場合) は、 を使用しますonEventBackgroundThread()。それらのいくつかを並行して実行する必要がある場合、特に I/O バウンドの場合は、 を使用しますonEventAsync()。

次の各関数は、どのスレッド モードを使用する必要がありますか?

デバイスの GPS 位置 (つまり、android.location)

上記のどれでもない。LocationManager融合されたロケーション API には、独自の非同期オプションがあります。私はそれらを使用します。場所が渡されたら、場所データを使用してイベントを投稿できますが、スレッドは投稿者ではなく、そのイベントのサブスクライバーによって決定されます。

インターネット接続ステータス (つまり、ConnectivityManager、NetworkInfo)

getNetworkInfo()私の知る限り、高価な通話ではないため、上記のいずれもありません。

テキスト (JSON など) を受信する単純な HTTP 要求を作成すると、1000 ミリ秒から 5000 ミリ秒の間、平均 2000 ミリ秒かかります。

上記のどれでもない。Retrofit または非同期オプションを提供する別の HTTP クライアント ライブラリを使用します。何らかの理由でどうしても HTTP I/O を自分で行わなければならない場合は、これがどのくらいの頻度で発生しているかによって異なります。たとえば、これらのいくつかを立て続けに起動したために遅れる可能性がある場合は、onEventAsync()それらを並行して実行できるように使用します。

ファイルサイズが 50kb から 1500kb の画像をロードするための単純な HTTP リクエストを作成します (正確なサイズは、サーバーにリクエストを送信する前に、クライアントには不明です)。

上記のどれでもない。Picasso、Universal Image Loader、またはその他の画像読み込みライブラリを使用してください。これらにはすべて非同期オプションがあり、画像処理ロジックにはこれらが本当に必要です。何らかの理由でどうしても HTTP I/O を自分で行う必要がある場合は、前の項目で説明したのと同じ規則に従います。

内部データベースへのデータのキャッシュ (例: SharedPreferences、SQLite など)。

ここで非同期操作を提供する可能性のあるラッパー ライブラリを使用していないと仮定すると、これはおそらく を介して処理できますonEventBackgroundThread()。これにより、シリアル化された操作を保証するという利点も得られます。

于 2015-06-01T20:42:55.167 に答える