EventBus源码分析（一）

EventBus源码分析（一）

EventBus官方介绍为一个为Android系统优化的事件订阅总线，它不仅可以很方便的在同线程中传递事件或者对象，还可以在不同线程中实现事件或对象的传递，用法比较简单，可以很好地完成一些在原生系统中的Intent，Handler等可以完成的工作，在Android开发过程中用途及其广泛，这里不再介绍它的具体用法，由于在工作中遇到过一些关于EventBus的问题，所以计划学习一下EventBus的设计与实现。接下来的几篇文章记录对于EventBus源码的学习过程，阅读其源码，不仅可以在遇到问题时可以很快找到原因，更重要的是发现EventBus源码程序中的类型结构层次以及数据结构的设计有很多值得我们借鉴的地方。
EventBus的整体结构是典型的观察者模式，其工作流程如下：

EventBus-Publish-Subscribe.png

在传统的观察者模式中，被观察者记录订阅者的信息，在事件发生以后依次调用订阅者的相应方法。EventBus对其做了扩展，将订阅信息的管理和事件的分发调度从被观察者中抽离出来，就是我们的EventBus, 它作为一个事件总线，被观察者在事件发生后可以将事件推送到事件总线上，EventBus负责在合适的时机调用订阅者的相应方法。由于EventBus的存在，被观察者和订阅者分离，所以我们的程序中使用EventBus传递事件或对象及其简单，中间过程全交由EventBus处理，本篇文章的重点就是关注EventBus在中间所做的事情。简单来说，EventBus的任务就是传统观察者当中被观察者的管理注册信息和调度方法两项任务。下面我们从EventBus这个类的源码开始分析，首先从构造器开始。

1. 构造器

EventBus的构造方式是典型的建造者模式，首先看我们获取EventBus最常用的方法，getDefault()

/** Convenience singleton for apps using a process-wide EventBus instance. */
public static EventBus getDefault() {
    if (defaultInstance == null) {
        synchronized (EventBus.class) {
            if (defaultInstance == null) {
                defaultInstance = new EventBus();
            }
        }
    }
    return defaultInstance;
}

如注释所说，这里是传统的单例模式，通常在一个应用中使用同一个EventBus即可，这样方便事件的处理，同时EventBus对事件的注册和调度方法都是线程安全的，我们在后面就会看到，所以单例非常适合。接下来看默认构造器：

 public EventBus() {
        this(DEFAULT_BUILDER);
    }

DEFAULT_BUILDER是一个静态的构造者，其中包含一系列的默认属性，最后就是以建造者为参数的构造器，过程就是一系列的参数初始化，代码如下：

EventBus(EventBusBuilder builder) {
        subscriptionsByEventType = new HashMap<>();  //以事件类的class对象为键值，记录注册方法信息，值为一个Subscription的列表
        typesBySubscriber = new HashMap<>();   //以注册的类为键值，记录该类所注册的所有事件类型，值为一个Event的class对象的列表
        stickyEvents = new ConcurrentHashMap<>();  //记录sticky事件
        //三个Poster, 负责在不同的线程中调用订阅者的方法
        mainThreadPoster = new HandlerPoster(this, Looper.getMainLooper(), 10);
        backgroundPoster = new BackgroundPoster(this);
        asyncPoster = new AsyncPoster(this);
        ...
        //方法的查找类，用于查找某个类中有哪些注册的方法
        subscriberMethodFinder = new SubscriberMethodFinder(builder.subscriberInfoIndexes,
                builder.strictMethodVerification, builder.ignoreGeneratedIndex);
        ...
        //后面是一些表示开关信息的boolean值以及一个线程池
    }

这里省略了一部分暂时没有分析到的参数。首先来看管理注册信息的两个Map, 由于一个类中可能有多个方法监听多个事件，所以Subscription这个类封装一个注册信息，这个类很简单，只有三个属性，如下：

final class Subscription {
    final Object subscriber;
    final SubscriberMethod subscriberMethod;
    /**
     * Becomes false as soon as {@link EventBus#unregister(Object)} is called, which is checked by queued event delivery
     * {@link EventBus#invokeSubscriber(PendingPost)} to prevent race conditions.
     */
    volatile boolean active;

    //之后为构造器以及覆写的equal和hashCode方法。
    ...
}

public class SubscriberMethod {
    final Method method;
    final ThreadMode threadMode;
    final Class eventType;
    final int priority;
    final boolean sticky;
    /** Used for efficient comparison */
    String methodString;

    //之后为构造器以及覆写的equal和hashCode方法。
    ...

所以类和方法唯一确定一条注册信息，active表示该注册信息是否有效(如注释所说它的作用)。所以在EventBus中，使用subscriptionsByEventType，以Event的class对象为键值，管理注册信息，值为一个处理事件类型为该键值的Subscription的列表。typesBySubscriber则相对简单，就是记录一个类注册了哪些事件类型。虽然二者有所冗余，它们在后面的注册和调度过程中都是为了便于查询，这样更为高效。
然后是stickyEvents，是一个线程安全的Map,用来记录sticky事件，sticky事件的含义是指即使被观察者发送sticky事件是在订阅者订阅该事件之前，订阅者在订阅之后，EventBus将该事件发送到该订阅者，即调用相应的订阅方法。（如果在之后，那就和普通事件一样）
接下来的三个Poster极为重要，但是这里理解很容易，就是负责在不同线程中调用方法，他们分别对应着threadMode中除去POSTING之外三种类型。
最后是一个Finder，由于在EventBus的使用简便，都是以对象为单位调用registe()方法，但是一个对象中可能有多个注册方法，所以注册过程中需要subscriberMethodFinder查找一个类中有哪些注册方法，最后生成一个Subscrip，并存在subscriptionsByEventType的某一个列表中。

EventBus的构造器很简单，这里重点讲述了一下其中的几个比较重要的成员变量，尤其是管理注册信息的数据结构，下一步就是注册源码的分析。

2. 注册

注册方法rigister()的代码如下：

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

思路很明确，两个步骤，一是查找注册方法的列表，这个利用到了SubscriberMethodFinder的对应方法，查找一个类中有哪些注册方法，而是调用订阅方法，参数为类和方法两个，即subscriber和subscriberMethod。查找我们留到下一部分，先看订阅方法：

 // Must be called in synchronized block
private void subscribe(Object subscriber, SubscriberMethod subscriberMethod) {
    Class eventType = subscriberMethod.eventType;
    Subscription newSubscription = new Subscription(subscriber, subscriberMethod);
    CopyOnWriteArrayList subscriptions = subscriptionsByEventType.get(eventType);
    if (subscriptions == null) {
        subscriptions = new CopyOnWriteArrayList<>();
        subscriptionsByEventType.put(eventType, subscriptions);
    } else {
        if (subscriptions.contains(newSubscription)) {
            throw new EventBusException("Subscriber " + subscriber.getClass() + " already registered to event "
                    + 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> subscribedEvents = typesBySubscriber.get(subscriber);
    if (subscribedEvents == null) {
        subscribedEvents = new ArrayList<>();
        typesBySubscriber.put(subscriber, subscribedEvents);
    }
    subscribedEvents.add(eventType);

    if (subscriberMethod.sticky) {
        if (eventInheritance) {
            // Existing sticky events of all subclasses of eventType have to be considered.
            // Note: Iterating over all events may be inefficient with lots of sticky events,
            // thus data structure should be changed to allow a more efficient lookup
            // (e.g. an additional map storing sub classes of super classes: Class -> List).
            Set, Object>> entries = stickyEvents.entrySet();
            for (Map.Entry, 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);
        }
    }
}

代码虽然有点长，但是逻辑很简单清晰，就是构建Subscription, 然后将该注册信息保存到两个数据结构中。对于subscriptionsByEventType首先获取EventType对应的列表，没有则创建，重复注册则抛异常，正常情况下，则根据priority插入到列表中适合的位置。对于typesBySubscriber，则是更新该subscriber对应的列表即可。最后是处理sticky事件，即在注册时，如果是监听sticky事件，则需要从stickyEvents中取出对应sticky事件，并发送到订阅者。这里需要注意eventInheritance是一个开关，表示是否处理EventType的继承关系，默认为true，如代码中，EventBus会向订阅者发送该类型的事件，以及该类型所有子类类型的事件。由于订阅者监听一个sticky事件，那么该sticky事件的子类型也可以认为是该类型的事件，所以订阅者也同样会接收到该事件。最后checkPostStickyEventToSubscription方法如下：

private void checkPostStickyEventToSubscription(Subscription newSubscription, Object stickyEvent) {
    if (stickyEvent != null) {
        // If the subscriber is trying to abort the event, it will fail (event is not tracked in posting state)
        // --> Strange corner case, which we don't take care of here.
        postToSubscription(newSubscription, stickyEvent, Looper.getMainLooper() == Looper.myLooper());
    }
}

代码很简单，至于如何发送，放到第三部分统一分析，注释中说的订阅者不能终止sticky事件的发送，至于posting state则同样放在但三部分说明。

注册过程就是这些，还有一个重要且稍微复杂的查找过程放在第二篇中分析，在分析事件分发之前，与注册相反的unrigister由于比较简单，这里一并说了，下面是其代码：

 /** Unregisters the given subscriber from all event classes. */
public synchronized void unregister(Object subscriber) {
    List> subscribedTypes = typesBySubscriber.get(subscriber);
    if (subscribedTypes != null) {
        for (Class eventType : subscribedTypes) {
            unsubscribeByEventType(subscriber, eventType);
        }
        typesBySubscriber.remove(subscriber);
    } else {
        Log.w(TAG, "Subscriber to unregister was not registered before: " + subscriber.getClass());
    }
}

逻辑很明确，调用unsubscribeByEventType方法，并更新typesBySubscriber数据结构，那么你可能猜到了，unsubscribeByEventType方法中就是更新另一个数据结构，代码如下：

/** Only updates subscriptionsByEventType, not typesBySubscriber! Caller must update typesBySubscriber. */
private void unsubscribeByEventType(Object subscriber, Class eventType) {
    List 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--;
            }
        }
    }
}

这里逻辑很简单，但是有一点值得注意的是就遍历删除列表时，注意序号i和size的改变，容易出现数组越界的错误，遍历删除通常使用倒序的方式，不容易出现错误，这里动态改变size变量也是一样。注销过程需要考虑sticky事件，也不需要查找过程，所以过程很简单。
register和unregister的过程除了查找订阅方法以外，逻辑很简单，就是更新一下管理注册信息的数据结构，可以看出数据结构的设计还是很重要的，设计的好，逻辑就会很清晰，程序代码也就相对简洁易懂。下一步就是介绍事件的分发。

3. 事件分发

在分析post()方法之前，先看EventBus的一个内部类，PostState：

/** For ThreadLocal, much faster to set (and get multiple values). */
final static class PostingThreadState {
    final List