EventBus 筆記
APP中模塊/層級間交互的邏輯處理往往也起著關(guān)鍵性的作用，一般較為常見的是通過自定義的接口即回調(diào)( callback )的方式實現(xiàn)徊都，但是邏輯稍微復(fù)雜的情況下很容易發(fā)展為callback hell薛窥。本篇我們要看的是另外的一種方式，即采用Event bus來解耦發(fā)送端與接收端。實質(zhì)上看 EventBus 是設(shè)計模式中 Observer模式 的典型代表童太。
先看到主流的Event bus 的對比 (Greenrobot EventBus VS. Otto Bus):
0. 性能對比
1. 對DeadEvent的處理
OttoBus 對沒有接收者的事件，保留了和 Guava eventbus 相同處理方式胸完，即發(fā)現(xiàn)沒有處理事件的handler時將發(fā)出 DeadEvent书释，此時 DeadEvent 將事件的發(fā)送者和源事件包裝起來了。
而 Greenrobot EventBus 中則附加定義了 postSticky 的方法赊窥，會在內(nèi)存中緩存 ( Sticky Events map 默認(rèn)以 Event class作為key保存 ) 最近的 Sticky Event 對象爆惧，在接收的方法中明確指定 sticky 為 true 時，則可以自動處理锨能；但值得注意的是扯再，此時如未指定sticky 為 true，則不能收到 event址遇。同時在處理完了Sticky Event之后熄阻，需要手動移除，以避免重復(fù)處理該事件倔约。
@Subscribe(sticky = true)
public void onHandle(YourEvent event) {
// process your sticky event
// ...
EventBus.getDefault().removeStickyEvent(event);
}
相較之下秃殉，OttoBus 則可能需要自行搜集所有的DeadEvent，然后適時再次發(fā)送。
2. 事件處理的可繼承性與訂閱者索引
由于EventBus 對Event 以及 Subscriber 的繼承性都進行了實現(xiàn)钾军，簡單來講基類的訂閱邏輯在子類中同樣是有效的鳄袍；而Otto bus則處于性能上的考慮未能給予支持。
再看 Greenrobot EventBus吏恭，為了優(yōu)化性能拗小，減少靠反射調(diào)用來查找事件的訂閱方法，EventBus 推薦采用對訂閱者建立索引樱哼， 最終利用 annotation processor 生成索引類哀九，使用 builder 模式構(gòu)建最后的 EventBus 實例（將復(fù)雜度從運行時轉(zhuǎn)到了編譯期 ??）。
??如果項目中引入了 Kotlin 或是已經(jīng)是完全的 Kotlin開發(fā)搅幅，請使用
apply plugin: 'kotlin-kapt' // ensure kapt plugin is applied
dependencies {
def eventbus_version = '3.2.0'
implementation "org.greenrobot:eventbus:$eventbus_version"
kapt "org.greenrobot:eventbus-annotation-processor:$eventbus_version"
}
kapt {
arguments {
arg('eventBusIndex', 'com.example.myapp.MyEventBusIndex')
}
}
而無需同時指定
javaCompileOptions {
annotationProcessorOptions {
arguments = [ eventBusIndex : 'com.example.myapp.MyEventBusIndex' ]
}
}
否則勾栗，可能無法生成 MyEventBusIndex class.
