×

分析EventBus源码扩展Weex事件机制[源码]

96
MarchCd
2018.06.01 09:51* 字数 3058
分析EventBus源码扩展Weex事件机制

EventBus 是基于观察者模式的发布/订阅事件总线,它让组件间的通信变得更加简单。类似广播系统,不过 EventBus 所有的订阅和发送都是在内存层面的,使用起来远比广播简单,也更容易管理。

EventBus-Publish-Subscribe.png

先说明在事件总线中的几个关键词:

  • 事件发送者,发出事件的人
  • 订阅者,处理事件的人
  • 订阅者中处理事件的方法,因为每个订阅者感兴趣的事件有多种,因此会有多个处理事件的方法
  • 订阅,一个订阅指的是某个订阅者中的处理某个事件的方法,由订阅者和事件类型唯一确定。

订阅事件注册

当希望接受到事件时,需要在 onCreate() 执行 register() 方法,在注册方法中会检索当前类中声明的接受事件的方法,并将他们注册到对应的映射中。

public void register(Object subscriber) {
    Class<?> subscriberClass = subscriber.getClass();
    List<SubscriberMethod> subscriberMethods = subscriberMethodFinder.findSubscriberMethods(subscriberClass);
    synchronized (this) {
        for (SubscriberMethod subscriberMethod : subscriberMethods) {
            subscribe(subscriber, subscriberMethod);
        }
    }
}

内存中存储的数据结构有如下几个:

// 事件 - 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 注解的方法,存储到列表中。

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--;
            }
        }
    }
}

发送事件

当需要发送事件使用 EventBuspost() 方法。

借助 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 中有一个 BroadcastChannelAPI 用来实现页面间的通信,在原生部分使用 WebSocketModule 实现,不过经过实验发现,注册和发送没有什么大问题,不过在取消注册这块做的有漏洞,出现多次页面销毁但是无法取消对事件监听的情况(可能是当时尝试的时候版本低一些),主要是因为 module 的生命周期没能和 weex 页面实例更好的绑定起来,而且它是基于 W3C 的标准设计的,也没有实现类似粘滞事件这种功能的支持。

最后决定根据事件总线的机制来尝试实现页面之间的通信,在 Weex 中有一个 页面内 通信的接口,他是 nativeweex 通信的通道,可以用一个 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)
        }
    }
}

最后,目前只是一个简单的实现,能够基本实现页面间通信的需求,不过还需要更多地调研和其他端同学的配合,相信会越来越完善。


目前维护的几个项目,求 ✨✨✨✨

Android开发
Web note ad 1