EventBus 3.0的用法详解(二)

这是一个系列，若是你尚未看以前的文章：

EventBus 3.0的用法详解(一)

前一篇文章简单介绍了EventBus 3.0的用法，如今是时候详解其用法了。首先声明，EventBus 3.0的改动针对2.4的改动并非特别大，可是对于其性能的提高是另一个说法了，因此建议学习EventBus 3.0。

注解

新增的@Subscribe

threadMode = ThreadMode.MainThread

用注解的方式代替约定的方法名规范，是其最大的改变。在2.4中，你可能须要这么定义：

public void onEventMainThread(MessageEvent event) {
        log(event.message);
    }

该方法为接收消息后在主线程中处理事件，而在3.0中：

@Subscribe(threadMode = ThreadMode.MainThread) //在ui线程执行
public void onUserEvent(UserEvent event) {
        log(event.message);
    }

其中ThreadMode提供了四个常量：

• MainThread 主线程

• BackgroundThread 后台线程

• Async 后台线程

• PostThread 发送线程（默认）

BackgroundThread:当事件是在UI线程发出，那么事件处理其实是须要新建单独线程，若是是在后台线程发出，那么事件处理就在该线程。该事件处理方法应该是快速的，避免阻塞后台线程。

Async：发送事件方不须要等待事件处理完毕。这种方式适用于该事件处理方法须要较长时间，例如网络请求。

sticky = true

默认状况下，其为false。什么状况下使用sticky呢？

相信大多数使用过EventBus 2.4的同窗或多或少的使用过：

EventBus.getDefault().postSticky(new VoteEvent(obj));
EventBus.getDefault().registerSticky(this);

你会发现很是的麻烦，那么在3.0中：

EventBus.getDefault().postSticky(new VoteEvent(obj));
EventBus.getDefault().register(this);
@Subscribe(sticky = true)

何时使用sticy,当你但愿你的事件不被立刻处理的时候，举个栗子，好比说，在一个详情页点赞以后，产生一个VoteEvent，VoteEvent并不当即被消费，而是等用户退出详情页回到商品列表以后，接收到该事件，而后刷新Adapter等。其实这就是以前咱们用startActivityForResult和onActivityResult作的事情。

priority = 1

相信大部分人知道该用法，值越小优先级越低，默认为0。

建议

推荐你们在使用EventBus的时候，建立一个事件类，把你的每个参数（或者可能发生冲突的参数），封装成一个类：

public class Event  {  
    public static class UserListEvent {  
        public List<User> users ;  
    }
    public static class ItemListEvent {  
        public List<Item> items;  
    }    
}

添加processor

按照Markus Junginger的说法（EventBus创做者），在3.0中，若是你想进一步提高你的app的性能，你须要添加：

provided 'de.greenrobot:eventbus-annotation-processor:3.0.0-beta1'

其在编译的时候为注册类构建了一个索引，而不是在运行时，这样的结果是其让EventBus 3.0的性能提高了一倍，相比2.4来讲，其会是它的3到6倍。你们能够感觉下：