Android组件间通信机解耦——Android EventBus和Otto框架一、前言 传统的事件传递方式包括：Handler、BroadCastReceiver、Interface 回调，相比之

一、前言

传统的事件传递方式包括：Handler、BroadCastReceiver、Interface 回调，相比之下 EventBus 的优点是代码简洁，使用简单，并将事件发布和订阅充分解耦。

EventBus 是一个 Android 事件发布/订阅框架，通过解耦发布者和订阅者简化 Android 事件传递，这里的事件可以理解为消息或者数据，本文中统一称为事件。事件传递既可用于 Android 四大组件间通讯，也可以用户异步线程和主线程间通讯等等。

简单来说，就是使用事件发布/订阅框架，让我们不用在需要数据回调的地方考虑如何回传数据，只需要将数据发布，然后就不用管了。Bus会帮我们把数据发给相关的订阅者。

基本过程：

1、订阅者先向Bus注册自己（不在需要的时候反注册自己）

2、发布者在需要发布消息的时候通过Bus发布消息，然后就不管了

3、Bus扫描所有注册的订阅者，并通过一定的匹配规则（例如方法的参数），将消息发布给符合规则的订阅者

这样一来，发布者在需要发布消息的时候直接发布消息，其他不用管，而订阅者则可以在任意位置收到Bus发过来的消息，发布者与订阅者实现了解耦！

例如，下载一张图片并显示到ImageView上，一般做法，可开启后台线程下载图片，并设置一个监听器，后台线程下载完成后通过监听器通知主线程显示下载完成的图片。

如果使用EventBus，可以写一个方法，这个方法接受一张图片，并把图片显示到ImageView，其他不管。而后台线程下载完成后直接通过Bus发布图片，然后也不管。前面的方法自然会受到Bus传送过来的数据，以后修改这个方法或者后台线程，都不会互相干扰，实现了解耦！

二、Android EventBus

1、Android EventBus 是通过方法的参数来匹配的，所有形参与提交数据时候的参数一致的方法，都会接到Bus传递过来的数据

2、方法必须以onEvent开头

3、可以使用类封装参数，以达到更灵活得匹配方法参数的目的

4、EventBus包含4个ThreadMode：PostThread，MainThread，BackgroundThread，Async

具体的用法，极其简单，方法名开头为：onEventPostThread， onEventMainThread，onEventBackgroundThread，onEventAsync即可

具体什么区别呢？

onEventMainThread代表这个方法会在UI线程执行

onEventPostThread代表这个方法会在当前发布事件的线程执行

BackgroundThread这个方法，如果在非UI线程发布的事件，则直接执行，和发布在同一个线程中。如果在UI线程发布的事件，则加入后台任务队列，使用线程池一个接一个调用。

Async 加入后台任务队列，使用线程池调用，注意没有BackgroundThread中的一个接一个。

5、Sticky Event

有时候某个事件可能会用到多次，比如在前面介绍Event Bus模型一文的示例中，最新的位置更新信息，可能需要多次用到，真对这种情况，您可以把该事件发布为Sticky Event，然后，当需要查询该信息的时候，可以通过Bus的getStickyEvent(ClasseventType) 函数来查询最新发布的Event对象。

同一类型的事件只保存最新的Event对象。

注册和发布事件的函数分别为 registerSticky(…) 和 postSticky(Object event)。

三、Otto

1、otto通过注解Produce、Subscribe来标明生产消息的方法和接受消息的方法

2、没有想Android EventBus那样有多种事件响应的线程模式

3、不支持Sticky Event

4、因为使用了注解，Otto在处理大量事件的时候，性能会比Android EventBus稍差

转自：http://m.blog.csdn.net/blog/Estellise/41758401