【EventBus】性能更优的Broadcast替代者

今天写一个蓝牙通信的app，需要10ms间隔持续的接收数据，接收端当然在service里了，但是数据要在主activity进行处理和UI显示，所以我在service的蓝牙通信子线程把数据发送到activity。然后在这之前我就用了EventBus来进行service和activity的通信，但是也只是初学者想要尝试一些新东西。接下来诡异的事情发生了，因为EventBus确实不如Broadcast易用，所以我莫名其妙的替换成了Broadcast，然后activity接收有了延迟，而且是很明显的延迟，10几秒的那种。排查了好久，终于在同事指导下发现是Broadcast导致的延迟。本人菜鸟一只，也不懂为什么，只知道大概是Broadcast的性能问题，而且换了EventBus之后确实延迟现象没有了，本篇就当记录一下这个坑吧。

下面是EventBus的使用方法：

官方GitHub地址：https://github.com/greenrobot/EventBus

 

第一步首先添加库依赖：implementation 'org.greenrobot:eventbus:3.1.1'

第二步然后是发消息，非常简单，就一句话：EventBus.getDefault().post(new MessageEvent());

MessageEvent()自己写一个就可以，下面给一段示例:

private class MessageEvent{
	    public int type;
	    public int[] msg;
	    
	    public MessageEvent(int type,int[] msg){
	        this.type = type;
	        this.msg = msg;
        }
        
        public int getType(){
	        return type;
        }
        
        public int[] getMsg(){
	        return msg;
        }
    }

 

第三步接收消息需要先注册：EventBus.getDefault().register(this); 也别忘了解注册：EventBus.getDefault().unregister(this); 在哪里接收就在那里注册，可以注册多个接收者。

注册了之后必须接收消息，不然程序会崩溃；

    @Subscribe(threadMode = ThreadMode.MAIN)
    public void onMessageEvent(MessageEvent event) {
	    switch (event.type){
            case 0:
                int[] msg1 = event.msg;
                //do something
                break;
            case 1:
                int[] msg2 = event.msg;
                //do something
                break;
        }
    };

threadMode是接收消息的线程模式，有四种模式可供选择：

摘抄一个别人博客的线程模式解释：

• POSTING (默认) 表示事件处理函数的线程跟发布事件的线程在同一个线程。
• MAIN 表示事件处理函数的线程在主线程(UI)线程，因此在这里不能进行耗时操作。
• BACKGROUND 表示事件处理函数的线程在后台线程，因此不能进行UI操作。如果发布事件的线程是主线程(UI线程)，那么事件处理函数将会开启一个后台线程，如果果发布事件的线程是在后台线程，那么事件处理函数就使用该线程。
• ASYNC 表示无论事件发布的线程是哪一个，事件处理函数始终会新建一个子线程运行，同样不能进行UI操作。

 

在使用EventBus的时候确实感觉易用性不够，坑很多，但是鉴于本人是初学菜鸟，可能是我不会用而已吧。