AndroidでEventBusの使用するマルチスレッドイベントの処理
この一連の教程の最後の編で、GRのEventBusについて話したいです。マルチスレッド非同期タスクを処理する時、どれだけ簡単で効果的ですか？
AsyncTask、LoaderとExector…お願いします。
Androidには、非同期的な動作を実行する方法（UIスレッドと平行なこと）がたくさんある。AsyncTaskはユーザーにとって最も簡単な機構であり、少量の設定コードだけが必要である。しかし、Android公式文書で説明されているように、使用に限界があります。
AsyncTaskはツールクラスとして設計されています。その内部にはThreadとHandlerが含まれていますが、それ自体は汎用スレッドフレームの一部ではありません。AyncTaskは、できるだけ短い動作を実行するために使用されるべきである（最大数秒）。もしスレッド内で長時間のタスクを実行する必要があるなら、Exector、ThreadPool Exector、およびFutreTaskなど、java.util.co ncurrentパッケージで提供される様々なAPIを直接使用することをお勧めします。
ただし、短時間で操作しても問題があります。特にActivity/Fragmentライフサイクルに関するところです。AyncTaskは継続的に動作しているため（それらを起動してもActivity/Fragmentは破壊されている）。このように、ひとたびオンライン・エクステント・アプローチでUIを更新しようとすると、最終的にはIllagalStationの異常が発生します。
Android 3.0には、Activity/Fragmentライフサイクルの問題を解決するためにLoader APIが導入されています。Loader APIは、Activity/Fragmentに非同期的にデータをロードするように設計されている。ローディングデータは非常に一般的な非同期動作であるが、UIスレッドから分離する必要がある唯一の操作ではない。LoaderはActivity/Fragmentにおいてもう一つの傍受インターフェースを実現する必要があります。間違っていませんが、このようなパターンは個人的には好きではありません。最後に、ActivityとFragmentも非同期にスレッドを操作する唯一の場所ではない。例えばServiceではLoaderManagerにアクセスできないので、最終的にはAyncTaskまたはjava.util.co ncurrentを使用します。
java.util.co ncurrentカバンはとてもいいです。AndroidとAndroid以外の項目で全部使えます。でも、使う時はもっと多くの配置と管理が必要です。AyncTaskほど簡単ではありません。ExectorServiceを初期化し、ライフサイクルを管理し、監視する必要があります。いくつかのFutureオブジェクトとの接触が必要です。
適切に使えば、AyncTask、Loader、Exectorは非常に有効です。しかし、複雑なアプリケーションでは、各タスクのために適切なツールを選択する必要があります。このように、3つの異なる処理を同時に行うフレームコードを維持しなければなりません。
Green Robotが手伝いに来ました。
GRのEventBusには非常に素晴らしい同時処理機構が内蔵されています。モニタークラスでは、4つの異なるタイプの処理が可能です。一つの整合イベントが送信されると、EventBusは、異なる同時モデルに従ってイベントを対応する処理方法に送信する。
イベント（Tイベント）：送信されたイベントと同じスレッドで実行します。
OventMainThread（T event）：メイン（UI）スレッドで実行され、イベントがどのスレッドから送られてくるかに関わらず。
オンイベントAync（Tイベント）：個々のスレッド、すなわち非UIスレッド、イベントを送信するスレッドで実行されます。
イベントを送信するスレッドがUIスレッドではない場合、このスレッドで実行されます。イベントを送信するのがUIスレッドである場合、それはEventBusによって維持される別のスレッドで実行される。複数のイベントは、この個別のバックグラウンドスレッドに同期して処理される。
これらの方法は機能が強く，簡単に使用できる。例えば、比較的に時間がかかる操作（おそらく、ネットワーク呼び出し、大量のデータ処理など）があり、この操作はUI上の動作によってトリガされ、操作が実行されると、UIを更新する必要がある。この例では、UI挙動はボタンクリックであり、ボタンはactivityでは、serviceで時間がかかります。私たちは次のように実現できます。
Java
この例は比較的簡単であるにもかかわらず、問題を非常に簡潔に説明した。ここでは傍受インターフェースは必要ないし、ライフサイクルのような問題もないです。また、構成変更（回転スクリーン）が発生した場合、または他の何らかの理由でactivityが2つのイベントの間で破壊され再構築され、最終的にはOperation Complette Eventイベントを受信することができます。
また、他の使い方も考えやすくなります。例えば、更新の進捗を送信する必要があれば、進捗値を封入したイベントクラスを別のものにして送信すればいいです。または、他のイベント（同じでも異なるタイプでも）を並列処理しないようにしたい場合（同期実行）は、オンEvent Background Threadを選択して使用することができます。
依存Buss
EventBusを実装する一番簡単な方法はEventBus.get Default()を通じてです。しかし、EventBusBuiderクラス（EventBus.builder（を通じて）には、他の有用な構成方法も含まれている。特にここで述べたのは、あなた自身のExectorServiceを使用します。デフォルトの場合はEventBusはExectors.newCachedThreadPoolを通じて自分のExector Serviceを創建します。ほとんどの場合はあなたのニーズに満足しています。しかし、EventBusで使用するスレッドの数を表示して制御したい場合があります。この場合、EventBusを初期化することができます。
Java
AsyncTask、LoaderとExector…お願いします。
Androidには、非同期的な動作を実行する方法（UIスレッドと平行なこと）がたくさんある。AsyncTaskはユーザーにとって最も簡単な機構であり、少量の設定コードだけが必要である。しかし、Android公式文書で説明されているように、使用に限界があります。
AsyncTaskはツールクラスとして設計されています。その内部にはThreadとHandlerが含まれていますが、それ自体は汎用スレッドフレームの一部ではありません。AyncTaskは、できるだけ短い動作を実行するために使用されるべきである（最大数秒）。もしスレッド内で長時間のタスクを実行する必要があるなら、Exector、ThreadPool Exector、およびFutreTaskなど、java.util.co ncurrentパッケージで提供される様々なAPIを直接使用することをお勧めします。
ただし、短時間で操作しても問題があります。特にActivity/Fragmentライフサイクルに関するところです。AyncTaskは継続的に動作しているため（それらを起動してもActivity/Fragmentは破壊されている）。このように、ひとたびオンライン・エクステント・アプローチでUIを更新しようとすると、最終的にはIllagalStationの異常が発生します。
Android 3.0には、Activity/Fragmentライフサイクルの問題を解決するためにLoader APIが導入されています。Loader APIは、Activity/Fragmentに非同期的にデータをロードするように設計されている。ローディングデータは非常に一般的な非同期動作であるが、UIスレッドから分離する必要がある唯一の操作ではない。LoaderはActivity/Fragmentにおいてもう一つの傍受インターフェースを実現する必要があります。間違っていませんが、このようなパターンは個人的には好きではありません。最後に、ActivityとFragmentも非同期にスレッドを操作する唯一の場所ではない。例えばServiceではLoaderManagerにアクセスできないので、最終的にはAyncTaskまたはjava.util.co ncurrentを使用します。
java.util.co ncurrentカバンはとてもいいです。AndroidとAndroid以外の項目で全部使えます。でも、使う時はもっと多くの配置と管理が必要です。AyncTaskほど簡単ではありません。ExectorServiceを初期化し、ライフサイクルを管理し、監視する必要があります。いくつかのFutureオブジェクトとの接触が必要です。
適切に使えば、AyncTask、Loader、Exectorは非常に有効です。しかし、複雑なアプリケーションでは、各タスクのために適切なツールを選択する必要があります。このように、3つの異なる処理を同時に行うフレームコードを維持しなければなりません。
Green Robotが手伝いに来ました。
GRのEventBusには非常に素晴らしい同時処理機構が内蔵されています。モニタークラスでは、4つの異なるタイプの処理が可能です。一つの整合イベントが送信されると、EventBusは、異なる同時モデルに従ってイベントを対応する処理方法に送信する。
イベント（Tイベント）：送信されたイベントと同じスレッドで実行します。
OventMainThread（T event）：メイン（UI）スレッドで実行され、イベントがどのスレッドから送られてくるかに関わらず。
オンイベントAync（Tイベント）：個々のスレッド、すなわち非UIスレッド、イベントを送信するスレッドで実行されます。
イベントを送信するスレッドがUIスレッドではない場合、このスレッドで実行されます。イベントを送信するのがUIスレッドである場合、それはEventBusによって維持される別のスレッドで実行される。複数のイベントは、この個別のバックグラウンドスレッドに同期して処理される。
これらの方法は機能が強く，簡単に使用できる。例えば、比較的に時間がかかる操作（おそらく、ネットワーク呼び出し、大量のデータ処理など）があり、この操作はUI上の動作によってトリガされ、操作が実行されると、UIを更新する必要がある。この例では、UI挙動はボタンクリックであり、ボタンはactivityでは、serviceで時間がかかります。私たちは次のように実現できます。
Java
この例は比較的簡単であるにもかかわらず、問題を非常に簡潔に説明した。ここでは傍受インターフェースは必要ないし、ライフサイクルのような問題もないです。また、構成変更（回転スクリーン）が発生した場合、または他の何らかの理由でactivityが2つのイベントの間で破壊され再構築され、最終的にはOperation Complette Eventイベントを受信することができます。
また、他の使い方も考えやすくなります。例えば、更新の進捗を送信する必要があれば、進捗値を封入したイベントクラスを別のものにして送信すればいいです。または、他のイベント（同じでも異なるタイプでも）を並列処理しないようにしたい場合（同期実行）は、オンEvent Background Threadを選択して使用することができます。
依存Buss
EventBusを実装する一番簡単な方法はEventBus.get Default()を通じてです。しかし、EventBusBuiderクラス（EventBus.builder（を通じて）には、他の有用な構成方法も含まれている。特にここで述べたのは、あなた自身のExectorServiceを使用します。デフォルトの場合はEventBusはExectors.newCachedThreadPoolを通じて自分のExector Serviceを創建します。ほとんどの場合はあなたのニーズに満足しています。しかし、EventBusで使用するスレッドの数を表示して制御したい場合があります。この場合、EventBusを初期化することができます。
Java
EventBus.builder().executorService(Executors.newFixedTheadPool(NUM_THREADS)).installDefaultEventBus();