EventBus框架的作用是什么(eventbus,移动开发)

EventBus的作用

Android中存在各种通信场景，如Activity之间的跳转，Activity与Fragment以及其他组件之间的交互，以及在某个耗时操作（如请求网络）之后的callback回调等，互相之之间往往需要持有对方的引用，每个场景的写法也有差异，导致耦合性较高且不便维护。

以Activity和Fragment的通信为例，官方做法是实现一个接口，然后持有对方的引用，再强行转成接口类型，导致耦合度偏高。

再以Activity的返回为例，一方需要设置setResult，而另一方需要在onActivityResult做对应处理，如果有多个返回路径，代码就会十分臃肿。而SimpleEventBus（本文最终实现的简化版事件总线）的写法如下：

来源Activity：

效果如下：

image

似乎只是换了一种写法，但在场景愈加复杂后，EventBus能够体现出更好的解耦能力

背景知识

主要涉及三方面的知识：

观察者模式(or 发布-订阅模式)

Android消息机制

Java并发编程

实现过程
EventBus`的使用分三个步骤：注册监听、发送事件和取消监听，相应本文也将分这三步来实现。

注册监听

定义一个注解：

greenrobot/EventBus还支持优先级和粘性事件，这里只支持最基本的能力：区分线程，因为如更新UI的操作必须放在主线程。ThreadMode`如下：

在对象初始化的时候，使用register方法注册，该方法会解析被注册对象的所有方法，并解析声明了注解的方法（即观察者），核心代码如下：

执行过这些逻辑后，该对象所有的观察者方法都会被存在一个Map中，其Key是EventType，即观察事件的类型，Value是订阅了该类型事件的所有方法（即观察者）的一个列表，每个方法和对象一起封装成了一个Subscription类：

如此，便是注册监听方法的核心逻辑了。

消息发送

消息的发送代码很简单：

比较复杂一点的是需要根据注解声明的线程模式在对应的线程进行发布：

三种线程模式分别如下，DefaultEventHandler（在发布线程执行观察者放方法）：

MainEventHandler（在主线程执行）：

AsyncEventHandler（新开一个线程执行）：

以上便是发布消息的代码。

注销监听

最后一个对象被销毁还要注销监听，否则容易导致内存泄露，目前SimpleEventBus用的是WeakReference，能够通过GC自动回收，但不知道greenrobot/EventBus为什么没这样实现，待研究。注销监听其实就是遍历Map，拿掉该对象的订阅即可：

局限性

由于时间关系，目前只研究了EventBus的核心部分，还有几个值得深入研究的点，在此记录一下，也欢迎路过的大牛指点一二。

性能问题

实际使用时，注解和反射会导致性能问题，但EventBus3已经通过Subscriber Index基本解决了这一问题，实现也非常有意思，是通过注解处理器（Annotation Processor）把耗时的逻辑从运行期提前到了编译期，通过编译期生成的索引来给运行期提速，这也是这个名字的由来

可用性问题

如果订阅者很多会不会影响体验，毕竟原始的方法是点对点的消息传递，不会有这种问题，如果部分订阅者尚未初始化怎么办。等等。目前EventBus3提供了优先级和粘性事件的属性来进一步满足开发需求。但是否彻底解决问题了还有待验证。