EventBus笔记--基本使用

EventBus直译过来,叫做消息总线 , 可以简化应用程序内各组件间、组件与后台线程间的通信. 比如,Activity之间的通信 ,主线程与子线程的通信 ,Service于Activity的通信,Fragment与Fragment的通信, 都可以使用该开源库方便的处理. 使用该框架,你只需要考虑谁是订阅者, 谁是发布者就可以了.

EventBus -- 基本使用
EventBus源码 -- 注册
EventBus源码 -- 发送消息
EventBus源码 -- 注销

gradle依赖####

compile 'org.greenrobot:eventbus:3.0.0' 笔者在使用时为3.0版本
记住 是org开头, org org org, 不是de

基本概念####

EventBus的github中写到了使用方法, 但对于完全没有接触过的人来说, 理解起来还是有些困难的. 用一张图给大家描述一下.

自助火锅

自助火锅都吃过的哈, 厨房吧处理好的食材放到传送带上, 交钱入座的客户就可以在传送带上拿到食材
也许我们的GreenRobot也是受此启发.......
类比一下我们的EventBus, 总体来说的模式就是: 发送者把事件发送到总线中, 订阅者订阅了之后就可以收到消息了

1. 消息 (菜品)
2. 订阅者(顾客)
3. 发送者(厨房)

吃过火锅的朋友们到这里应该基本理解EventBus的使用方法了,接下来就是具体的代码编写. 这里先简略的写个demo举例子

步骤####

Demo
Activity与Fragment
需求描述: 在Activity中嵌入一个Fragment,点击Activity中的按钮,可以发送消息到Fragment中并展示出来

1. 准备消息: 就是一个实体类的写法

   
   

2. 在订阅者(Fragment)中,进行注册和注销, 相当于缴费就坐

   
   

3. 发送消息(把菜放到传送带中)

   
   

4. 在Fragment中接收消息,并使用(就做的客人拿到菜品)

   
   

按照以上的流程,你就学会了最基本的EventBus的用法,接下来上效果图

效果图

详谈 EventBus

会了最基本的使用之后,我们来正经的梳理一下

1. EventBus的三要素:

• Event 事件,可以为任意类型的对象
• Subscriber 事件订阅者, EventBus3.0之后，事件处理的方法可以随便取名，但是需要添加一个注解@Subscribe，并且要指定线程模型（默认为POSTING），四种线程模型下面会讲到。
• Publisher 事件发布者. 可以在任意线程任意位置发送事件，直接调用EventBus的post(Object)方法。可以自己实例化EventBus对象，但一般使用EventBus.getDefault()就好了，根据post函数参数的类型，会自动调用订阅相应类型事件的函数。

2. 线程模型, 也就是在注解中写的threadMode:

• POSTING: 如果使用事件处理函数指定了线程模型为POSTING，发布事件和接收事件在同一个线程进行。
  注意 : 在线程模型为POSTING的事件处理函数中尽量避免执行耗时操作，因为它会阻塞事件的传递，甚至有可能会引起ANR。
• MAIN 事件的处理会在UI线程中执行。
  注意 : 不要有耗时操作，会ANR。
• BACKGROUND 如果事件是在UI线程中发布出来的，那么该事件处理函数就会在新的线程中运行，如果事件本来就是子线程中发布出来的，那么该事件处理函数直接在发布事件的线程中执行。
  注意 : 在此事件处理函数中禁止进行UI更新操作。
• ASYNC 无论事件在哪个线程发布，该事件处理函数都会在新建的子线程中执行，同样，此事件处理函数中禁止进行UI更新操作。

3. 粘性事件
   普通的消息是发送就可以接收, 而粘性事件是先暂存在内存中, 要求在使用时再拿到数据. 其实套路也是大同小异的.

• 发送事件为发送粘性事件:
  EventBus.getDefault().postSticky(new EventBusStickyMessage("我是主页面发送过来的粘性事件"));
• 接收事件时使用注解为: 这里的sticky=true表示开启粘性事件
  @Subscribe(threadMode = ThreadMode.MAIN,sticky = true)
• 注销时候,同时要注销掉粘性事件:

注销粘性事件

那些坑

1. 在@Subscribe注解下的方法必须为public, 否则会报错.
2. 订阅者的接收参数必须为包装类
3. EventBus的注册是在订阅者(接收消息)中写的, 因为EventBus的注册必须与@Subscribe注解写在同一个类, 否则会报错.
4. EventBus在注册的时候,会将注册者的订阅事件信息保存在一个HashMap中 , 也就是说,可以多次注册. 在不及时销毁的情况下, 发布一个消息, 可能会引起消息传递混乱. 在这里给出以下建议:
   • 将EventBus的注销写在onPause中,注册写在OnResume中
   • 在每次注册注销的时候引入一个boolean变量记录是否注册, 避免重复注册. 记得在注销的时候重置变量.
5. 由于EventBus的耦合性太低 , 在多次使用时候 ,往往不知道哪里可以接收, 极大的降低了可读性 , 这里推荐一个插件 , 可以方便的标记EventBus的发布与接收:EventBus3 IntelliJ Plugin, 效果图如图所示:
   

点击按钮即可找到发布或者接收的代码片段.(个人感觉 , 同时加上注释吧最好)

具体的情况请参照实际需求使用