EventBus 3.0源码解析

今天的文章是 Nipuream 的第二篇投稿,上一篇他投稿的《浅谈Android生产者消费者模式》有不少读者点赞,跟我说就喜欢看这种有深度的文章。那么,本篇文章同样有深度,讲解的是EventBus 3.0版本的用法和源码解析。现在网上讲解EventBus的文章大多数都是针对2.x版本的,比较老旧,本篇文章希望可以给大家在新版本上面带来帮助。

Nipuream 的博客地址:http://blog.csdn.net/yanghuinipurean

基本使用

EventBus 3.0源码解析

EventBus 是专门为Android设计的用于订阅,发布总线的库,用到这个库的app很多,因为它有很多的优点。比如:

  • 它可以简单Android组件之间的通信
  • 它可以避免了Android四大组件复杂的生命周期处理
  • 它可以让你的代码更为简洁。

先一起了解下如何使用,然后在分析它的源码,知道它的工作原理。我们直接来使用 EventBus 3.0,3.x主要的一个新的特性就是使用了注解,我们的 Subscribe 可以在代码中就指定我们的 EventBus 使用什么 ThreadMode,是否粘性事件,优先级。

EventBus 3.0源码解析

这些,等会在源码分析的时候会讲,先看看如何使用:

EventBus 3.0源码解析

视图上显示一个TextView和一个Button,点击按钮的时候,就执行NetWork任务请求,请求执行结束后,在 onEventMainThread 方法更新UI,下面是 NetWork :

EventBus 3.0源码解析

代码看起来要比广播和回调方便多了,下面是UI显示:

EventBus 3.0源码解析

源码分析

初始化

EventBus 3.0源码解析

上面是 EventBus 初始化的三个步骤,直观上看用到 单例模式和Builder模式,将构造参数给分离了出来,实际上还用到了策略模式,其中Builder中有些参数用于代码执行的策略,就说,你传的参数不一样,我执行的方式不一样,像 ignoreGeneratedIndex 作用就是让 EventBus 如何查找出订阅方法的策略。这些布尔类型的参数,在分析代码中可以逐步的了解到,先了解一些缓存对象,以更容易的了解源码:

  • subscriptionsByEventType : 内部是一个Map集合,可以根据 EventType 查找订阅事件。
  • typesBySubscriber : 根据我们的订阅对象找到 EventType
  • stickyEvents : 粘性事件的缓存。
  • 事件投递者 : mainThreadPoster, backgroundPoster, asyncPoster 根据订阅注解 ThreadMode 去选择不同的投递者,不同投递者投递事件,接收函数会执行在不同的线程中。
  • subscriberMethodFinder :查找方法用的,内部维护了一个订阅方法的集合。

注册

EventBus 3.0源码解析

当我们调用 register(this) 的时候就把订阅者给传了进来,代码量很少,主要就两个步骤,第一个 findSubscriberMethods 找出一个 SubscriberMethod 的集合,然后就遍历 SubscriberMethod 去订阅事件,我们先看看 findSubscriberMethods() 里面到底做了什么,返回的是什么。

EventBus 3.0源码解析

首先从缓存中查找,如果找到了就立马返回。如果缓存中没有的话,则根据 ignoreGeneratedIndex 选择如何查找订阅方法,最后,找到订阅方法后,放入缓存,以免下次继续查找。ignoreGeneratedIndex 默认就是 false,那我们会执行 findUsingInfo() 方法,但是这里先分析 findUsingReflection(),因为在我们没有做任何配置的情况下还是会执行上面的 findUsingReflection(),就是通过反射来解析注解。

EventBus 3.0源码解析

从上面的代码块,我们可以看到,第一步准备 FindState,我们点进去看看:

EventBus 3.0源码解析

这里我们先了解从池中拿出一个 FindState对象,FindState 中维护的就是我们对订阅方法查找结果的封装。其实,往后面,我们就知道作者这里设计的非常精妙。第二步,initForSubscriber() 就是将我们的订阅者传给FindState对象。第三步做的就是不断从订阅者和订阅者的父类去查找订阅方法,一起看 findUsingReflectionInSingleClass():

EventBus 3.0源码解析

代码很长,其实就是对订阅者方法的遍历,看有没有注解,有的话就解析注解,最后将找到的订阅方法的集合封装到 FindState 对象中的 subscriberMethods 集合中。我们解析完了之后,在看 findUsingReflection() 方法的最后,返回了 getMethodsAndRelease(FindState),将我们的 FindState 传给了getMethodsAndRelease() 方法,好,我们点进去:

EventBus 3.0源码解析

从这里,我们就知道作者设计 FindState池的初心了,解析完了之后,将订阅方法赋给List集合,再回收 FindState,继续接收解析,内存没有半点浪费。最后,我们返回的是一个订阅方法的集合。这样,我们通过反射解析注解,找到订阅方法的方式,我们已经分析完了。再看看通过apt处理器来找,我们知道apt处理,是针对源码的处理,是执行在编译过程中的。所以性能要比反射好的多,所以推荐大家使用这种方式。好,那最开始,我说使用 findUsingInfo() 方法如果没有配置还是使用反射呢,我们一起看看:

EventBus 3.0源码解析

上面,我注释解析的很清楚了,前几步的操作基本一致,主要看 getSubscriberInfo(findState) 这个方法:

EventBus 3.0源码解析

上面一段代码是针对缓存的,如果缓存中有就直接返回,底下,是从 subscriberInfoIndexes 中查找订阅信息的。那么,我们的 subscriberInfoIndexes 从哪来的呢,是 EventBus Builder 对象:

public class EventBusBuilder {
 private final static ExecutorService DEFAULT_EXECUTOR_SERVICE = Executors.newCachedThreadPool();
 ...... List<SubscriberInfoIndex> subscriberInfoIndexes;

默认是空的,所以结合上面的代码,还是执行了 findUsingReflection() 方法。那么,我们应该如何操作呢?我们需要配置下。第一步引入EventBusAnnotationProcessor 库:

EventBus 3.0源码解析

这个库是在预编译过程,对我们的代码进行处理,找到我们有订阅方法的类的。第二步,配置项目的build.gradle文件:

EventBus 3.0源码解析

将我们的库和 andorid-apt 引入,其中参数 arguments 是指定,我们处理完我们的源码文件,生成的文件名的。好,我们rebuild一下我们的项目。然后在build文件夹下面发现了:

EventBus 3.0源码解析

我们点进去看看:

EventBus 3.0源码解析

把我们的订阅类和订阅方法全找出来了,当,我们这个类初始化的时候,我们的SUBSCRIBER_INDEX这个集合就已经有我们的订阅信息了。所以,你知道为什么,叫ignoreGeneratedIndex了把。好,最后一步,我们就通过EventBus初始化,将这个类给传进去:

EventBus.builder().addIndex(new MyEventBusIndex()).installDefaultEventBus().register(this);

这样,它就会通过apt方式来处理我们的注解了,需要强调的是,我们是在编译过程中就已经找到我们的订阅信息了,不会在运行期做任何事情,所以这个效率是非常高的。好了,我们查找订阅的代码已经全部分析完了,这个部分是3.0最核心的代码,作者很精心的设计以提高EventBus的性能,我们看完之后也受益良多啊。好,继续分析,继续看findUsingInfo()方法,之前,我注释的也很清楚,但是还有个地方需要注意:

EventBus 3.0源码解析

我们添加订阅方法的时候还有个检查,我们分析下:

EventBus 3.0源码解析

这里,有两步检查,第一步检查,很好懂,第二步,根据什么签名来检查,我们看看:

EventBus 3.0源码解析

其实作者,这里又做了一个优化,将方法名和事件类型当作key,来保存方法,将传来的方法类型和我们签名的保存的比较,如果我们保存的是父类,就返回 true,如果是子类,就将传来的方法保存起来,返回 false。这样做的意图是,如果有父类的方法了,就没有必要添加子类的方法了,因为继承会执行到的。至此,我们对查找订阅方法的过程已经完全分析完了。看懂了之后,非常的过瘾。无论哪种方式查找,都返回了SubscriberMethod 对象,我们看看它维护了什么属性:

/**
 * Used internally by EventBus
 * and generated subscriber indexes.
 */
public class SubscriberMethod {
 final Method method;
 final ThreadMode threadMode;
 final Class<?> eventType;
 final int priority;
 final boolean sticky;
 /** Used for efficient comparison */
 String methodString;

订阅

EventBus 3.0源码解析

EventBus 3.0源码解析

订阅的代码比较长,但是理解起来并不难,而且,我也做了很详细的注释,其实里面就做了两件事,将我们的订阅方法和订阅者,封装到 subscriptionsByEventType和typesBySubscriber,至于这两个对象是干什么的呢?第一个是我们投递订阅事件的时候,就是根据我们的 EventType 找到我们的订阅事件,从而去分发事件,处理事件的;第二个是在调用 unregister(this) 的时候,根据订阅者找到我们的 EventType,又根据我们的 EventType 找到订阅事件,从而解绑用的,由于篇幅问题就不详细分析了。第二件事,就是如果是粘性事件的话,就立马投递、执行。

发布

EventBus 3.0源码解析

当我们调用 post(Object object) 的方法的时候就执行了上面的代码,PostingThreadState 是维护了投递的状态,最后循环投递,直到 PostingThreadState 中的 EventQueue 为空。那么代码最终执行到:

EventBus 3.0源码解析

那么,我们就会根据 ThreadMode 去处理事件了。也是由于篇幅的问题,就分析一种了,当线程模式是主线程的时候,意味着,我们需要执行的代码在主线程中操作。如果是主线程,就是通过反射,直接运行订阅的方法,如果不是主线程,我们需要 mainThreadPoster 将我们的订阅事件入队列,一起看看 mainThreadPoster 的工作原理:

EventBus 3.0源码解析

其实,在 EventBus初始化的时候,mainThreadPoster 就已经获取主线程的Looper了,就是用到了我们Android的消息处理机制:Looper,Handler。至于消息队列是自己维护的一个单向的链表。每次向Andorid的主线程Looper投递一个空消息,然后在 HandlerMessage() 方法里面从自己维护的队列中取出 PendingPost 进行处理。

final class PendingPost {
 private final static List<PendingPost> pendingPostPool = new ArrayList<PendingPost>();
 
 Object event;
 Subscription subscription;
 PendingPost next;

PendingPost 中维护的是订阅事件,EventType 和下一个 PendingPost 的地址。

反注册

EventBus 3.0源码解析

反注册就是通过,我们EventBustypesBySubscriber这个属性,通过订阅者去查找订阅事件,然后去一一解绑的。当然,反注册主要是为了提高效率的,不然订阅的事件太多,非常影响性能。

新特性-粘性事件

是否还记得,我们看订阅中的最后一段代码呢?不记得,也没事,回顾一下:

EventBus 3.0源码解析

我们来看看 checkPostStickyEventToSubscription

EventBus 3.0源码解析

看到没有,如果我们在注册的时候,指定我们要发布粘性事件,那么我们在订阅的时候,就立马调用 postToSubscription,去发布了,至于它从缓存中 stickyEvents 中获取订阅事件,你可能要问,我们什么时候把EventType放进去的呢?

public void postSticky(Object event) {
 synchronized (stickyEvents) {
 stickyEvents.put(event.getClass(), event);
 }
 // Should be posted after it is putted, 
 // in case the subscriber wants to remove immediately
 post(event);
}

没错,就是我们在调用 postSticky() 方法的时候,放入了缓存。当然,你也可以移除粘性事件:

EventBus 3.0源码解析

根据源码的分析,我们把上面的代码改成粘性事件。首先,在 NetWork 里面:

@Override
protected void onPostExecute(Integer integer) {
 if(integer == SUCCESS){
 EventBus.getDefault().postSticky(NetTask.this);
 }
}

然后,在MainActivity跳转到SecondActivity,让SecondActivity粘性注册:

EventBus 3.0源码解析

这样,我们只要一打开SecondActivityTextView上面就会显示Event Bus,下面是UI显示:

EventBus 3.0源码解析

思考

分析了好久的源码,我们收获很多,除了对框架的理解得到了升华,其次,我们也体会到了作者的设计思想,这在我们平常工作中都可以去尝试,体验 。最后,我们来思考下使用它的优点。首先和Android自带的组件广播相比,除了代码简洁之外,更多的是,我们能获取到更多的信息,众所周知,观察者有两种模式,一种被观察者推,一种是观察者自己拉取。

EventBus 3.0源码解析

我们可以在投递的过程把被观察着本身投递出去,然后从被观察者身(NetTask)上拉取数据。既然提到观察者模式,我们和jdk自带的观察者模式对比,相信很多人都在Android代码中使用jdk封装好的类吧,那么我就随便举个例子:

EventBus 3.0源码解析

我们写个任务的基类来继承Observable,当任务执行完了之后,通知观察者们去取,我们只要在Activity中实现Observer,实现方法update就可以完成数据的更新:

EventBus 3.0源码解析

这种实现方式虽然也能达到和 EventBus 相同的作用,但是和我们的 EventBus 相比,就更能突出我们 EventBus 最大的优势就是解耦和,将业务和视图分离。只要在BaseAcitity中注册,解绑。通过注解我们就能很随意的获取到任何回调的结果,更为任性的是我们想在哪个线程中运行就再哪个线程中运行,并且接收事件的先后顺序也可以自定义。代码写出来更加的优雅,灵活。

也许,你可能会说,性能相比呢?确实,我们的EventBus用用到了大量的缓存和反射,但是3.0后,已经做了很大改变了,我们可以通过apt预编译找到订阅着,避免了运行期间的反射处理解析。更为重要的是,牺牲一点内存达到代码的解耦,以后维护起来更加的方便,我觉得还是有所需要的。最后和Otto框架来比较,你就会知道EventBus框架是多么的优秀了!

EventBus 3.0源码解析

相关推荐