EventBus原理解析笔记以及案例实战（结合demo）
笔记概述
-
EventBus简介
-
EventBus方法介绍
-
EventBus实际运用
EventBus简介
-
开源项目地址：https://github.com/greenrobot/EventBus
-
EventBus主页：http://greenrobot.org/eventBus/
-
github项目地址中关于EventBus的简介：
Event bus for Android and Java that simplifies communication between Activities, Fragments, Threads, Services, etc. Less code, better quality.
即，
Event 简化了活动、碎片、进程、服务等之间的通讯方式；
使APP项目用更少的代码量实现更好的质量；
关于EventBus的优势
- 简化组件间的通讯方式
- 解耦合事件发送者和接收者
- 使活动、碎片和后台的线程实现更高的执行效率
- 防止复杂的有错误（倾向）的依赖以及生命周期的问题
- 让你的代码简洁
- 运行快
- 库小
- EventBus主页简洁：
EventBus is an open-source library for Android and Java using the publisher/subscriber pattern for loose coupling. EventBus enables central communication to decoupled classes with just a few lines of code – simplifying the code, removing dependencies, and speeding up app development.
即，
EventBus是一个开源库，
使用发布/订阅机制来对代码进行解耦。
简化项目的集中通讯（仅仅通过几行代码就可以解耦各个类），
移除了一些不必要的依赖，加速移动应用的开发。
关于大项目，如果还是用Java/Android原生的调用，
两个Activity之间的通讯，
还用startActivity()/startActivityForResult()这类通信方式的话，
代码会非常的冗余，
例如Activity和Fragment之间的通讯就需要不断地调用相关的函数；
使用EventBus可以解除这些耦合；
否则如果代码耦合性非常大的话，
会大大增加后期维护的难度！
EventBus架构
-
Publisher
调用post()方法，
把Event发送到EventBus； -
EventBus（类似于快递中心）
分发Publisher发布的Event
给对应的Subscriber（订阅者）； -
Subscriber接收Event；
EventBus概述
-
EventBus是一个Android端优化的
publish/subscribe消息总线； -
简化了应用程序内各组件间、组件与后台线程间的通讯；
-
举例一个EventBus可简化代码的场景：
请求网络时候，等网络返回时通过Handler或Broadcast通知UI；
两个Fragment之间需要通过Listener通讯；
以上都可以用EventBus来代替； -
EventBus作为一个消息总线，有三个主要的元素：
-
Event：事件
Event可以是任意对象，
用来描述传递的数据或事件类型；
一般Event是由开发者按照需求自己定义的，
里面封装要传递的事件类型和数据； -
Subscriber：事件订阅者，接收待定的事件
在Event中，使用约定来制定事件订阅者以简化使用；
在3.0之前，EventBus还没使用注解的方式，消息处理的方法也仅限于：onEvent、onEventMainThread、onEventBackgroundThread、onEventSync，
分别代表四种线程模型；
在3.0之后，消息处理的方法可以随便取名，
但是需要
添加一个注解@Subscribe，
并且要指定线程的模型； -
Publisher：事件发布者，用于通知
Subscriber有事件发生
可以在任意线程、任意位置发送事件，
直接调用EventBus的post(Object)方法即可； -
调用
EventBus.getDefault()方法，实例化EventBus对象
-
EventBus线程模型
ThreadMode
ThreadMode指定了会调用的函数，
只能有以下四种（因为每个订阅事件都是和一个线程模型相关的）：PostThread、 BackgroundThread、 MainThread、 Async
PostThread： 在相同的进程中做EventBus通信
-
事件的处理和事件的发送在相同的进程，
所以事件的处理时间不应太长，
不然会影响事件的发送线程；
而这个线程可能是UI线程； -
对应的函数名是
onEvent，
一般在UI线程使用，
如果堵塞时间较长则会影响其他线程的刷新，
引起界面的卡顿；
打个比方说你在UI线程中卡了两秒等下UI就不动，不刷新了
相关地举一个案例
- 这里有两个Activity：
按下Activity1中的Button，
会跳转到Activity2；
按下Activity2中的button，
会通过EventBus去通知Activity1；
Activity1会通过OnEvent接收，
如果接收到Activity2发送过来消息，
然后触发Toast；
接下来新建一个项目，根据官方GitHub添加依赖，
implementation 'org.greenrobot:eventbus:3.1.1'
下面是主布局（Activity1）:
- 然后根据需求定义Event（类似于Module类），
这里没什么特别需求，
定义一个简单的Event就可以了：
public class MyEvent {
public String msg;
public MyEvent() {}
public MyEvent(String msg) {
this.msg = msg;
}
}
- 接下来，
要在我们这个“Activity1”里面注册 OnEvent ，
这个OnEvent 是在跟 发送事件的线程 同一个线程里面 接收事件的，
我们这里虽然是分开两个Activity，
但是Activity本身就都是在主线程里面的；
所以这里 事件的发送(在Activity2)， 事件的接收(在Activity1)
都在同一个线程中；
即，以上所说的PostThread线程类型中，
事件的发送 跟 事件的接收 是在同一个线程里面的;
下面注册一个onEvent()，
如果接收到Activity2发送过来消息，触发Toast；
/**
* 注册onEvent(),
* 注意写上注解！
*/
@Subscribe
public void onEvent(MyEvent event) {
popOutToast("接收到Event：" + event.msg);
}
/**
* 封装弹出短时Toast提示
* @param text 企图弹出的文本内容
*
*/
private void popOutToast(String text) {
Toast.makeText(MainActivity.this,text,Toast.LENGTH_SHORT).show();
}
- 使用EventBus的接收方法的活动，需要在onCreate中注册
EventBus.getDefault().register(this);
- 反注册
@Override
protected void onDestroy() {
super.onDestroy();
EventBus.getDefault().unregister(this);
}
- 整个Activity1的java代码：
public class MainActivity extends AppCompatActivity {
private Button mButton;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
//使用EventBus的接收方法的活动，需要注册
EventBus.getDefault().register(this);
mButton = findViewById(R.id.bt_toAc2);
mButton.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Intent intent = new Intent(MainActivity.this, SecondActivity.class);
startActivity(intent);
}
});
}
/**
* 注册onEvent(),
* 注意写上注解！
*/
@Subscribe
public void onEvent(MyEvent event) {
popOutToast("接收到Event：" + event.msg);
}
@Override
protected void onDestroy() {
super.onDestroy();
EventBus.getDefault().unregister(this);
}
/**
* 封装弹出短时Toast提示
* @param text 企图弹出的文本内容
*
*/
private void popOutToast(String text) {
Toast.makeText(MainActivity.this,text,Toast.LENGTH_SHORT).show();
}
}
创建第二个活动SecondActivity，布局：
java：
public class SecondActivity extends AppCompatActivity {
private Button mButton;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_second);
mButton = findViewById(R.id.bt_sendMsg);
mButton.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
EventBus.getDefault().post(new MyEvent("洞妖洞妖我是栋二！！！"));
}
});
}
}
运行效果图：
Activity1：
跳到Activity2，点击按钮，弹出Toast：
补充
- 以上这种场景，
如果不用EventBus，
我们可能需要用到Handler + Runnable的方式，
但是如果有十个Activity向Activity1发消息，
我们就需要写十个Handler了，
这样子相当繁琐；
而使用EventBus，
这里只要稍微用代码注册一下就可以了，
明显方便很多，
一个方post、一个onEvent，也很轻松地解耦了；
- 另外一个需要注意的地方就是，
EventBus.getDefault().register(this);系列的注册与反注册代码，
同onEvent()系列的接收函数是紧密绑定的；
用时缺一不可，不用时存一不可，同生同灭；
也就是说一个活动注册onEvent()系列的接收函数了，
则必须用EventBus.getDefault().register(this);去注册，
不然会报错；
而一个活动它没有写onEvent()系列的接收函数，
却用EventBus.getDefault().register(this);去注册了，
同样也会报错！
- onEvent()处理时间比较长，会导致线程堵塞；
如以下再onEvent()中挂起线程3秒，模拟3秒处理时间：
@Subscribe
public void onEvent(MyEvent event) {
//消耗时间模拟
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
popOutToast("接收到Event：" + event.msg);
}
接着运行项目的话，
会发现我们在Activity2中点击发送消息的按钮之后，
要等到3秒钟，主线程才会刷新UI（弹出Toast），
这样子在实际运用中用户体验很差；
MainThread
- 其机制同onEvent()其实是差不多的，
即发送和接收都是在同一个线程主线程/UI线程中进行；
使用：基于PostThread的代码，
加多一行(threadMode = ThreadMode.MAIN)即可：
//MainThread
@Subscribe(threadMode = ThreadMode.MAIN)
public void onEvent(MyEvent event) {
//消耗时间模拟
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
popOutToast("接收到Event：" + event.msg);
}
BackgroundThread
-
事件的处理会在一个
后台线程中执行，
对应的函数名是onEventBackgroundThread； -
虽然名字是BackgroundThread，
事件的处理是在后台线程，
但事件的处理时间还是不宜太长； -
如果发送事件的线程是在后台线程，
会直接执行事件； -
如果当前线程是UI线程，
事件会被加到一个队列中，
由一个线程依次处理这些事件，
如果某个事件处理时间太长，
会阻塞队列中 排在后面的事件的派发或处理；
图解
对于PostThread和MainThread
一次执行
-
当只有一个线程的时候，
post（发送）和onEvent()是在同一个线程中去跑的，
一个线程里面的话，
宏观上来说，其代码便是一次执行的：
对于BackgroundThread
一一对应
- 这里有两个线程，UI主线程和后台线程，
这个后台线程专门用来
处理onEventBackgroundThread方法及其对应的事件的；
也就是说，
比如现在主线程里面有一个post，
它会对应执行到后台的一个onEventBackgroundThread()；
顺序执行，前者执行，后者等待阻塞
-
一个前台线程的post
会对应执行到一个后台线程的onEventBackgroundThread()；
来了第二个post，
就对应第二个onEventBackgroundThread()； -
后台线程中的
onEventBackgroundThread()；
是按照post的顺序依次执行的；
如果前面一个post对应的onEventBackgroundThread()；没有执行完，
这时候又post了一下，
那么对应的后面的这个onEventBackgroundThread()会等待前面一个onEventBackgroundThread()执行完，它才执行；
- 来个例子，修改MainActivity代码：
//BackgroundThread
@Subscribe(threadMode = ThreadMode.BACKGROUND)
public void onEvent(MyEvent event) {
Log.d(TAG, "onEvent Start!!!!!!!! ");
//消耗时间模拟
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.d(TAG, "onEvent End!!!!!!!! ");
// popOutToast("接收到Event：" + event.msg);
}
-
接着运行代码，
老规矩，Activity1跳转到Activity2，
点击“发送信息”按钮，
连续点击两次（根据以上SecondActivity中写的按钮点击事件，
这里可以理解成连续post两次，一前一后），
观察logcat：
-
我们可以观察到两对Start和End是顺序执行的；
-
执行时候没有交叉，先第一对，后第二对；
这里也便验证了以上理论——
即，
一一对应，一个post对应一个event，
event顺序执行，
前post者对应的event执行中，
则后post者对应的event等待阻塞； -
其实把代码改成
MainThread的，
再运行，连续点击三次，
同样是能体现一一对应，顺序执行，前者执行，后者等待阻塞的特性：
@Subscribe(threadMode = ThreadMode.MAIN)
public void onEvent(MyEvent event) {
Log.d(TAG, "onEvent Start!!!!!!!! ");
//消耗时间模拟
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.d(TAG, "onEvent End!!!!!!!! ");
// popOutToast("接收到Event：" + event.msg);
}
- 但区别在于，
Main是执行在主线程，
而Background是执行在后台线程，
而且我们前面说过，
在主线程中执行占用资源多、占用时间长的任务是不合适的，
既不规范，也影响体验；
PostThread/MainThread缺点：
执行在主线程，
事件的个数，事件的耗时，
都需要做比较严格的限制；
BackgroundThread缺点：
运行在后台线程，不占用主线程资源，
比PostThread/MainThread好那么一点，
但是还是没有解决——
多个（>= 2个）事件时，
一次处理一个，依次处理，
前者执行，后者等待阻塞的问题，
不适合事件中有耗时较长的任务；
Async adj.异步的；
sync n.同时，同步；
- 事件处理会在单独的线程中执行，
主要用于在后台线程中执行耗时操作，
每个事件会开启一个线程
（程序初始化时，已经帮我们创建好一个线程池，每次POST一下框架都会去取一个线程来执行），
但最好限制线程的数目
（线程过多，CPU使用大，设备耗电快）；每次POST一下框架都会去取一个线程来执行，
线程池中线程之间互相不干扰，可以同时运行；
更改代码：
//AsyncThread
@Subscribe(threadMode = ThreadMode.ASYNC)
public void onEvent(MyEvent event) {
Log.d(TAG, "onEvent Start!!!!!!!! ");
//消耗时间模拟
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.d(TAG, "onEvent End!!!!!!!! ");
}
执行效果：
这次我们可以看到，
事件的处理就没有——
一次处理一个，依次处理，前者执行中，后者等待阻塞的特性了，
因为各个post的事件，
都有各自独立的线程去处理，
所以事件的处理运行是同时的、异步的；
小结
- PostThread：发送和接收在同一个线程；
- MainThread：发送和接收同在主线程；
（应用范围上被PostThread包括） - BackgroundThread
PostThread/MainThread缺点：
一般执行在主线程，
事件的个数，事件的耗时，
都需要做比较严格的限制；
BackgroundThread缺点：
运行在后台线程，不占用主线程资源，
比PostThread/MainThread好那么一点，
但是还是没有解决——
多个（>= 2个）事件时，
一次处理一个，依次处理，
前者执行，后者等待阻塞的问题，
不适合事件中有耗时较长的任务；
以上三种线程都是不适合跑耗时操作的；
Async
adj.异步的；
核心：异步，同时，高效；
- 事件处理会在单独的线程中执行，
主要用于在后台线程中执行耗时操作，
每个事件会开启一个线程
（程序初始化时，已经帮我们创建好一个线程池，每次POST一下框架都会去取一个线程来执行），
但最好限制线程的数目
（线程过多，CPU使用大，设备耗电快）；每次POST一下框架都会去取一个线程来执行，
线程池中线程之间互相不干扰，可以同时运行
补充：
-
优先级（
priority）就是字面上的意义，
值越高，优先级越高； -
sticy即粘性发送，发送方法即EventBus.getDefault().postSticky(new MyEvent());注销粘性event的方法EventBus.getDefault().removeStickyEvent(new MyEvent());
发送（postSticky）的时候，
项目中有多少Fragment、Activity等载体，
事件MyEvent就发送多少份；粘性其意义在于，
无论项目中载体类中
是否使用EventBus.getDefault().register(this);对EventBus注册过，
都会对其发送事件，若载体注册了，则接收处理该粘性事件；若载体未注册，则该粘性事件会缓存起来，一旦载体注册，马上接收处理事件；
但由于这种粘性发送在项目比较大的时候
需要占用一定量的缓存资源，
所以一般使用较少；
- 另外一个需要注意的地方就是，
EventBus.getDefault().register(this);系列的注册与反注册代码，
同onEvent()系列的接收函数是紧密绑定的；
用时缺一不可，不用时存一不可，同生同灭；
也就是说一个活动注册onEvent()系列的接收函数了，
则必须用EventBus.getDefault().register(this);去注册，
不然会报错；
而一个活动它没有写onEvent()系列的接收函数，
却用EventBus.getDefault().register(this);去注册了，
同样也会报错！
使用技巧
-
事件只需要传递一个
状态/指令，无需传递数据时，
event自定义类内容可以为空；
比如一个只需要传递“清空位置信息列表”这个指令的事件，
可以这么定义：
就是定义一个Event类，但是内容为空；
即
无需传递数据，
仅仅event类的类名已经具备传递的事件、指令意义； -
一个
Fragment或者Activity需要接收处理多个Event时候，
通过建立多个注解方法，并以不同的event 形参，
来区分处理，接收到不同的event时，该做的对应的逻辑；
参考资料：慕课网