AndroidでのEventBusとRxJavaの違いについて混乱しています。何らかの変更が行われたときにいくつかのコンポーネントに通知し、状態を更新できるようにするという私の問題のために、それらのいずれかを実装する必要があります。
また、EventsBusがRxJavaで非推奨になったことを読みましたが、この情報が真実かどうかわかりません。
EventBus
とRxJava
は性質が異なります。
EventBus
は、名前が示すようにbus
にすぎません。これは、イベントのサブスクライブと発行のメカニズムを提供します。 isなど。Androidのコンテキストでは、EventBus
は、より少ない定型文でBroadcast
メッセージの送受信を処理する簡単な方法です。
一方、RxJava
はそれよりもはるかに強力です。はい、イベントをサブスクライブおよび公開できますが、プロセスをはるかに制御できます-頻度、スレッドがすべて発生するなど、RxJava
の主な力は(私の意見では)大量のoperators
を使用して、非常に簡単に公開されるデータ。
まとめると、受け取ったときにイベントの発行とアクションの実行のみに関心がある場合は、おそらく最も単純な2つ、つまり何らかの種類のBus
、または単純な古いBroadcastReceiver
s。データの変換、スレッド処理、または単純化されたエラー処理のメリットも得られる場合は、RxJava
アプローチに進んでください。 RxJava
の学習曲線は一般に急勾配であるため、その概念に慣れるまでに時間がかかることに注意してください。
RxJavaを理解するには、リストを考えてください。現在、変換、分割、マージなどのリストの操作は、機能的なメソッド(map、groupByなど)を使用して簡単に実行できます。 RxJavaは、メインターゲットがリストではなくストリームであることを除いて、同じ原則を使用します。ストリームは非同期で、多くの場合、websocketチャネルやオンラインムービーなどのライブデータです。
イベントバスは、Androidでライフサイクルに結び付けられることが多いクラスを分離する必要があるためです。インスタンスとしてのネットワークコールバックとアクティビティのビューの緊密な結合は、多数のヌルポインター例外の原因:パブリッシャー/サブスクライバーパターンを備えたイベントバスは、この問題を軽減します。
RxJavaとどのように混在しますか? RxJavaには、Observableパターンが組み込まれています。ここで、オブザーバーはオブザーバブルを監視し、イベントが到着すると反応します。 Observableにはいくつかのサブクラスがあり、その中にはObservableとObserverの両方のプロパティを持つSubjectがあります。イベントをトラップしてサブスクライバーに公開することで機能するため、技術的にはイベントバスとして機能します。
RxJavaをイベントバスとして使用するのは賢明ですか?いいえ。RxJavaは、単純な目的のために不必要な複雑さをもたらします。アプリがストリームを操作する場合にのみ使用してください。たとえば、映画ストリームのフレームと別のストリームの字幕をペアリングします。アプリが単にREST APIを消費し、アクティビティ/フラグメントからコールバックを分離する必要がある場合、イベントバスで十分です。
Live @Veskoが書いたように、RxJavaとイベントバスは性質が異なり、さまざまな問題を解決するのに役立つ可能性があります。それにもかかわらず、両方とも同じ問題を(異なるコストで)解決できるいくつかのシナリオがあり、これが多くの人々がこれら2つの概念を混同する理由かもしれません。
RxJavaは概念的にはAndroid少し前にリリースされたLiveDataに似ており、これらの概念とイベントバスをよりよく理解するために、私の投稿を読むことをお勧めします。これらの概念そのもので、あるシナリオを別のシナリオよりも優先的に使用するシナリオと、他のシナリオではなくどちらかを使用する場合の長所と短所を説明します。
サーバーからデータを取得してUIを更新する場合は、RxJava + Refrofitを使用します。 UIを更新するか、データをフェッチせずに何らかの操作を行う場合、EventBusで十分です。