問題タブ [event-bus]

アプリでイベント バスを使用しています (例: greenrobot/EventBus)。しかし、Event Bus の使用にはいくつかの欠点があります。

• タスクの連鎖実行が難しい
• イベントを表現するための多くのクラス
• あまり明確でないコード (まあ、追跡することは可能ですが、それほど明確ではありません)

私はこの問題に対処するための新しい技術を研究してきました。そして、私は RxJava についてかなり読んで、それが解決策になるのではないかと考えています。

RxJava に関する私の質問 (最近読んだ内容に基づく):

• RxJava オブザーバーはいつでも登録できますか? Observable を作成するときだけではありません。EventBus ではこれが可能です。Observable が作成されたときだけでなく、いつでもサブスクライブできます。
• 同じ種類のイベント (例: ナビゲーション イベント) を発行する 2 つ以上の発行者をどのように処理しますか?
• パブリッシャーとサブスクライバーを緊密に結合するということは、毎回パブリッシャーを明示的に指定する必要があることを意味します。そのため、イベントの種類だけでなく、発案者についても心配する必要があります。EventBus を使用すると、イベントの種類だけを気にする必要があり、オリジネーターは気にする必要がありません。

私はAndroid でMVPパターンを実装しています。EventBusを使用して、アクティビティ「A」からのプレゼンターに、アクティビティ「 B」で何かが発生して「A」からのビューを更新することを知らせています。

プレゼンターをコンストラクター内の EventBus に登録しましたが、登録を解除できる場所がありません。

1. プレゼンターがアプリケーションと同じくらい存続すると想定される場合 (構成の変更時に再作成されない)、登録を解除する必要はありますか?
2. ユーザーがアプリケーションを離れる (アクティビティ "A" を閉じる) と、参照は解放されますか、それともメモリ リークですか?

プロジェクトにイベント バスを追加しようとしています。これは、コードをより読みやすく、アプリケーションを堅牢にするために従うべき非常に優れたパターンだからです。
アクティビティのライフサイクル メソッドをリッスンする必要があります。
なぜこれが必要なのか説明しましょう。
アクティビティがあります。このアクティビティ内には、このアクティビティに正確に関連付けられた実行中のスレッド (またはスレッド) があり、UI の変更をメイン キューにポストします。
アクティビティが破棄または一時停止される場合、スレッドを一時停止し、アクティビティが再び画面に表示されたときにスレッドを再開する必要があります。
もちろん、onDestroy および onStart メソッドで直接スレッドを一時停止/再開できますが、アクティビティのライフサイクル メソッドをリッスンする必要がある別のコンポーネントもいくつかあります。
私の質問があります：

1. この場合、EventBus を使用するのは正しいですか、それとも、イベント バスを使用せずにアクティビティ ライフサイクル メソッドですべてを直接実行する方がよいでしょうか。また、アクティビティのライフサイクルでイベント バスを使用することは、あいまいで正しくありません。

   public class ExampleActivity extends Activity {

   ここで私が見た利点の 1 つは、アクティビティの一部でロジックが必要になるたびに、ロジックをアクティビティ ライフサイクル メソッドに追加する必要がないことです。アクティビティのコンテンツは非常に複雑になる可能性があり、フラグメントも使用できます。もちろん、フラグメントのライフサイクル メソッドも使用できます。しかし、アクティビティのライフサイクル メソッドが呼び出されるまでフラグメントが破棄されないのだろうかと思いますが、これはまだテストしていません。したがって、ここでの主な質問は、ネイティブフックメソッドメカニズムを使用して、ここで必要なことを行うのと、イベントバスを使用するのとのどちらが良いかということです。

2. 次の質問は、メインの質問とは直接関係ありません。EventBusAndroid用の（EventBus Link）ライブラリが実装されている方法についての質問です。bus.register(this);1 つのメソッドでインスタンス Subscribe のインターフェイスを実装するために、listener() を作成しないでくださいonEvent(BusEvent event);。そして、このメソッドにいくつかの基本的なクラスを受け入れさせないでBusEventください。onEventライブラリの実装では、イベントが発生してメソッドが呼び出されるたびにリフレクションが使用されています。このアプローチには利点が見られず、リフレクションはJavaでは非常に重いものです。

回答やアドバイスをいただければ幸いです。

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など)。

私はかなりの量の Apache Camel (ルーティング/メディエーション/オーケストレーション エンジン; 軽量 ESB) の経験があり、Akka の違いを理解しようと頭を悩ませています:

• ディスパッチャー ( Dispatcher、PinnedDispatcher、CallingThreadDispatcher)
• ルーター
• プール
• グループ
• イベントバス

ドキュメントによると：

ディスパッチャは次のとおりです。

…それがAkka Actorsを「カチカチ」させる、いわば機械のエンジンです。

しかし、それでは、ディスパッチャとは何か、またはアクターとの関係がどのようなものかについては、実際には説明されていません。

ルーターは次のとおりです。

メッセージをルーター経由で送信して、ルートと呼ばれる宛先アクターに効率的にルーティングできます。Router はアクターの内部または外部で使用でき、自分でルートを管理したり、構成機能を備えた自己完結型のルーター アクターを使用したりできます。しかし、それはディスパッチャーのようにひどく聞こえます。

プールは次のとおりです。

子アクターとしてルートを作成し、それらが終了するとルーターから削除する [のタイプ] ルーター。

グループは次のとおりです。

[タイプ] アクター [ルート] はルーターの外部で作成され、ルーターはアクターの選択を使用して、終了を監視せずに指定されたパスにメッセージを送信します。

イベントバスは次のとおりです。

...アクターのグループにメッセージを送信する方法

これは、ディスパッチャーとルーターのように聞こえます。

したがって、私の主な懸念事項は次のとおりです。

• ディスパッチャー、ルーター、イベントバスの違いと、それぞれをいつ使用するか?
• プールとグループをいつ使用するか?