本文参考EventBus官网，有兴趣的朋友可以直接上官网阅读：http://greenrobot.org/eventbus/documentation/
在开始使用EventBus3.0之前，必须先引入EventBus3.0（ps：那是当然了。。。），方法如下：
Gradle
Maven
第一步：定义事件
事件是没有具体返回值的POJO（普通的Java类）。
（PS：据我所知事件类是可以继承的，并且对于事件内的属性也是可以被继承的，这样的好处就是开发人员可以通过继承更好的组织一类事件，注意在继承时，发布子类的事件父类订阅者能够接收到消息，而发布父类的事件子类的订阅者不能接收到事件）
第二步：准备订阅者
订阅者需要实现事件处理方法（或者叫做“订阅者方法”），这个方法会在一个事件被发布之后调用。事件处理方法需要通过 注解定义。注意： EventBus3.0的事件处理方法的名称可以自由选择（没有像EventBus2那种命名约束）
订阅者必须在总线(EventBus)上注册和反注册它自己。因为只有订阅者注册之后才会收到事件消息。在Android系统上，在Activites和Fragments组件中通常使用它们的生命周期方法来注册订阅者。并且在大多数情况下onStart/onStop两个方法会更好。
第三步：发布事件
可以在代码中的任何地方发布一个事件。所有符合事件类型并且当前已经注册的订阅者都会接收到事件。
通过以上的代码，发布事件后，所有的通过 注解声明的订阅者如果符合事件 就会接收到消息。
ThreadMode: POSTING
这种线程模式的订阅者会在与发布者相同的线程中被调用。注意：这种模式是默认的。 也就是说在不设置线程模式的情况下，订阅者被调用的线程和发布者的线程是一个线程。 一旦事件发送完成，事件同步就会完成并且所有的订阅者都会被调用（订阅当前事件的订阅者）。因为这种线程模式完全避免了线程转换，所以它是性能开销最小的线程模式。因此这种模式被推荐用于执行事件短并且不需要调用main线程的简单任务。使用这种线程模式来处理事件应该快速返回避免阻碍发布线程（因为发布线程和订阅者事件处理逻辑在一个线程，如果处理事件过长，发布线程会阻塞，尤其避免在UI线程发布事件后订阅者长时间不返回结果，会造成ANR）。
ThreadMode: MAIN
这种模式下订阅者会在main线程被调用（一般情况下指的是UI线程）。如果发布线程是main线程，那么事件处理方法会被直接调用（就像使用ThreadMode.POSTING描述一样）。事件处理者如果使用这种模式必须快速返回以免阻塞UI线程。
ThreadMode: BACKGROUND
订阅者会在后台线程被调用。如果发布线程不是main线程，事件处理方法会直接在发布线程中调用。如果发布线程不是main线程，EventBus会使用一个单一线程按照顺序发送所有的事件。事件处理者如果使用这种模式应该尽量快速返回，避免阻塞后台线程（PS：因为后台线程只有一个，并且是顺序执行的，耗时的事件处理，会造成队列积压）。
ThreadMode: ASYNC
这种模式下事件处理者会在一个独立线程中被调用。这个线程独立于main线程和发布线程。使用这种模式，发布事件不用等待事件处理者。如果事件处理方法执行需要一些事件，例如网络接入。应该使用这种模式。避免触发大量长时间运行的异步处理方法同时也要限制同一时间的线程数量。EventBus使用了一个线程池用来把已经处完成的异步处理消息线程有效的重新利用。
EventBusBuilder类可以配置EventBus的多个方面。例如：以下的配置就可以在发布事件遇到没有订阅者的情况下不做任何处理。
另一个例子：当订阅者抛出异常的时候程序不会被EventBus捕获。
注意 默认情况下EventBus会缓存事件处理者的异常并发布一个 事件，但是并不一定需要处理这个事件。
点击EventBusBuilder class and its JavaDoc 查看所有的可配置项。
配置默认的EventBus实例
注意 这种设置只在默认的实例被第一次使用前才能生效。随后调用 会抛出异常。这样可以保证在你的App中EventBus动作保持一致。Application 类是在第一次使用前配置EventBus的一个好地方。
今天先到这里未完待续。。。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/173994.html