概述
- EventBus是Android和Java的发布/订阅事件总线。
- 简化了组件之间的通信；
- 将事件发送者和接收者分开；
- 与Activity，Fragment和后台线程之间调度非常好；
- 避免了复杂和容易出错的依赖和生命周期问题；
- 让你的代码变得更简单易懂；
常用的事件传递
- Intent 意图，跳转+传参；
- Handler ，通常用来在主线程更新UI，使用不当容易出现内存泄漏；
- Interface接口，仅限于统一在同一线程中数据交互；
- BoardCastReceiver ，有序+ 无序广播，不安全或者容易ANR；
- AIDL 跨进程通讯，代码阅读星不好，维护成本高；
- 其他方式，本地存储；
如何使用
EventBus 4 部曲（官方3步）：
1、引入依赖：
Grdle：
compile 'org.greenrobot:eventbus:3.1.1'
如果你的项目需要混淆记得加入：
-keepattributes *Annotation*
-keepclassmembers class ** {
@org.greenrobot.eventbus.Subscribe <methods>;
}
-keep enum org.greenrobot.eventbus.ThreadMode { *; }
# Only required if you use AsyncExecutor
-keepclassmembers class * extends org.greenrobot.eventbus.util.ThrowableFailureEvent {
<init>(java.lang.Throwable);
}
2、定义一个消息类，该类不继承任何基类也不要实现任何接口。如：
public class MessageEvent
{
public String message;
public MessageEvent(String message){
this.message = message;
}
}
3、定义事件回调方法，threadMode是可选：
@Subscribe(threadMode = ThreadMode.MAIN)
public void onMessageEvent(MessageEvent event) {/* Do something */};
4、在需要订阅事件的地方注册事件（必须要先注册，不然无法收到消息）：
EventBus.getDefault().register(this);
5、发送消息
EventBus .getDefault().post（new MessageEvent());
6、处理消息，即接受到MessageEvent消息做出反应：
@Subscribe(threadMode = ThreadMode.PostThread)
public void XXX(MessageEvent messageEvent) {
...
}
在3.0之前，EventBus还没有使用注解方式。消息处理的方法也只能限定于onEvent、onEventMainThread、onEventBackgroundThread和onEventAsync，分别代表四种线程模型。而在3.0之后，消息处理的方法可以随便取名，但是需要添加一个注解@Subscribe，并且要指定线程模型（默认为PostThread），四种线程模型，下面会讲到。
注意，事件处理函数的访问权限必须为public，否则会报异常。
7、取消消息事件的订阅：
EventBus.getDefault().unregister(this);
EventBus有何优点
采用消息发布/订阅的一个很大的优点就是代码的简洁性，并且能够有效地降低消息发布者和订阅者之间的耦合度；
举个例子，比如有两个界面，ActivityA和ActivityB，从ActivityA界面跳转到ActivityB界面后，ActivityB要给ActivityA发送一个消息，ActivityA收到消息后在界面上显示出来，我可以告诉你，这样也可以，就是代码过于臃肿；
常用API介绍
线程模型
在EventBus的事件处理函数中需要指定线程模型，即指定事件处理函数运行所在的想线程。在上面我们已经接触到了EventBus的四种线程模型。那他们有什么区别呢？
在EventBus中的观察者通常有四种线程模型，分别是PostThread（默认）、MainThread、BackgroundThread与Async。
PostThread：如果使用事件处理函数指定了线程模型为PostThread，那么该事件在哪个线程发布出来的，事件处理函数就会在这个线程中运行，也就是说发布事件和接收事件在同一个线程。在线程模型为PostThread的事件处理函数中尽量避免执行耗时操作，因为它会阻塞事件的传递，甚至有可能会引起ANR。
MainThread：如果使用事件处理函数指定了线程模型为MainThread，那么不论事件是在哪个线程中发布出来的，该事件处理函数都会在UI线程中执行。该方法可以用来更新UI，但是不能处理耗时操作。
BackgroundThread：如果使用事件处理函数指定了线程模型为
-
BackgroundThread，那么如果事件是在UI线程中发布出来的，那么该事件处理函数就会在新的线程中运行，如果事件本来就是子线程中发布出来的，那么该事件处理函数直接在发布事件的线程中执行。在此事件处理函数中禁止进行UI更新操作。
Async：如果使用事件处理函数指定了线程模型为Async，那么无论事件在哪个线程发布，该事件处理函数都会在新建的子线程中执行。同样，此事件处理函数中禁止进行UI更新操作。@Subscribe(threadMode = ThreadMode.PostThread) public void onMessageEventPostThread(MessageEvent messageEvent) { Log.e("FY", Thread.currentThread().getName()); } @Subscribe(threadMode = ThreadMode.MainThread) public void onMessageEventMainThread(MessageEvent messageEvent) { Log.e("FY", Thread.currentThread().getName()); } @Subscribe(threadMode = ThreadMode.BackgroundThread) public void onMessageEventBackgroundThread(MessageEvent messageEvent) { Log.e("FY", Thread.currentThread().getName()); } @Subscribe(threadMode = ThreadMode.Async) public void onMessageEventAsync(MessageEvent messageEvent) { Log.e("FY", Thread.currentThread().getName()); }
分别使用上面四个方法订阅同一事件，打印他们运行所在的线程。首先我们在UI线程中发布一条MessageEvent的消息，看下日志打印结果是什么。
打印结果如下：
postEvent﹕ main
PostThread﹕ main
Async﹕ pool-1-thread-1
MainThread﹕ main
BackgroundThread﹕ pool-1-thread-2
从日志打印结果可以看出，如果在UI线程中发布事件，则线程模型为PostThread的事件处理函数也执行在UI线程，与发布事件的线程一致。线程模型为Async的事件处理函数执行在名字叫做pool-1-thread-1的新的线程中。而MainThread的事件处理函数执行在UI线程，BackgroundThread的时间处理函数执行在名字叫做pool-1-thread-2的新的线程中。
再看看在子线程中发布一条MessageEvent的消息时，会有什么样的结果。
打印结果如下：
postEvent﹕ Thread-1
PostThread﹕ Thread-1
BackgroundThread﹕ Thread-1
Async﹕ pool-1-thread-1
MainThread﹕ main
从日志打印结果可以看出，如果在子线程中发布事件，则线程模型为PostThread的事件处理函数也执行在子线程，与发布事件的线程一致（都是Thread-1）。BackgroundThread事件模型也与发布事件在同一线程执行。Async则在一个名叫pool-1-thread-1的新线程中执行。MainThread还是在UI线程中执行。
黏性事件
除了上面讲的普通事件外，EventBus还支持发送黏性事件。卧槽，黏性事件？简单讲，就是在发送事件之后再订阅该事件也能收到该事件，一些事件在事件发布后携带有兴趣的信息。例如，一个事件表示一些初始化完成。或者如果您有一些传感器或位置数据，并且想要保留最新的值。而不是实现自己的缓存，你可以使用粘性事件。所以EventBus将最后一个特定类型的粘滞事件保存在内存中。然后粘性事件可以传递给订阅者或者显式查询。因此，您不需要任何特殊的逻辑来考虑已有的数据。跟黏性广播类似。具体用法如下：
订阅黏性事件：
EventBus.getDefault().register(StickyModeActivity.this);
黏性事件处理函数：
@Subscribe(sticky = true)
public void XXX(MessageEvent messageEvent) {
......
}
发送黏性事件：
EventBus.getDefault().postSticky(new MessageEvent("test"));
手动获取和删除粘性事件
MessageEvent stickyEvent = EventBus.getDefault().getStickyEvent(MessageEvent.class);
// Better check that an event was actually posted before
if(stickyEvent != null) {
// "Consume" the sticky event
EventBus.getDefault().removeStickyEvent(stickyEvent);
// Now do something with it
}
removeStickyEvent方法被重载：当你传入类时，它将返回以前持有的粘性事件。使用这个变体，我们可以改进前面的例子：
MessageEvent stickyEvent = EventBus.getDefault().removeStickyEvent(MessageEvent.class);
// Better check that an event was actually posted before
if(stickyEvent != null) {
// Now do something with it
}
处理消息事件以及取消订阅和上面方式相同。
建议看官方文档
开始造轮子
看过EventBus的源码应该知道，EventBus的实现使用了观察者模式。代码如下：
public void register(Object object) {
List<SubscriberMethod> subscribes = mCacheMap.get(object);
if (subscribes == null) {
synchronized (SimpleEventBus.class) {
subscribes = findSubscribeMethod(object);
mCacheMap.put(object, subscribes);
}
}
}
private List<SubscriberMethod> findSubscribeMethod(Object object) {
List<SubscriberMethod> subscriberMethods = new CopyOnWriteArrayList<>();
Class<?> clazz = object.getClass();
while (clazz != null) {
String name = clazz.getName();
//排除系统的类或接口，不能是系统的类或接口，因为我们的订阅方法只能是我们自己的类或接口
if (name.startsWith("java") || name.startsWith("javax") || name.startsWith("android")) {
break;
}
//该类定义的Method
Method[] methods = clazz.getDeclaredMethods();
for (Method method : methods) {
Annotation annotation = method.getAnnotation(Subscribe.class);
if (annotation == null) continue;
Class<?>[] parameterTypes = method.getParameterTypes();
if (parameterTypes.length != 1) throw new RuntimeException("只能有一个参数");
Class<?> methodParameterType = parameterTypes[0];
ThreadMode threadMode = ((Subscribe) annotation).threadMode();
subscriberMethods.add(new SubscriberMethod(method, threadMode, methodParameterType));
}
clazz = clazz.getSuperclass();
}
if (subscriberMethods.size() <= 0) {
throw new RuntimeException("必须有一个订阅方法");
}
return subscriberMethods;
}
看到当EventBus开始register的时候，通过解析Class中被标注@Sunscriber注解的方法Method，拿到注解标识的接收事件的方法，然后解析注解并将解析到的Method和Method Param type以及ThreadMode保存到内存中，在来看看那post方法，代码如下：
/**
* 实际上是根据订阅方法的参数和发布传进来的对象进行对比
*
* @param eventMessage
*/
public void post(Object eventMessage) {
Set<Object> objects = mCacheMap.keySet();
for (Object obj : objects) {
List<SubscriberMethod> subscriberMethods = mCacheMap.get(obj);
if (subscriberMethods == null) continue;
for (SubscriberMethod subMethod : subscriberMethods) {
Class<?> aClass = subMethod.getEventType();
Class<?> bClass = eventMessage.getClass();
//aClass 的class是是不是bClass的的父类或者接口
if (aClass.isAssignableFrom(bClass)) {
invoke(subMethod, obj, eventMessage);
}
}
}
}
private void invoke(SubscriberMethod subscriberMethod, Object obj, final Object eventObj) {
EventTask eventTask = new EventTask(subscriberMethod.getMethod(), obj, eventObj, subscriberMethod.getThreadMode());
ScheduleRouterExecutor.getInstance().executeTask(eventTask);
}
当post的时候，通过post传入的参数类型与第2步解析的得到的方法参数类型进行对比，回调的对应的方法，整个过程就结束了。
总结：
1、因为EventBus 3.0之前，在运行时大量存在了反射，势必会造成不必要的性能问题，目前官方做了优化，使用了编译时注解，也就是index,如何使用Eventbus注解。
2、EventBus并不支持跨进程通讯，我们是否可以对他进程拓展？那么这样会不会和第1的问题冲突呢？
从上面知道EventBus是不支持跨进程通讯和大量反射有性能损耗，后期将尝试解决这些问题demo地址
