官方链接Github：https://github.com/greenrobot/EventBus

官方文档使用查询：http://greenrobot.org/eventbus/documentation/delivery-threads-threadmode/

一.引用EventBus的方式:

1.在项目中导入jar包（jar包在github首页中有下载链接）

2.使用引用库的方式比如在app gradle下的dependencies中引用：compile'org.greenrobot:eventbus:3.1.1'

二.开始使用EventBus

1.注册EventBus Tips:注意生命周期的方法先手顺序

(1)在Activity的onCreate()中注册:EventBus.getDefault().register(this);

(2)在Activity的onDestroy()中取消:EventBus.getDefault().unregister(this);

(3)在当前activity中定义一个方法 方法名在3.0之后可以随意定义

Tips:不定义方法，会报错。（原因不明）

注册eventbus的avtivity中定义方法

(4)定义传递消息的Bean类。上面onMessageEvent方法接收的参数MessageEvent这个类，就是我定义传递消息的Bean类

Bean类的定义

方法上方的注解：@Subscribe 作用是声明此方法是观察者用来接收event发送的消息

后面的 threadModo 定义此消息接收的线程域，后面我会对每个模式进行注释和记录。

三.Delivery Threads（threadMode）消息交付方式

ThreadMode: POSTING

订阅者将在发布事件的同一线程中被调用。这是默认值。事件传递是同步完成的，所有订阅服务器在发布完成后都会被调用。这threadmode意味着最少的开销，因为它避免了线程切换完全。因此，这是已知的简单任务的推荐模式，在不需要主线程的情况下完成很短的时间。使用此模式的事件处理程序应迅速返回，以避免阻塞发布线程，该线程可能是主要线程。例子:

ThreadMode.Posting

ThreadMode: Main

用户将被称为Android的主线程（有时称为UI线程）。如果在线程是主线程，事件处理程序方法将直接调用（同步像描述的threadmode。发帖）。使用此模式的事件处理程序必须迅速返回，以避免阻塞主线程。例子：

ThreadMode:Main

Tips:不要在这种模式下做耗时操作

ThreadMode: MAIN_ORDERED

用户将被称为Android的主线程。事件总是入队后交付给用户，所以调用后会立即返回。这使事件处理更严格和更一致的秩序（因而得名main_ordered）。例如，如果您以主线程模式在事件处理程序中发布另一个事件，则第二个事件处理程序将在第一个事件处理程序之前完成（因为它是同步调用的——将其与方法调用进行比较）。与main_ordered，第一事件处理程序将完成，然后第二个调用将在稍后的时间点（当主线程有能力）

Thread.Main_Ordered

Tisp:经过测试

A 跳转 B ，在A活动中接收消息的mode是MAIN_ORDERED，B活动消息事件的模式是MAIN。关闭B活动并且发送消息，返回A活动，这时候先触发B的消息事件，再触发A的消息事件。反之，则只会触发A的消息事件。B的消息事件不触发。我猜想这个时候B的观察者已经被注销，在这种情况下，就不会被触发。以上这种场景，在B是MAIN、POSTING模式的条件下，B活动关闭并发送消息，回到A活动后，会先触发A事件，再触发B事件，这两种模式下，B的观察者注销之前，都能触发消息事件。

ThreadMode: BACKGROUND

订阅者将在后台线程中被调用。如果发布线程不是主线程，则将在过帐线程中直接调用事件处理程序方法。如果在线程是主线程，eventbus使用一个单一的后台线程，将其所有的事件顺序。使用此模式的事件处理程序应尽量快速返回，以避免阻塞后台线程。例子:

ThreadMode.BackGround

Tips:使用这种消息模式，不要在子线程执行耗时操作，会阻塞主线程。

ThreadMode: ASYNC

事件处理程序方法在单独的线程中调用。这始终与发布线程和主线程无关。发布事件从不等待使用此模式的事件处理程序方法。事件处理程序方法应该使用这种模式，如果它们的执行可能需要一些时间，例如用于网络访问。避免同时触发大量长时间运行的异步处理程序方法，以限制并发线程的数量。eventbus使用线程池来有效地重用线程完成的异步事件处理程序的通知。

四.关于Subscribe中的属性使用

Subscribe中有3个属性：threadMode、priority、sticky

threadMode我们已经介绍过了。下面介绍priority（优先权）和sticky（粘性消息）

priority 消息的优先级定义

例子：

正常顺序

上面这个例子是在同一线程中，我同时写了三个接收消息事件。模式分别是MAIN、POSTING、MAIN_ORDERED

当我发送消息时，按顺序打印的结果是 MAIN、POSTING、MAIN_ORDERED（注意，不是按照代码顺序执行，是按照模式的级别出的打印结果），现在我给POSTING和MAIN中加上priority这个属性，来改变接收消息的先后顺序：

加上priority属性后

给MAIN的prority的属性值是1，给POSTING的priority的属性值是3，Main_ORDERED不加这个属性，此时的打印结果是：POSTING 、MAIN、MAIN_ORDERED。

经过测试，这个值给的越高，优先级越高。默认值是0

PS：优先级比较好的订阅者可以取消分发的事件，同时优先级比较低的订阅者将不会再收到此取消的事件 。例子：

拦截事件

代码：EventBus.getDefault().cancelEventDelivery(你的消息传递对象);

sticky（粘性消息）

sticky = true

使用方式：给需要接收粘性消息的方法事件的注解 加上这个属性 sticky = true

作用：在Android开发中，Sticky事件只指事件消费者在事件发布之后才注册的也能接收到该事件的特殊类型。Android中就有这样的实例，也就是Sticky Broadcast，即粘性广播。正常情况下如果发送者发送了某个广播，而接收者在这个广播发送后才注册自己的Receiver，这时接收者便 无法接收到刚才的广播，为此Android引入了StickyBroadcast，在广播发送结束后会保存刚刚发送的广播（Intent），这样当接收者注册完Receiver 后就可以接收到刚才已经发布的广播。这就使得我们可以预先处理一些事件，让有消费者时再把这些事件投递给消费者。

其他特性：参考链接：http://blog.csdn.net/IO_Field/article/details/52185717