EventBus是怎樣管理事件匯流排的, 是不是最佳處理訊息的方案?讓我們一同來學習和認識.

EventBus由來

    在面對應用程式內元件間, 元件與後臺執行緒間的通訊. 又如我們在處理耗時操作時, 等到耗時操作完成後通過Handler或者Broadcast去更新UI, 但是面對多個Activity之間需要通過Listener通訊完成. 但是這些問題我們可以通過EventBus來完成.它是通過釋出/訂閱的方式來管理事件匯流排 .通過註解和反射機制將訂閱者連同訂閱函式儲存起來, 然後在傳送訂閱的時候遍歷訂閱函式陣列進行呼叫, 但是這種形式會影響到EventBus的執行效力.

EventBus的介紹

    EventBus出自greenrobot, 與GreenDao是一家. 而EventBus3.0框架採用了建造者模式, 並加入註解, 通過註解的方式告知訂閱函式執行在哪一個執行緒中.

EventBus主要角色

•     Event 傳遞的事件物件
•     Subscriber 事件的訂閱者
•     Publisher事件的釋出者
•     ThreadMode 定義函式在那種執行緒中執行

官網給出的各種角色的協作圖

EventBus使用

1. 在build.gradle中新增引用

compile 'org.greenrobot:eventbus:3.0.0'

    2. 定義一個事件型別

 public class EventInfoBean {
     public String msg;
     public EventInfoBean(String msg) {
         this.msg = msg;
      }
  }
 

    3.訂閱事件

EventBus.getDefault().register(this);

    4. 釋出事件

EventBus.getDefault().post(new 	EventInfoBean("eventBus傳送的訊息"))

    5. 解除訂閱(一般放在onDestroy()中)

EventBus.getDefault().unregister(this);

    @Subscribe(threadMode = ThreadMode.MAIN)
    public void onEventMainThread(EventInfoBean info) {
        Toast.makeText(getApplicationContext(), "接收到的訊息..." + info.msg, Toast.LENGTH_SHORT).show();
    }
 

    7.訂閱事件的優先順序

    EventBus事件的優先順序類似於廣播的優先順序, 優先順序越高優先得到訊息

    @Subscribe(threadMode = ThreadMode.MAIN,priority = 100)
    public void onDataSynEvent(EventInfoBean event) {
        Log.e(TAG, "event---->" + event.msg);
    }

    8.終止事件傳遞

    EventBus在傳送有序廣播的時候可以終止廣播的往下傳遞

 EventBus.getDefault().cancelEventDelivery(event) ;

    9. 程式碼混淆

-keepattributes *Annotation*
-keepclassmembers class ** {
    @org.greenrobot.eventbus.Subscribe <methods>;
}
-keep enum org.greenrobot.eventbus.ThreadMode { *; }
-keepclassmembers class * extends org.greenrobot.eventbus.util.ThrowableFailureEvent {
    <init>(java.lang.Throwable);
}

EventBus執行緒模型說明

    ThreadMode.MAIN  

        無論任何執行緒中釋出事件, 事件處理函式都會在main執行緒中執行.該方法可以用來更新UI, 但是不能處理耗時操作

    ThreadMode.BACKGROUND

        如果釋出事件是在UI執行緒中釋出, 那麼事件處理函式會在新的執行緒中執行, 如果釋出事件本來就在子執行緒中釋出的, 那麼事件處理函式在釋出事件的執行緒中執行. 此事件處理函式不可以進行UI更新操作

    ThreadMode.POSTING

        事件處理和事件釋出在同一個執行緒中. 在事件處理函式中儘量避免執行耗時操作, 因為它會阻塞事件的傳遞, 有可能會引起ANR

    ThreadMode.ASYNC

        不管事件在哪個執行緒中釋出, 該事件處理函式都會在新建的子執行緒中執行. 事件處理函式中禁止UI更新操作

例項

    事件處理函式

@Subscribe(threadMode = ThreadMode.MAIN)
public void onMessageEventMain(FirstEvent firstEvent) {
    Log.d(TAG, "接收到的訊息.1.." + Thread.currentThread().getName());
}

@Subscribe(threadMode = ThreadMode.ASYNC)
public void onMessageEventAsync(FirstEvent firstEvent) {
    Log.d(TAG, "接收到的訊息.2.." + Thread.currentThread().getName());
}

@Subscribe(threadMode = ThreadMode.BACKGROUND)
public void onMessageEventBackground(FirstEvent firstEvent) {
    Log.d(TAG, "接收到的訊息.3.." + Thread.currentThread().getName());
}

@Subscribe(threadMode = ThreadMode.POSTING)
public void onMessageEventPosting(FirstEvent firstEvent) {
    Log.d(TAG, "接收到的訊息.4.." + Thread.currentThread().getName());
}

從UI執行緒中釋出事件

    釋出事件

send.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {
        EventBus.getDefault().post(new FirstEvent("在同一個執行緒中執行"));
    }
});

    輸出log

02-27 10:26:29.727 14358-14358/com.quanzi.eventbusdemo D/SameThreadActivity: 接收到的訊息.1..main
02-27 10:26:29.727 14358-14358/com.quanzi.eventbusdemo D/SameThreadActivity: 接收到的訊息.4..main
02-27 10:26:29.728 14358-14420/com.quanzi.eventbusdemo D/SameThreadActivity: 接收到的訊息.2..pool-1-thread-1
02-27 10:26:29.729 14358-14421/com.quanzi.eventbusdemo D/SameThreadActivity: 接收到的訊息.3..pool-1-thread-2

從子執行緒中釋出事件

    釋出事件

send.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                EventBus.getDefault().post(new FirstEvent("在同一個執行緒中執行"));
            }
        }).start();
    }
});

輸出log

02-27 10:30:45.027 14523-14541/com.quanzi.eventbusdemo D/SameThreadActivity: 接收到的訊息.3..Thread-799
02-27 10:30:45.027 14523-14541/com.quanzi.eventbusdemo D/SameThreadActivity: 接收到的訊息.4..Thread-799
02-27 10:30:45.027 14523-14542/com.quanzi.eventbusdemo D/SameThreadActivity: 接收到的訊息.2..pool-1-thread-1
02-27 10:30:45.036 14523-14523/com.quanzi.eventbusdemo D/SameThreadActivity: 接收到的訊息.1..main

EventBus粘性事件

    EventBus的粘性事件類似於廣播中的粘性廣播. 粘性廣播在實際開發中使用的比較少.粘性廣播中訂閱/解除訂閱和普通事件一樣, 但是在處理訂閱函式時需要添加註解 sticky = true

    處理粘性事件

 @Subscribe(threadMode = ThreadMode.MAIN,sticky = true)
    public void onDataSynEvent(FirstEvent event){
        Log.d(TAG,"sticky..." + event.getMsg() + "..." + Thread.currentThread().getName());
    }

    傳送粘性事件

 EventBus.getDefault().postSticky(new FirstEvent("粘性事件..."));

     移除粘性事件

        粘性廣播屬於常駐廣播, 如果不需要可以移除粘性事件

    EventBus.getDefault().removeStickyEvent(new FirstEvent());

        或呼叫移除所有粘性事件

    EventBus.getDefault().removeAllStickyEvents();

EventBus的優缺點

    優點 : 簡化了各元件間的通訊方式, 實現瞭解耦讓業務程式碼更加簡潔, 可以動態設定事件處理執行緒以及優先順序

    缺點 : 每一個事件必須自定義一個事件類, 造成事件類過多, 從而增加了維護的成本

EventBus3.0與2.X比較

1.程式碼更加簡潔

2.效能更優. 由於EventBus 2.x 是採用反射的方式對整個註冊類中的所有方法進行掃描來完成註冊，因此在效能上有所影響。而EventBus3.0中提供EventBusAnnotationProcessor註解處理器在編譯期通過讀取Subscribe註解並解析、處理其中所包含的資訊，再生成java類來儲存所有訂閱者的資訊,從而比在執行時使用反射來獲得這些訂閱者的資訊速度要快

以上是我個人對EventBus3.0的一些認識和理解,要是有什麼地方不對的,歡迎各位同仁指正