【Bugly乾貨分享】老司機教你 “飆” EventBus 3
EventBus對於Android開發老司機來說肯定不會陌生,它是一個基於觀察者模式的事件釋出/訂閱框架,開發者可以通過極少的程式碼去實現多個模組之間的通訊,而不需要以層層傳遞介面的形式去單獨構建通訊橋樑。從而降低因多重回調導致的模組間強耦合,同時避免產生大量內部類。它擁有使用方便,效能高,接入成本低和支援多執行緒的優點,實乃模組解耦、程式碼重構必備良藥。
作為Markus Junginger大神耗時4年打磨、超過1億接入量、Github 9000+ star的明星級元件,分析EventBus的文章早已是數不勝數。本文的題目是“教你飆巴士”,而這輛Bus之所以可以飆起來,是因為作者在EventBus 3中引入了EventBusAnnotationProcessor
1. 新手上路——使用EventBus
1.1 匯入元件:
開啟App的build.gradle,在dependencies中新增最新的EventBus依賴:
compile 'org.greenrobot:eventbus:3.0.0'
如果不需要索引加速的話,就可以直接跳到第二步了。而要應用最新的EventBusAnnotationProcessor則比較麻煩,因為註解解析依賴於android-apt-plugin。我們一步一步來,首先在專案gradle的dependencies中引入apt編譯外掛:
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.8'
然後在App的build.gradle中應用apt外掛,並設定apt生成的索引的包名和類名:
apply plugin: 'com.neenbedankt.android-apt'
apt {
arguments {
eventBusIndex "com.study.sangerzhong.studyapp.MyEventBusIndex"
}
}
接著在App的dependencies中引入EventBusAnnotationProcessor:
apt 'org.greenrobot:eventbus-annotation-processor:3.0.1'
這裡需要注意,如果應用了EventBusAnnotationProcessor卻沒有設定arguments的話,編譯時就會報錯:No option eventBusIndex passed to annotation processor
此時需要我們先編譯一次,生成索引類。編譯成功之後,就會發現在\ProjectName\app\build\generated\source\apt\PakageName\
下看到通過註解分析生成的索引類,這樣我們便可以在初始化EventBus時應用我們生成的索引了。
1.2 初始化EventBus
EventBus預設有一個單例,可以通過getDefault()
獲取,也可以通過EventBus.builder()
構造自定義的EventBus,比如要應用我們生成好的索引時:
EventBus mEventBus = EventBus.builder().addIndex(new MyEventBusIndex()).build();
如果想把自定義的設定應用到EventBus預設的單例中,則可以用installDefaultEventBus()
方法:
EventBus.builder().addIndex(new MyEventBusIndex()).installDefaultEventBus();
1.3 定義事件:
所有能被例項化為Object的例項都可以作為事件:
public class DriverEvent { public String info; }
在最新版的eventbus 3中如果用到了索引加速,事件類的修飾符必須為public,不然編譯時會報錯:Subscriber method must be public
1.4 監聽事件:
首先把作為訂閱事件的模組通過EventBus註冊監聽:
mEventBus.register(this);
在3.0之前,註冊監聽需要區分是否監聽黏性(sticky)事件,監聽EventBus事件的模組需要實現以onEvent開頭的方法。如今改為在方法上添加註解的形式:
@Subscribe(threadMode = ThreadMode.POSTING, priority = 0, sticky = true)
public void handleEvent(DriverEvent event) {
Log.d(TAG, event.info);
}
註解有三個引數,threadMode為回撥所在的執行緒,priority為優先順序,sticky為是否接收黏性事件。排程單位從類細化到了方法,對方法的命名也沒有了要求,方便混淆程式碼。但註冊了監聽的模組必須有一個標註了Subscribe註解方法,不然在register時會丟擲異常:Subscriber class XXX and its super classes have no public methods with the @Subscribe annotation
1.5 傳送事件:
呼叫post或者postSticky即可:
mEventBus.post(new DriverEvent("magnet:?xt=urn:btih……"));
到此我們就完成了使用EventBus的學習,可以在程式碼中盡情地飈車了。專案接入了EventBus之後會有什麼好處呢?舉一個常見的用例:ViewPager中Fragment的相互通訊,就不需要在容器中定義各種介面,可以直接通過EventBus來實現相互回撥,這樣就把邏輯從ViewPager這個容器中剝離出來,使程式碼閱讀起來更加直觀。
在實際專案的使用中,register和unregister通常與Activity和Fragment的生命週期相關,ThreadMode.MainThread可以很好地解決Android的介面重新整理必須在UI執行緒的問題,不需要再回調後用Handler中轉(EventBus中已經自動用Handler做了處理),黏性事件可以很好地解決post與register同時執行時的非同步問題(這個在原理中會說到),事件的傳遞也沒有序列化與反序列化的效能消耗,足以滿足我們大部分情況下的模組間通訊需求。
2. 變身老司機——EventBus原理分析
在平時使用中我們不需要關心EventBus中對事件的分發機制,但要成為能夠快速排查問題的老司機,我們還是得熟悉它的工作原理,下面我們就透過UML圖來學習一下。
2.1 核心架構
EventBus的核心工作機制透過作者Blog中的這張圖就能很好地理解:
訂閱者模組需要通過EventBus訂閱相關的事件,並準備好處理事件的回撥方法,而事件釋出者則在適當的時機把事件post出去,EventBus就能幫我們搞定一切。在架構方面,EventBus 3與之前稍老版本有不同,我們直接看架構圖:
先看核心類EventBus,其中subscriptionByEventType是以事件的類為key,訂閱者的回撥方法為value的對映關係表。也就是說EventBus在收到一個事件時,就可以根據這個事件的型別,在subscriptionByEventType中找到所有監聽了該事件的訂閱者及處理事件的回撥方法。而typesBySubscriber則是每個訂閱者所監聽的事件型別表,在取消註冊時可以通過該表中儲存的資訊,快速刪除subscriptionByEventType中訂閱者的註冊資訊,避免遍歷查詢。註冊事件、傳送事件和登出都是圍繞著這兩個核心資料結構來展開。上面的Subscription可以理解為每個訂閱者與回撥方法的關係,在其他模組傳送事件時,就會通過這個關係,讓訂閱者執行回撥方法。
回撥方法在這裡被封裝成了SubscriptionMethod,裡面儲存了在需要反射invoke方法時的各種引數,包括優先順序,是否接收黏性事件和所線上程等資訊。而要生成這些封裝好的方法,則需要SubscriberMethodFinder,它可以在regster時得到訂閱者的所有回撥方法,並封裝返回給EventBus。而右邊的加速器模組,就是為了提高SubscriberMethodFinder的效率,會在第三章詳細介紹,這裡就不再囉嗦。
而下面的三個Poster,則是EventBus能在不同的執行緒執行回撥方法的核心,我們根據不同的回撥方式來看:
- POSTING(在呼叫post所在的執行緒執行回撥):不需要poster來排程,直接執行。
- MAIN(在UI執行緒回撥):如果post所線上程為UI執行緒則直接執行,否則則通過mainThreadPoster來排程。
- BACKGROUND(在Backgroud執行緒回撥):如果post所線上程為非UI執行緒則直接執行,否則則通過backgroundPoster來排程。
- ASYNC(交給執行緒池來管理):直接通過asyncPoster排程。
可以看到,不同的Poster會在post事件時,排程相應的事件佇列PendingPostQueue,讓每個訂閱者的回撥方法收到相應的事件,並在其註冊的Thread中執行。而這個事件佇列是一個連結串列,由一個個PendingPost組成,其中包含了事件,事件訂閱者,回撥方法這三個核心引數,以及需要執行的下一個PendingPost。
至此EventBus 3的架構就分析完了,與之前EventBus老版本最明顯的區別在於:分發事件的排程單位從訂閱者,細化成了訂閱者的回撥方法。也就是說每個回撥方法都有自己的優先順序,執行執行緒和是否接收黏性事件,提高了事件分發的靈活程度,接下來我們在看核心功能的實現時更能體現這一點。
2.2 register
簡單來說就是:根據訂閱者的類來找回調方法,把訂閱者和回撥方法封裝成關係,並儲存到相應的資料結構中,為隨後的事件分發做好準備,最後處理黏性事件:
值得注意的是,老版本的EventBus是允許事件訂閱者以不同的ThreadMode去監聽同一個事件的,即在一個訂閱者中有多個方法訂閱一個事件,此時是無法保證這幾個回撥的先後順序的,因為不同的執行緒回撥是通過Handler排程的,有可能單個執行緒中的事件過多,事件受阻,回撥則會比較慢。如今EventBus 3使用了註解來表示回撥後,還可以出現相同的ThreadMode的回撥方法監聽相同的事件,此時會根據註冊的先後順序,先註冊先分發事件,注意不是先收到事件,收到事件的順序還是得看poster中Handler的排程。
2.3 post
總的來說就是分析事件,得到所有監聽該事件的訂閱者的回撥方法,並利用反射來invoke方法,實現回撥:
這裡就能看到poster的排程事件功能,同時可以看到排程的單位細化成了Subscription,即每一個方法都有自己的優先順序和是否接收黏性事件。在原始碼中為了保證post執行不會出現死鎖,等待和對同一訂閱者傳送相同的事件,增加了很多執行緒保護鎖和標誌位,值得我們每個開發者學習。
2.4 unregister
登出就比較簡單了,把在註冊時往兩個資料結構中新增的訂閱者資訊刪除即可:
上面經常會提到黏性事件,為什麼要有這個設計呢?這裡舉個例子:我想在登陸成功後自動播放歌曲,而登陸和監聽登陸監聽是同時進行的。在這個前提下,如果登陸流程走得特別快,在登陸成功後播放模組才註冊了監聽。此時播放模組便會錯過了【登陸成功】的事件,出現“雖然登陸成功了,回撥卻沒執行”的情況。而如果【登陸成功】這個事件是一個黏性事件的話,那麼即使我後來才註冊了監聽(並且回撥方法設定為監聽黏性事件),則回撥就能在註冊的那一刻被執行,這個問題就能被優雅地解決,而不需要額外去定義其他標誌位。
至此大家對EventBus的執行原理應該有了一定的瞭解,雖然看起來像是一個複雜耗時的自動機,但大部分時候事件都是一瞬間就能分發到位的,而大家關心的效能問題反而是發生在註冊EventBus的時候,因為需要遍歷監聽者的所有方法去找到回撥的方法。作者也提到執行時註解的效能在Android上並不理想,為了解決這個問題,作者才會以索引的方式去生成回撥方法表(下一章會詳細介紹)。而EventBus原始碼分析的文章早已是數不勝數,這裡就不再大段大段地貼程式碼了,主要以類圖和流程圖的形式讓大家直觀地瞭解EventBus3的整體架構及核心功能的實現原理,把原始碼分析留到後面介紹EventBusAnnotationProcessor中再進行。大家如果想要深入學習EventBus 3的話,在本文結尾的參考文章中有很多寫得很棒的原始碼分析。
3. 渦輪引擎——索引加速
在EventBus 3的介紹中,作者提到以前的版本為了保證效能,在遍歷尋找訂閱者的回撥方法時使用反射而不是註解。但現在卻能在使用註解的前提下,大幅度提高效能,同時作者在部落格中放出了這張對比圖:
可以看到在效能方面,EventBus 3由於使用了註解,比起使用反射來遍歷方法的2.4版本遜色不少。但開啟了索引後效能像打了雞血一樣,遠遠超出之前的版本。這裡我們就來分析一下這個提高EventBus效能的“渦輪引擎”。(下面的原始碼分析為了方便閱讀,添加了部分註釋,並刪減了部分原始碼,如果有疑問的話可以到官方的github上檢視原版原始碼)
首先我們知道,索引是在初始化EventBus時通過EventBusBuilder.addIndex(SubscriberInfoIndex index)
方法傳進來的,我們就先看看這個方法:
public EventBusBuilder addIndex(SubscriberInfoIndex index) {
if(subscriberInfoIndexes == null) {
subscriberInfoIndexes = new ArrayList<>();
}
subscriberInfoIndexes.add(index);
return this;
}
可以看到,傳進來的索引資訊會儲存在subscriberInfoIndexes這個List中,後續會通過EventBusBuilder傳到相應EventBus的SubscriberMethodFinder例項中。我們先來分析SubscriberInfoIndex這個引數:
public interface SubscriberInfoIndex {
SubscriberInfo getSubscriberInfo(Class<?> subscriberClass);
}
可見索引只需要做一件事情——就是能拿到訂閱者的資訊。而實現這個介面的類如果我們沒有編譯過,是找不到的。這裡就得看我們在一開始在配置gradle時匯入的EventBusAnnotationProcessor:
@SupportedAnnotationTypes("org.greenrobot.eventbus.Subscribe")
@SupportedOptions(value = {"eventBusIndex", "verbose"})
public class EventBusAnnotationProcessor extends AbstractProcessor {
/** Found subscriber methods for a class (without superclasses). 被註解表示的方法資訊 */
private final ListMap<TypeElement, ExecutableElement> methodsByClass = new ListMap<>();
private final Set<TypeElement> classesToSkip = new HashSet<>(); // checkHasErrors檢查出來的異常方法
@Override
public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment env) {
Messager messager = processingEnv.getMessager();
try {
String index = processingEnv.getOptions().get(OPTION_EVENT_BUS_INDEX);
if (index == null) { // 如果沒有在gradle中配置apt的argument,編譯就會在這裡報錯
messager.printMessage(Diagnostic.Kind.ERROR, "No option " + OPTION_EVENT_BUS_INDEX +
" passed to annotation processor");
return false;
}
/** ... */
collectSubscribers(annotations, env, messager); // 根據註解拿到所有訂閱者的回撥方法資訊
checkForSubscribersToSkip(messager, indexPackage); // 篩掉不符合規則的訂閱者
if (!methodsByClass.isEmpty()) {
createInfoIndexFile(index); // 生成索引類
}
/** 列印錯誤 */
}
/** 下面這些方法就不再貼出具體實現了,我們瞭解它們的功能就行 */
private void collectSubscribers // 遍歷annotations,找出所有被註解標識的方法,以初始化methodsByClass
private boolean checkHasNoErrors // 過濾掉static,非public和引數大於1的方法
private void checkForSubscribersToSkip // 檢查methodsByClass中的各個類,是否存在非public的父類和方法引數
/** 下面這三個方法會把methodsByClass中的資訊寫到相應的類中 */
private void writeCreateSubscriberMethods
private void createInfoIndexFile
private void writeIndexLines
}
至此便揭開了索引生成的祕密,是在編譯時apt外掛通過EventBusAnnotationProcessor分析註解,並利用註解標識的相關類的資訊去生成相關的類。writeCreateSubscriberMethods中呼叫了很多IO函式,很容易理解,這裡就不貼了,我們直接看生成出來的類:
/** This class is generated by EventBus, do not edit. */
public class MyEventBusIndex implements SubscriberInfoIndex {
private static final Map<Class<?>, SubscriberInfo> SUBSCRIBER_INDEX;
static {
SUBSCRIBER_INDEX = new HashMap<Class<?>, SubscriberInfo>();
// 每有一個訂閱者類,就呼叫一次putIndex往索引中新增相關的資訊
putIndex(new SimpleSubscriberInfo(com.study.sangerzhong.studyapp.ui.MainActivity.class, true, new SubscriberMethodInfo[] {
new SubscriberMethodInfo("onEvent", com.study.sangerzhong.studyapp.ui.MainActivity.DriverEvent.class, ThreadMode.POSTING, 0, false),
// 類中每一個被Subscribe標識的方法都在這裡新增進來
}));
}
// 下面的程式碼就是EventBusAnnotationProcessor中寫死的了
private static void putIndex(SubscriberInfo info) {
SUBSCRIBER_INDEX.put(info.getSubscriberClass(), info);
}
@Override
public SubscriberInfo getSubscriberInfo(Class<?> subscriberClass) {
SubscriberInfo info = SUBSCRIBER_INDEX.get(subscriberClass);
if (info != null) {
return info;
} else {
return null;
}
}
}
可見,子類中hardcode了所有註冊了EventBus的類中被Subscribe註解標識的方法資訊,包括方法名、方法引數型別等資訊。並把這些資訊封裝到SimpleSubscriberInfo中,我們拿到的索引其實就是以訂閱者的類為Key、SimpleSubscriberInfo為value的雜湊表。而這些hardcode都是在編譯的時候生成的,避免了在在EventBus.register()時才去遍歷查詢生成,從而把在註冊時需要遍歷訂閱者所有方法的行為,提前到在編譯時完成了。
索引的生成我們已經明白了,那麼它是在哪裡被應用的呢?我們記得在註冊時,EventBus會通過SubscriberMethodFinder來遍歷註冊物件的Class的所有方法,篩選出符合規則的方法,並作為訂閱者在接收到事件時執行的回撥,我們直接來看看SubscriberMethodFinder.findSubscriberMethods()
這個核心方法:
List<SubscriberMethod> findSubscriberMethods(Class<?> subscriberClass) {
List<SubscriberMethod> subscriberMethods = METHOD_CACHE.get(subscriberClass);
if (subscriberMethods != null) {
return subscriberMethods; // 先去方法快取裡找,找到直接返回
}
if (ignoreGeneratedIndex) { // 是否忽略設定的索引
subscriberMethods = findUsingReflection(subscriberClass);
} else {
subscriberMethods = findUsingInfo(subscriberClass);
}
/** 把找到的方法儲存到METHOD_CACHE裡並返回,找不到直接丟擲異常 */
}
可以看到其中findUsingInfo()方法就是去索引中查詢訂閱者的回撥方法,我們戳進去看看這個方法的實現:
private List<SubscriberMethod> findUsingInfo(Class<?> subscriberClass) {
// 最新版的EventBus3中,尋找方法時所需的臨時變數都被封裝到了FindState這個靜態內部類中
FindState findState = prepareFindState(); // 到物件池中取得上下文,避免頻繁創造物件,這個設計很贊
findState.initForSubscriber(subscriberClass); // 初始化尋找方法的上下文
while (findState.clazz != null) { // 子類找完了,會繼續去父類中找
findState.subscriberInfo = getSubscriberInfo(findState); // 獲得訂閱者類的相關資訊
if (findState.subscriberInfo != null) { // 上一步能拿到相關資訊的話,就開始把方法陣列封裝成List
SubscriberMethod[] array = findState.subscriberInfo.getSubscriberMethods();
for (SubscriberMethod subscriberMethod : array) {
if (findState.checkAdd(subscriberMethod.method, subscriberMethod.eventType)) {
// checkAdd是為了避免在父類中找到的方法是被子類重寫的,此時應該保證回撥時執行子類的方法
findState.subscriberMethods.add(subscriberMethod);
}
}
} else { // 索引中找不到,降級成執行時通過註解和反射去找
findUsingReflectionInSingleClass(findState);
}
findState.moveToSuperclass(); // 上下文切換成父類
}
return getMethodsAndRelease(findState); // 找完後,釋放FindState進物件池,並返回找到的回撥方法
}
可以看到EventBus中在查詢訂閱者的回撥方法時是能處理好繼承關係的,不僅會去遍歷父類,而且還會避免因為重寫方法導致執行多次回撥。其中需要關心的是getSubscriberInfo()是如何返回索引資料的,我們繼續深入:
private SubscriberInfo getSubscriberInfo(FindState findState) {
if (findState.subscriberInfo != null && findState.subscriberInfo.getSuperSubscriberInfo() != null) { // subscriberInfo已有例項,證明本次查詢需要查詢上次找過的類的父類
SubscriberInfo superclassInfo = findState.subscriberInfo.getSuperSubscriberInfo();
if (findState.clazz == superclassInfo.getSubscriberClass()) { // 確定是所需查詢的類
return superclassInfo;
}
}
if (subscriberInfoIndexes != null) { // 從我們傳進來的subscriberInfoIndexes中獲取相應的訂閱者資訊
for (SubscriberInfoIndex index : subscriberInfoIndexes) {
SubscriberInfo info = index.getSubscriberInfo(findState.clazz);
if (info != null) { return info; }
}
}
return null;
}
可見就在這個方法裡面,應用到了我們生成的索引,避免我們需要在findSubscriberMethods時去呼叫耗時的findUsingReflection方法。在實際使用中,Nexus6上一個Activity註冊EventBus需要10毫秒左右,而使用了索引後能降低到3毫秒左右,效果非常明顯。雖然這個索引的實現邏輯有點繞,而且還存在一些坑(比如後面講到的混淆問題),但實現的手段非常巧妙,尤其是“把耗時的操作在編譯的時候完成”和“用物件池減少建立物件的效能開銷”的思想值得我們開發者借鑑。
4. 駕駛寶典——踩坑與經驗
4.1 混淆問題
混淆作為版本釋出必備的流程,經常會鬧出很多奇奇怪怪的問題,且不方便定位,尤其是EventBus這種依賴反射技術的庫。通常情況下都會把相關的類和回撥方法都keep住,但這樣其實會留下被人反編譯後破解的後顧之憂,所以我們的目標是keep最少的程式碼。
首先,因為EventBus 3棄用了反射的方式去尋找回調方法,改用註解的方式。作者的意思是在混淆時就不用再keep住相應的類和方法。但是我們在執行時,卻會報java.lang.NoSuchFieldError: No static field POSTING
。網上給出的解決辦法是keep住所有eventbus相關的程式碼:
-keep class de.greenrobot.** {*;}
其實我們仔細分析,可以看到是因為在SubscriberMethodFinder的findUsingReflection方法中,在呼叫Method.getAnnotation()時獲取ThreadMode這個enum失敗了,所以我們只需要keep住這個enum就可以了(如下)。
-keep public enum org.greenrobot.eventbus.ThreadMode { public static *; }
這樣就能正常編譯通過了,但如果使用了索引加速,是不會有上面這個問題的。因為在找方法時,呼叫的不是findUsingReflection,而是findUsingInfo。但是使用了索引加速後,編譯後卻會報新的錯誤:Could not find subscriber method in XXX Class. Maybe a missing ProGuard rule?
這就很好理解了,因為生成索引GeneratedSubscriberIndex是在程式碼混淆之前進行的,混淆之後類名和方法名都不一樣了(上面這個錯誤是方法無法找到),得keep住所有被Subscribe註解標註的方法:
-keepclassmembers class * {
@de.greenrobot.event.Subscribe <methods>;
}
所以又倒退回了EventBus2.4時不能混淆onEvent開頭的方法一樣的處境了。所以這裡就得權衡一下利弊:使用了註解不用索引加速,則只需要keep住EventBus相關的程式碼,現有的程式碼可以正常的進行混淆。而使用了索引加速的話,則需要keep住相關的方法和類。
4.2 跨程序問題
目前EventBus只支援跨執行緒,而不支援跨程序。如果一個app的service起到了另一個程序中,那麼註冊監聽的模組則會收不到另一個程序的EventBus發出的事件。這裡可以考慮利用IPC做對映表,並在兩個程序中各維護一個EventBus,不過這樣就要自己去維護register和unregister的關係,比較繁瑣,而且這種情況下通常用廣播會更加方便,大家可以思考一下有沒有更優的解決方案。
4.3 事件環路問題
在使用EventBus時,通常我們會把兩個模組相互監聽,來達到一個相互回撥通訊的目的。但這樣一旦出現死迴圈,而且如果沒有相應的日誌資訊,很難定位問題。所以在使用EventBus的模組,如果在回撥上有環路,而且回撥方法複雜到了一定程度的話,就要考慮把接收事件專門封裝成一個子模組,同時考慮避免出現事件環路。
5. 車神之路——寫在最後
當然,EventBus並不是重構程式碼的唯一之選。作為觀察者模式的“同門師兄弟”——RxJava,作為功能更為強大的響應式程式設計框架,可以輕鬆實現EventBus的事件匯流排功能(RxBus)。但畢竟大型專案要接入RxJava的成本高,複雜的操作符需要開發者投入更多的時間去學習。所以想在成熟的專案中快速地重構、解耦模組,EventBus依舊是我們的不二之選。
本文總結了EventBus 3的使用方法,執行原理和一些新特性,讓大家能直觀地看到這個元件的優點和缺點,同時讓大家在考慮是否在專案中引入EventBus時心裡有個底。最後感謝Markus Junginger大神開源瞭如此實用的元件,以及組內同事在筆者探究EventBus原理時提供的幫助,希望大家在看完本文後都能有所收穫,成為NB的Android開發老司機。
參考: