续上一篇调用register订阅后，下一步就是调用post发布事件。
首先看EventBus的post 方法
event是发布事件的参数，tag是事件指定的tag，利用event和tag创建一个EventType,并添加到mLocalEvents。
mLocalEvents是一个由ThreadLocal维护的事件类型队列的副本，主要处理多线程间并发问题。
接着调用mDispatcher的dispatchEvents方法，mDispatcher是事件分发器EventDispatcher的实例。
在dispatchEvents方法中，使用mLocalEvents.get() 先取出当前线程的事件类型的EventType队列，然后循环取出每个EventType并调用deliveryEvent方法处理每一个EventType。
在循环调用deliveryEvent方法时，deliveryEvent会调用getMatchedEventTypes方法，将事件类型EventType和事件实体参数传入。
接着看getMatchedEventTypes方法代码，
这里出现一个mCacheEventTypes，mCacheEventType是缓存一个事件类型对应的已发布的EventType列表的map集合.如果缓存中已存在对应的EventType列表，直接使用，否则会调用mMatchPolicy.findMatchEventTypes().
mMatchPolicy是DefaultMatchPolicy的实例对象，实现了MatchPolicy接口。这里我将mMatchPolicy理解为一个事件参数匹配器，为什么这样理解？
因为findMatchEventTypes方法用aEvent（事件实体参数）实例化一个事件类型EventType，接着将EventType和aEvent的对象类传入addInterfaces方法中，addInterfaces中又根据aEvent的对象类利用反射获取其实现的接口，循环每个接口实例化其接口的事件类型EventType后，添加到集合中。findMatchEventTypes方法还获取aEvent的父类继续调用addInterfaces方法。
例如：post发布事件的参数是某个父类的子类，订阅者中的订阅方法的参数是这个父类，并且post的tag与订阅方法注解的tag相同，那么这个订阅方法会被调用。
回到代码中，findMatchEventTypes方法会返回结果给getMatchedEventTypes方法，getMatchedEventTypes方法也将其结果返回到deliveryEvent中，然后循环匹配成功的EventType集合，并调用handleEvent方法。
mSubcriberMap在上一篇register流程中提到，mSubcriberMap是一个事件类型对应订阅者的集合。
handleEvent中根据匹配成功的EventType获取对应的订阅者Subscription，如不为空，则根据Subscription中的线程模式获取相关的事件处理器。
假如线程模式为POST，则会使用DefaultEventHandler处理器处理事件。
DefaultEventHandler的handleEvent方法中，使用subscription获取订阅者（subscription.subscriber.get()）和订阅方法（subscription.targetMethod），然后利用反射执行订阅方法。至此，post的流程结束。
