RxBus 是什么？
这里有一连串的概念 - -！
RxBus是RxJava的自定义实现；
RxJava？它是ReactiveX在java上的实现。
ReactiveX？专注于异步编程和控制可观察数据和事件流的API，它组合了观察者模式，迭代器模式，函数式编程的优秀思想）
所以说，RxBus：是java上用于 异步编程，控制可观察数据和事件流的API。
在android架构上，RxBus用来 实现 组件之间的无差别信息互通。
组件？
四大组件。Activity,Service,ContentProvider,BroadcastReceiver,讲道理，除了Activity的3个组件，都用的很少，因为业务场景并没涉及。
以及小概念上的组件，比如自定义的View，ViewGroup，Fragment；
无差别？
所谓无差别，就是所有组件在信息互通上都是平等地位，任何一个组件都可以发送消息，和接收消息。并且这种方式并没有对android原有的信息传递方式（Intent+Bundle）造成影响，原有的依然可以用。
依赖的库：
目前，RxJava有2个大版本，1.X和2.X ；两者的区别，1.X的 核心类 是Observable，2.X则换成了Flowable，API和调用方式有所改变，功能也有所不同。
Github上有版本迭代的记录，到github上，搜索RxJava，第一个就是。
最新版本目前是2.2.2.
===========================
RxBus使用方法:
假如你已经有了一个RxBus.java（事件总线类,或者消息总线类）
那么它的业务模型，应该是：
组件A和B要互通消息，A 要发消息给B，那么，B要收到消息，必须 在事件总线上“订阅”，成为订阅者。A调用RxBus的API，由事件总线发出消息，然后 让订阅者收到, B收到消息之后自行处理。
网上搜罗了一些RxBus使用上的一些梗：
1-Sticky 粘性。
和粘性对应的是 “非粘性”：即， B要想收到消息，“必须”在A发出消息之前，到事件总线去“订阅”，然后A发消息，B收到之后处理。 那么粘性： B"无须"在A发出消息之前订阅，即使消息已发出，你才去订阅，也能收到。
在最新版本的RxJava的第三方API中，貌似提供了4种粘性消息的实现类，可自行度娘；各种API。
2-消息类别区分:
上面的案例只是说，A发送消息给B，但是如果同时有B1,B2,B3,B4....B100呢？这么多组件，那如果我需要对消息进行区分，明确我要把消息发给谁，应该怎么做。可是，RxJava上我没发现直接解决这种问题的API···所以，自己解决吧。
具体方法：
A调用RxBus的接口，接口参数是一个Object对象，本来这个对象是直接发给B的，那么现在如果把这个对象封装一下，把原本的对象变成一个成员变量，再增加一个String code，作为消息类别的标识符。
B在 订阅消息的时候，也要对消息进行过滤，只接收对应code的消息。(这里过滤消息,用的是第三方库的API。。filter,好吧，这个库还有很大进步空间啊)
3-反压力 Backpressure:
反压力这个概念 来源于 生产者消费者的模型：当生产者的生产效率高于消费者的消费效率，消费者无法及时处理，就会造成产品积压。
同样，在消息总线中，如果积压了太多消息，一窝蜂发给 订阅者，如果订阅者来不及处理，可能就会造成预期之外的效果，长期如此就会耗费内存。
针对这种问题。。。
查了资料，有一篇好文（ https://www.jianshu.com/p/2c4799fa91a4 ），明确定义：背压是指在异步场景中，被观察者发送事件速度远快于观察者的处理速度的情况下，一种告诉上游的被观察者降低发送速度的策略；背压是流速控制的一种策略;
策略细节
1) 响应式拉取。原本：观察者是被动接收事件，被观察者是主动发送数据。那么现在变成：观察者主动拉取数据，被观察者得知观察者需要数据之后，再发送数据，由观察者掌握主动权。
2) 热 被观察者，冷被观察者（Hot/cold observables）;
`````
背压这个东西，暂时用不到，而且牵涉的其他知识太多了，遇到了再说吧.
总结就到这里。我要查别的东西了·····
Demo
总结了一个Demo放在了github上，实现了 消息总线的基本功能，并且 对消息进行了区分对待；三块不同的颜色区域是 3个独立的Fragment组件;
说明-
1- 业务1的消息发送
2- 业务2的消息发送
3- 订阅业务1的消息
4- 取消业务1的消息订阅
5- 订阅业务2的消息
6- 取消业务2的消息订阅
7- 显示业务1的消息内容
8- 显示业务2的消息内容
这是动态图;
最后奉上我自己的 Demo-Github地址：https://github.com/18598925736/RxBusStudy2