前文
由于EventBus的源码还是比较的复杂的,打算使用五篇文章从浅入深的分析它的源码。包括:
postSticky
1 | //接收的方法 |
当我们需要接受一些滞后消息的时候,就需要通过Stickey消息实现。Stickey消息可以让订阅方法接收到之前发送的消息。他的发送方式是通过postSticky()
方法发送。
1 | public void postSticky(Object event) { |
从这段代码我们可以知道,通过该方法的事件会使用stickyEvents
缓存下来,同时开始进行事件的分发。也就是说假如当前的分发的订阅方法列表,无论是否是sticky
类型都能接收到。
然后,我们开始看我们的订阅方法是如何接收这些滞后消息的,首先我们的订阅方法的描述类SubscriberMethod
中有一个属性sticky
,值为true就代表可以接受sticky
消息。
重看register方法
我们之前的分析都是在如何查找订阅方法中,就findSubscriberMethods
的实现上,
1 | public void register(Object subscriber) { |
然后我们重点看下subscribe
方法
1 | private void subscribe(Object subscriber, SubscriberMethod subscriberMethod) { |
具体的可以看上面的代码的逐行分析,经过了subscribe
方法,我们的subscriptionsByEventType
就有了key为EventClass,value为所有对应的订阅了key的subscriber以及他的对应subscriberMethod,类似于<String.class,[FirstActivity,test(),FirstActivity,test2(),SecondActivity,test()]>
,然后typesBySubscriber
就存储了key为subscriber,value为他的所有的对应的方法,类似于<FirstActivity.class,[test(),test2()]>
,然后最终,假如是sticky
方法,就调用checkPostStickyEventToSubscription
进行分发。
1 | private void checkPostStickyEventToSubscription(Subscription newSubscription, Object stickyEvent) { |
移除sticky
看完代码我们就知道,sticky事件就是存储事件的方法,到了register
的时候再把事件通知过去达成目的,那我们日常使用的时候就需要注意重复收到事件的问题了。比如我们再A页面postSticky
了一个事件进入了B,这时候收到了事件,然后退出之后再次进入B又收到了,这时候就出问题了。我们就需要在收到了消息之后,在合适的地方进行移除(一般接收到就移除即可),移除的方法有下面几种。
1 | getStickyEvent(Class<T> eventType) ,获取eventType对应的sticky事件 |