EventBusとActivityが教えてくれた「先手が強い」そして「生きている」という意味

EventBusはAndroid最適化のためのパブリケーション/サブスクリプションインベントリーバスです.主な機能は、Intent、Handler、BroadCastの代わりに、Fragment、Activity、Service、スレッド間でメッセージを伝えることです.利点は、オーバーヘッドが小さく、コードがより優雅であり、送信者と受信者をデカップリングすることである.翻訳すると実はこのような核心のいくつか:1.コンポーネント間の通信を簡略化する(1).送信および受信イベントをデカップリング(2).Activity,Fragment,バックグラウンドスレッド間で実行できる(3).複雑で誤りやすい依存とライフサイクルの問題を回避した.コードをより簡潔にします.より高速4.より軽量(jarパッケージが50 K未満)5.実践はすでに1億余りのアプリにEventBus 6が統合されていることを証明した.スレッド配布、ユーザー優先度など、先進的な機能を備えています.

一、同じActivityでEventイベントを転送する

Activityでネットワークリクエストを取得して結果を得た後、このActivityで結果情報を判断する必要があります.だからこのActivityは送信も受信もできます.

二、異なるActivity転送イベント

この2つのActivityでは、1つのActivityにpostメソッドがイベントの送信を担当し、もう1つのActivityにサブスクライバを登録して受信を担当することは間違いありません.多くの初心者の友达は間違いなくこのようにすればいいと思って、往々にして1つの重要な問題を無視して、それはActivityのライフサイクルが購読者の登録に影響して、それによって事件の転送に影響して、転送の失敗をもたらす可能性があります.転送に失敗する可能性のある原因を分析します.なぜ「購読者」と名付けられたのか、EventBusが先に購読してから送信することを知っておく必要があります.サブスクリプションは前に、後に送信されます.受信者は先にサブスクリプションし、そのActivityはまだ「生きている」必要があります.これにより、異なるActivityの間でイベントが順調に伝達されます.
例えば、AのActivityはイベントを送信し、BのActivityはAが送信したイベントを受信する.B Aのイベントを受信したい場合は、まずB Activityを開き、Bでは購読者の登録方法を実行し、Bが登録されてからA Activity(このときBがスタックにスタックされてfinishがない)にジャンプし、Aがイベントを送信した後、Bはイベントを受信することに成功する.AをスキップするついでにB finishを登録しておけば、Bの購読者が存在しないことになるので、Aはイベントを送信し、Bをスキップし、Bは購読者を再登録しただけだが、受信できない.
**まとめ**EventBusは、サブスクライバが送信者より先に起動していないか、送信者より先に起動して殺されている場合があります.サブスクライバが存在しない限り、このイベントは受信できません.so,且记口诀:先订阅者且活着,发送能成功.では、先に送って、後で購読しても全然だめですか??答えはいいですが、どのようにして先に送信し、後で購読してイベントを成功させることができますか?以下の2つの方法がある:1.送信者のonStopメソッドでイベントを送信します.Aが送信イベントである場合、Bが受信イベントである場合、AでB Activityを開き、イベント転送を完了する.この場合は先に送信してサブスクライバを登録するのですが、送信者AのonStopメソッドで送信すると、onStopメソッドはB Activityが開いてから呼び出されるので、その時点でBはまだ生きているということになります.2.公式のSticky Events公式を使用して、この問題を解決するために、EventBusは粘性イベントの送信もサポートしています.粘性事件とは何ですか.簡単に言えば、イベントを送信してからこのイベントを購読してもそのイベントを受け取ることができ、粘性放送と似ています.
公式サイトの説明を見てFor example, an event signals that some initialization is complete. Or if you have some sensor or location data and you want to hold on the most recent values. Instead of implementing your own caching, you can use sticky events. EventBus keeps the last sticky event of a certain type in memory. The sticky event can be delivered to subscribers or queried explicitly. Thus, you don’t need any special logic to consider already available data. 一部のイベントは、情报に兴味のあるイベントを行った后に発表されます.例えば、イベント信号、いくつかの初期化が完了します.あるいは、センサの位置データと最近の値をつかみたい場合は.独自のキャッシュを実装するのではなく、粘性のイベントを使用できます.EventBusは、過去のイベントの特定のタイプをメモリに保持します.粘性のイベントは、ユーザーまたは明示的なクエリーに渡すことができます.したがって、使用可能なデータを考慮するために特別な論理は必要ありません.どのように使うか、以下の例

public class BActivity extends Activity {
  //  
  @Override 
  public void onClick(View v) {
    Event event= new Event(10);
    //  Sticky 
    EventBus.getDefault().postSticky(event);
    //  B 
    Intent intent = new Intent(this, AActivity.class);
    startActivity(intent);
  }
}

 AActivity 。

public class AActivity extends Activity {
  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_a);
    //  Sticky 
    EventBus.getDefault().registerSticky(this);
  }
  @Subscriber
  private void receiveUser(Event event){
     //  , event Event 
  }
}