「Android」分析EventBus源碼擴展Weex事件機制
本文來自尚妝前端團隊路遠html
發表於尚妝github博客，歡迎訂閱！前端
EventBus 是基於觀察者模式的發佈/訂閱事件總線，它讓組件間的通訊變得更加簡單。相似廣播系統，不過 EventBus 全部的訂閱和發送都是在內存層面的，使用起來遠比廣播簡單，也更容易管理。java
先說明在事件總線中的幾個關鍵詞：git
- 事件發送者，發出事件的人
- 訂閱者，處理事件的人
- 訂閱者中處理事件的方法，由於每一個訂閱者感興趣的事件有多種，所以會有多個處理事件的方法
- 訂閱，一個訂閱指的是某個訂閱者中的處理某個事件的方法，由訂閱者和事件類型惟一肯定。
訂閱事件註冊
當但願接受到事件時，須要在 onCreate() 執行 register() 方法，在註冊方法中會檢索當前類中聲明的接受事件的方法，並將他們註冊到對應的映射中。github
public void register(Object subscriber) {
Class<?> subscriberClass = subscriber.getClass();
List<SubscriberMethod> subscriberMethods = subscriberMethodFinder.findSubscriberMethods(subscriberClass);
synchronized (this) {
for (SubscriberMethod subscriberMethod : subscriberMethods) {
subscribe(subscriber, subscriberMethod);
}
}
}
複製代碼
內存中存儲的數據結構有以下幾個：apache
// 事件 - List<訂閱(Subscription)> 每一個訂閱由訂閱者、事件類型惟一肯定
private final Map<Class<?>, CopyOnWriteArrayList<Subscription>> subscriptionsByEventType;
// 訂閱者 - List<關注的事件> 每一個訂閱者可能關注多個事件
private final Map<Object, List<Class<?>>> typesBySubscriber;
// 事件對應下的粘滯事件
private final Map<Class<?>, Object> stickyEvents;
複製代碼
查找訂閱方法列表
當執行 register() 方法時，會藉助 SubscriberMethodFinder 類從註冊的對象的 Class 中查找。緩存
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);
}
if (subscriberMethods.isEmpty()) {
// 沒有找到任何的訂閱方法將會拋出異常，因此至少要用註解訂閱一個方法
} else {
// 針對這個 class 查找到訂閱的方法列表，存緩存，下次更快的返回
METHOD_CACHE.put(subscriberClass, subscriberMethods);
return subscriberMethods;
}
}
複製代碼
由於咱們不考慮索引的狀況，最終查找方法都會走到方法 findUsingReflectionInSingleClass，內部的原理相對簡單，遍歷該類的全部方法，找到共有的、只有一個參數、且帶有 @Subscribe 註解的方法，存儲到列表中。weex
private static final int MODIFIERS_IGNORE = Modifier.ABSTRACT | Modifier.STATIC | BRIDGE | SYNTHETIC;
private void findUsingReflectionInSingleClass(FindState findState) {
Method[] methods;
methods = findState.clazz.getDeclaredMethods();
for (Method method : methods) {
int modifiers = method.getModifiers();
// 共有的方法 & 不是靜態、抽象、不是編譯生成的方法
if ((modifiers & Modifier.PUBLIC) != 0 && (modifiers & MODIFIERS_IGNORE) == 0) {
Class<?>[] parameterTypes = method.getParameterTypes();
// 參數長度只能是1
if (parameterTypes.length == 1) {
Subscribe subscribeAnnotation = method.getAnnotation(Subscribe.class);
// 方法上面帶有 @Subscribe 註解
if (subscribeAnnotation != null) {
Class<?> eventType = parameterTypes[0];
if (findState.checkAdd(method, eventType)) {
ThreadMode threadMode = subscribeAnnotation.threadMode();
findState.subscriberMethods.add(new SubscriberMethod(method, eventType, threadMode,
subscribeAnnotation.priority(), subscribeAnnotation.sticky()));
}
}
}
}
}
}
複製代碼
這個過程是一個循環，每次都會向上查找當前類的父類，知道到達 java 內置的類中，這就意味着，父類中聲明的訂閱方法，在子類實例中也會接收到。查找的結果最終會生成一個 SubscriberMethod 的列表，這個類中存儲了訂閱方法的所有信息，數據結構以下：數據結構
public class SubscriberMethod {
final Method method; // 當前的方法，可執行
final ThreadMode threadMode; // 線程類型
final Class<?> eventType; // 參數的類型，也就是他訂閱的事件的類型
final int priority; // 優先級
final boolean sticky; // 是不是粘滯事件
String methodString; // 方法的字符串
}
複製代碼
訂閱到映射中
// 事件 - List<訂閱(Subscription)> 每一個訂閱由訂閱者、事件類型惟一肯定
private final Map<Class<?>, CopyOnWriteArrayList<Subscription>> subscriptionsByEventType;
// 訂閱者 - List<關注的事件>
private final Map<Object, List<Class<?>>> typesBySubscriber;
複製代碼
訂閱的過程就是根據訂閱者 Subscriber 及該訂閱者的某個處理事件的方法 SubscriberMethod 來生成 Subscription 而且存儲到映射當中。異步
private void subscribe(Object subscriber, SubscriberMethod subscriberMethod) {
// 存儲到 事件 - List<訂閱> 映射中
Class<?> eventType = subscriberMethod.eventType;
Subscription newSubscription = new Subscription(subscriber, subscriberMethod);
CopyOnWriteArrayList<Subscription> subscriptions = subscriptionsByEventType.get(eventType); // ... 不存在則建立新的
int size = subscriptions.size();
for (int i = 0; i <= size; i++) {
if (i == size || subscriberMethod.priority > subscriptions.get(i).subscriberMethod.priority) {
subscriptions.add(i, newSubscription);
break;
}
}
// 存儲到 訂閱者 - List<關注的事件> 映射中
List<Class<?>> subscribedEvents = typesBySubscriber.get(subscriber); // ... 不存在則建立新的
subscribedEvents.add(eventType);
// ...
// 對 Sticky Event 的處理，後面單獨說
}
複製代碼
取消註冊
因爲事件總線的機制基於內存實現，全部的訂閱都會存儲在內存中，所以必須在合適的時機取消註冊，來釋放佔用的內存空間。
當取消註冊時：
- 藉助以前存儲的
訂閱者-List<關注事件>的映射快速的獲取到，當前訂閱者感興趣的事件列表。 - 而後遍歷事件列表，從
事件-List<訂閱>的映射中，刪除全部的訂閱。 - 最後將當前訂閱者從
訂閱者-List<關注事件>刪除，完成取消訂閱的過程。
獲取當前訂閱者關注的所有事件，遍歷取消註冊。
public synchronized void unregister(Object subscriber) {
List<Class<?>> subscribedTypes = typesBySubscriber.get(subscriber);
if (subscribedTypes != null) {
for (Class<?> eventType : subscribedTypes) {
unsubscribeByEventType(subscriber, eventType);
}
typesBySubscriber.remove(subscriber);
} else {
}
}
// 從訂閱列表中刪除對應的訂閱
private void unsubscribeByEventType(Object subscriber, Class<?> eventType) {
List<Subscription> subscriptions = subscriptionsByEventType.get(eventType);
if (subscriptions != null) {
int size = subscriptions.size();
for (int i = 0; i < size; i++) {
Subscription subscription = subscriptions.get(i);
if (subscription.subscriber == subscriber) {
subscription.active = false;
subscriptions.remove(i);
i--;
size--;
}
}
}
}
複製代碼
發送事件
當須要發送事件使用 EventBus 的 post() 方法。
藉助 ThreadLocal 每一個線程單獨維護一個、且僅一個 PostingThreadState 對象，這個對象的數據結構以下, 內部存儲了當前發送事件狀態的的一些關鍵信息。
final static class PostingThreadState {
final List<Object> eventQueue = new ArrayList<Object>(); // 事件隊列
boolean isPosting; // 是否正在發送事件，是的話不須要啓動循環讀取事件
boolean isMainThread; // 是不是主線程
Subscription subscription; // 一個訂閱
Object event; // 當前的事件
boolean canceled; // 是否被取消
}
複製代碼
獲取本線程的 PostingThreadState 對象，進行初始化，並開始輪詢處理隊列中的事件。
public void post(Object event) {
PostingThreadState postingState = currentPostingThreadState.get();
List<Object> eventQueue = postingState.eventQueue;
eventQueue.add(event);
if (!postingState.isPosting) {
postingState.isMainThread = Looper.getMainLooper() == Looper.myLooper();
postingState.isPosting = true;
try {
// 從隊列中循環讀取事件處理
while (!eventQueue.isEmpty()) {
postSingleEvent(eventQueue.remove(0), postingState);
}
} finally {
postingState.isPosting = false;
postingState.isMainThread = false;
}
}
}
複製代碼
繼續往深裏面看 postSingleEvent() 方法，他每次處理一個從隊列中取出來的事件，這裏作了一個區分，是否支持繼承，這個值默認是 true，支持繼承時，若是對當前事件的父類、接口對應的事件感興趣，那麼他也能夠處理該事件。例如當前要處理 A 事件，A 繼承自 B，同時實現 C 接口，能處理 B,C 事件的訂閱者將也會參與處理此 A 事件。
private void postSingleEvent(Object event, PostingThreadState postingState) throws Error {
Class<?> eventClass = event.getClass();
boolean subscriptionFound = false;
if (eventInheritance) {
// 向父類搜索，將父類、接口所有查找到
List<Class<?>> eventTypes = lookupAllEventTypes(eventClass);
int countTypes = eventTypes.size();
for (int h = 0; h < countTypes; h++) {
Class<?> clazz = eventTypes.get(h);
subscriptionFound |= postSingleEventForEventType(event, postingState, clazz);
}
} else {
subscriptionFound = postSingleEventForEventType(event, postingState, eventClass);
}
if (!subscriptionFound) {
// 沒有找到訂閱的方法，處理分支
}
}
複製代碼
事件訂閱者排隊處理
接下來會走 postSingleEventForEventType() 方法，這個方法負責找到對這個事件感興趣的 訂閱 Subscription 列表， Subscription 裏面包含了訂閱者、處理對應事件的方法等信息。
拿到列表以後便循環將事件給列表中的訂閱依次處理，在以前註冊時，是有一個優先級別的，優先級高的將會先得到處理事件的權利。
優先級別較高的處理者能夠中止事件的傳遞，只須要拋出一個異常，被 finally 塊捕捉後，就會中斷輪詢，從而終止事件的傳遞。
private boolean postSingleEventForEventType(Object event, PostingThreadState postingState, Class<?> CopyOnWriteArrayList<Subscription> subscriptions; synchronized (this) {
subscriptions = subscriptionsByEventType.get(eventClass);
}
// 遍歷全部的訂閱，處理事件
if (subscriptions != null && !subscriptions.isEmpty()) {
for (Subscription subscription : subscriptions) {
postingState.event = event;
postingState.subscription = subscription;
boolean aborted = false;
try {
// 讓 subscription 處理 event
postToSubscription(subscription, event, postingState.isMainThread);
aborted = postingState.canceled;
} finally {
// 若是優先級別較高的處理者異常，則後續處理者將沒法處理該事件
postingState.event = null;
postingState.subscription = null;
postingState.canceled = false;
}
// 退出輪詢
if (aborted) {
break;
}
}
return true;
}
return false;
}
複製代碼
分發線程處理者執行
處理事件的最後一步，是 postToSubscription() 他負責將事件的處理分發到不一樣的線程隊列中，在添加訂閱註解 @Subscribe 時能夠指定 threadMode，這極大的方便了咱們在事件傳遞後切換不一樣線程處理事件，例如咱們經常要在子線程處理數據，而通知主線程更新 UI，使用 EventBus 只須要指定 @Subscribe(threadMode=ThreadMode.Main) 則在處理事件時全部操做在內部便被切換到了主線程，真正作到了對線程切換的無感知。
分爲了以下幾種類型：
POSTING發送線程，或者說是當前線程更貼切一些，在其餘類庫中一般叫Immediate， 也就是不用切換線程。MAIN主線程，不解釋。BACKGROUND後臺線程，若是發送線程是主線程，則開闢新的線程執行，不然將在當前線程執行。ASYNC異步線程，不管怎樣，老是開啓新的子線程去執行。
這裏就要看一下幾個處理者 HandlerPoster/BackgroundPoster/AsyncPoster 實現原理大體相同，內部維護一個隊列，不停的把裏面的事件取出來處理。
HandlerPoster是基於Handler實現對隊列的輪詢。BackgroundPoster則是用死循環來作的，誰讓人家有本身的線程呢。AsyncPoster就更富了，根本不輪詢，每次都是一個新的線程。
private void postToSubscription(Subscription subscription, Object event, boolean isMainThread) {
switch (subscription.subscriberMethod.threadMode) {
case POSTING:
invokeSubscriber(subscription, event);
break;
case MAIN:
if (isMainThread) {
invokeSubscriber(subscription, event);
} else {
mainThreadPoster.enqueue(subscription, event);
}
break;
case BACKGROUND:
if (isMainThread) {
backgroundPoster.enqueue(subscription, event);
} else {
invokeSubscriber(subscription, event);
}
break;
case ASYNC:
asyncPoster.enqueue(subscription, event);
break;
}
}
複製代碼
最終調用的 invokeSubscriber() 很簡單就是利用反射調一下對應的 method
subscription.subscriberMethod.method.invoke(subscription.subscriber, event);
複製代碼
粘滯事件的實現
我把 Sticky Event 翻譯成 粘滯事件 不知道對不對，他的出現主要是由於咱們須要處理事件是老是要先註冊再發送事件，根本緣由在於當一個事件發出時，他的生命週期很短，全部對他感興趣的訂閱者處理完了以後他就被拋棄了，後面的訂閱者再感興趣也沒用，由於早就被清理啦。
要解決這個問題也很簡單，就是延長事件的生命週期，即便你們都不理他了，他也能頑強的活着，萬一後面還有人對他感興趣呢。因此實現的原理也就很明瞭了，找個列表把它所有存起來，除非你手動給刪除，不然就 粘不拉幾 的附着在你的內存裏，等着他的真命天子出現。
// 事件類型 - 事件實例
private final Map<Class<?>, Object> stickyEvents;
// 發送粘滯事件時，先存起來給後面的人用，而後按照常規流發送出去
public void postSticky(Object event) {
synchronized (stickyEvents) {
stickyEvents.put(event.getClass(), event);
}
post(event);
}
複製代碼
還要提供一個渠道，讓新加入進來的訂閱者可以察覺到這裏有粘滯事件的存在，若是感興趣也能夠處理它。這個時機就是註冊時，當一個訂閱者被添加到註冊表中時，此時若是存在粘滯事件，用當前訂閱者感興趣的事件爲 key 獲取存在的粘滯事件，若是有感興趣的就臨幸一下。因而能夠完善一下以前未說完的 register() 方法：
- 首先要求當前訂閱者的處理事件的方法要對粘滯事件感興趣，這個在註解上能夠聲明。
- 繼承，若是支持繼承，當前事件的子類粘滯事件都會被取出來檢查是否能夠被處理。
private void subscribe(Object subscriber, SubscriberMethod subscriberMethod) {
// ... 前面這塊說過了
// 這個訂閱者的這個訂閱方法是對粘滯事件感興趣的
if (subscriberMethod.sticky) {
// 事件是否繼承
if (eventInheritance) {
Set<Map.Entry<Class<?>, Object>> entries = stickyEvents.entrySet();
// 當前事件的子類粘滯事件都會被取出來檢查是否能夠被處理
for (Map.Entry<Class<?>, Object> entry : entries) {
Class<?> candidateEventType = entry.getKey();
if (eventType.isAssignableFrom(candidateEventType)) {
Object stickyEvent = entry.getValue();
checkPostStickyEventToSubscription(newSubscription, stickyEvent);
}
}
} else {
Object stickyEvent = stickyEvents.get(eventType);
checkPostStickyEventToSubscription(newSubscription, stickyEvent);
}
}
}
複製代碼
接下來的 checkPostStickyEventToSubscription() 就會調用前面已經說過的 postToSubscription() 方法，開始發送到不一樣的線程中執行，這部分和普通的事件是同樣的啦。
理解事件的繼承
粘滯事件這裏也出現了一個關於事件繼承的檢索，在上一節也出現了一次，單獨拿出來講一下異同之處。
能夠類比函數入參的限制，若是一個方法聲明中參數是父類，那麼傳參時能夠傳遞子類對象進去，聲明瞭子類的話，是不能傳遞父類對象的。
舉個例子，設定下場景，咱們如今有事件基類 BaseEvent 和一個事件子類 ImplEvent 是繼承關係。
第一種場景，發送普通事件，我發送了一個 ImplEvent，由於我發的是個子類事件，也就是說全部聲明關注 BaseEvent 的訂閱者也均可以將當前事件做爲入參，因此向上檢索對 ImplEvent 父類、父接口感興趣的訂閱者去執行。
第二個場景，發送粘滯事件，發送一個 BaseEvent 的粘滯事件，由於是在註冊時觸發執行，那麼說明當前訂閱者對 BaseEvent 感興趣，既然他的入參是父類事件，那麼子類事件也一樣能夠做爲他的處理事件方法的入參，因而檢索全部粘滯事件找到全部 BaseEvent 的子類事件都交給當前訂閱者處理。
Weex 事件機制
在 Weex 中有一個 BroadcastChannel 的 API 用來實現頁面間的通訊，在原生部分使用 WebSocketModule 實現，不過通過實驗發現，註冊和發送沒有什麼大問題，不過在取消註冊這塊作的有漏洞，出現屢次頁面銷燬可是沒法取消對事件監聽的狀況（多是當時嘗試的時候版本低一些），主要是由於 module 的生命週期沒能和 weex 頁面實例更好的綁定起來，並且它是基於 W3C 的標準設計的，也沒有實現相似粘滯事件這種功能的支持。
最後決定根據事件總線的機制來嘗試實現頁面之間的通訊，在 Weex 中有一個 頁面內 通訊的接口，他是 native 和 weex 通訊的通道，能夠用一個 key 做爲標示符，觸發當前 weex 頁面中對 key 事件感興趣的的方法，關於 weex 相關的內容這裏不細說。
((WXSDKInstance)instance).fireGlobalEventCallback(key, params)
複製代碼
實現原理相似 EventBus，不過由於基於 weex 就沒那麼複雜，一樣須要維護一個註冊表，相對於 EventBus 要對訂閱者強引用持有，這裏使用了每一個 weex 頁面惟一的 instanceId 做爲標記，存儲這個標記而不是存儲真正的 WXSDKInstance 對象，避免內存泄漏。
private val mEventInstanceIdMap by lazy { mutableMapOf<String, MutableSet<String>>() }
複製代碼
註冊，當 weex 那邊發起註冊時，拿到對應的 instanceId 存儲到映射中。
// 註冊接受某事件
// event.registerEvent('myEvent')
// globalEvent.addEventListener('myEvent', (params) => {});
fun registerEvent(key: String?, instantId: String?) {
// do check...
val nonNullKey = key ?: return
val registerInstantIds = mEventInstanceIdMap[nonNullKey] ?: mutableSetOf()
registerInstantIds.add(instantId)
mEventInstanceIdMap[nonNullKey] = registerInstantIds
}
複製代碼
發送事件時，根據事件的 key 拿到對他關注的訂閱者的 instanceId 列表，循環從 weex sdk 中取出真正的 WXSDKInstance 對象，再利用頁面內通訊的 API 將事件發送給指定頁面，達到頁面間通訊的目的。
// 發送事件
// event.post('myEvent',{isOk:true});
fun postEvent(key: String, params: Map<String, Any>) {
// do check...
val registerInstantIds = mEventInstanceIdMap[key] ?: listOf<String>()
val allInstants = renderManager.allInstances
for (instance in allInstants) {
// 遍歷找到訂閱的 instanceId 進而拿到 weex 實例發送頁面內事件
if (instance != null
&& !instance.instanceId.isNullOrEmpty()
&& registerInstantIds.contains(instance.instanceId)) {
instance.fireGlobalEventCallback(key, params)
}
}
}
複製代碼
當頁面銷燬時，同時自動取消註冊，釋放內存和避免沒必要要的事件觸發
override fun onWxInstRelease(weexPage: WeexPage?, instance: WXSDKInstance?) {
val nonNullId = instance?.instanceId ?: return
for (mutableEntry in mEventInstanceIdMap) {
if (mutableEntry.value.isNotEmpty()) {
mutableEntry.value.remove(nonNullId)
}
}
}
複製代碼
最後，目前只是一個簡單的實現，可以基本實現頁面間通訊的需求，不過還須要更多地調研和其餘端同窗的配合，相信會愈來愈完善。
目前維護的幾個項目，求 ✨✨✨✨
- 1. Android事件分發機制源碼解析(二)-ViewGroup的事件分發機制
- 2. Android事件分發機制源碼解析(一)-View的事件分發機制
- 3. View事件機制源碼分析
- 4. React源碼分析 - 事件機制
- 5. ApplicationEvent事件機制源碼分析
- 6. EventBus源碼分析
- 7. EventBus 源碼分析
- 8. Weex源碼分析
- 9. Android源碼分析——ViewGroup的事件分發機制（二）
- 10. 基於源碼分析 Android View 事件分發機制
- 更多相關文章...
- • Kotlin 擴展 - Kotlin 教程
- • Swift 擴展 - Swift 教程
- • 漫談MySQL的鎖機制
- • 再有人問你分佈式事務，把這篇扔給他
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 融合阿里雲，牛客助您找到心儀好工作
- 2. 解決jdbc(jdbctemplate)在測試類時不報錯在TomCatb部署後報錯
- 3. 解決PyCharm GoLand IntelliJ 等 JetBrains 系列 IDE無法輸入中文
- 4. vue+ant design中關於圖片請求不顯示的問題。
- 5. insufficient memory && Native memory allocation (malloc) failed
- 6. 解決IDEA用Maven創建的Web工程不能創建Java Class文件的問題
- 7. [已解決] Error: Cannot download ‘https://start.spring.io/starter.zip?
- 8. 在idea讓java文件夾正常使用
- 9. Eclipse啓動提示「subversive connector discovery」
- 10. 帥某-技巧-快速轉帖博主文章（article_content）