不知道何年何月,一个叫EventBus的东东映入了我们的眼帘,让我们喜中生悲,悲中又夹杂着无比的喜,让我们高兴的是,利用EventBus可以很容易地实现组件与组件之间的通信,无论跨线程与否,简单的注册与监听,就可以让我们轻松实现。
何为EventBus?EventBus是一款针对Andoid优化的发布/订阅事件总线,主要功能是替Intent,Handler,BroadCast在Fragment,Activity,Service,线程之间传递消息,优点是开销小,代码更优雅,以及将发送者和接收者进行解耦。以观察者模式实现,用于简化程序的组件、线程通信,可以轻易切换线程、开辟线程。需要注意的是EventBus3.0跟先前版本的区别在于加入了annotation @Subscribe,取代了以前约定命名的方式。这一点应当很重要,在测试的时候,就因为所回调的方法没有加上@Subscribe,就报了(its super classes have no public methods with the @Subscribe annotation)这样的一个错误,所以,使用时请大家知悉。
在没有接触EventBus之前,也许在Android开发中,组件间的通信或者前后端线程之间的通信都是通过持有引用的回调或者Handler来实现的,但是过多回调势必带来一些副作用,比如:强引用,可能导致内存泄漏;多层回调的代码逻辑可读性差,调试时甚至使人摸不着头脑;直接用匿名内部类去实现很容易就出现多级缩进,长长的屏幕都看不完一行代码;要跨线程必须要用Handler或AsyncTask等等。
而EventBus是可以替代回调的。但替代的时候并不是那么简单地在原来调用回调方法的地方调用EventBus的post方法即可。具体的回调应有的步骤如下:
1、把回调里传的数据抽离成一个消息类Msg,一个回调方法对应一个消息类。
2、在调用回调方法的地方把调用改为EventBus的post方法,参数是上一步中抽取出来的Msg类。
3、把原来实现了的回调方法改为用Subscribe注解标明该在哪类线程运行,并把原参数改为抽取出来的Msg类,在具体实现里再从Msg实例取出对应的数据。
4、在添加回调的代码处改为EventBus的register方法;并在所处的组件销毁时的回调方法(如onDestroy、onDestroyView等,注意要和register方法所处的生命周期对称)内调用EventBus的unregister方法。
我们再来谈谈具体使用吧,这个地址:https://github.com/greenrobot/EventBus是EventBus的github地址,下载下来,依赖为我们要使用的库,其实使用起来,以上的步骤中诉述了,下面我举几个场景:
场景一:Activity之间进行传递消息
两个Activity,从第二个Activity接收返回来的参数,启动的时候用startActivityForResult,在onActivityResult里接收参数可以搞定,但是,从第一个Activity跳到第二个Activity再跳到第三个Activity,甚至跳到第N个Activity,来接收返回的参数,显示在第一个Activity上,你该如何操作呢亲?当然你可以是使用广播,来监听返回的消息,简单的参数你也可以直接使用SharedPreferences,当然了,你也完全可以每次跳转都startActivityForResult,然后在每个Activity里接收参数,直至第一个Activity,也许你会有各种各样的实现的方式,但是用了EventBus,你肯定会爱不释手。
简单四步走:
1、在需要接收参数的Activity中onCreate进行注册:
EventBus.getDefault().register(this);
2、在需要接收参数的Activity中重写回调方法,一定要记住,添加@Subscribe,并且所接收的参数和发送时的参数保持一致:
publicvoidonEventMainThread(MessageBeanbean) { tvContent.setText(bean.getMsg()); }
3、在需要传递信息的地方发送:
MessageBeanbean=newMessageBean(); bean.setMsg("你好"); EventBus.getDefault().post(bean);
4、在接收的Activity中进行onDestory中进行反注册:
voidonDestroy() { super.onDestroy(); EventBus.getDefault().unregister(this); }
场景二:Activity和Fragment进行互相通信
两者之间进行通信,我们可以采取接口回调或者注册广播,当然了既然是描述EventBus,EventBus当然这一职责也必须可以胜任,具体的实现逻辑和场景一差不多,无非就是,在需要接收的页面进行注册,重写回调函数,在需要传递的地方进行post传递,具体大家可以自行揣摩。
也许还有很多场景,在这里就不一一说了,EventBus说的那么好,具体它有什么缺点呢,俗话说,金无足赤人无完人,十全十美也不太现实,EventBus的缺点可以总结如下:1、只要用得一多,那消息类的数量必然是会爆炸性增长。2、调试的时候除非熟悉整块逻辑,不然不跑起来你是没办法了解Subscribe的方法的数据来源。我们需要看清的现实是,其优点是远远大于它的缺点的,我们不能因为几个缺点就抛弃了它。
补充说明:
上面的文章中,介绍了一个回调函数获取参数的方法onEventMainThread,除了这个函数,其实EventBus还有几个,分别是:
onEvent:如果使用onEvent作为订阅函数,那么该事件在哪个线程发布出来的,onEvent就会在这个线程中运行,也就是说发布事件和接收事件线程在同一个线程。使用这个方法时,在onEvent方法中不能执行耗时操作,如果执行耗时操作容易导致事件分发延迟。
onEventMainThread:如果使用onEventMainThread作为订阅函数,那么不论事件是在哪个线程中发布出来的,onEventMainThread都会在UI线程中执行,接收事件就会在UI线程中运行,这个在Android中是非常有用的,因为在Android中只能在UI线程中跟新UI,所以在onEvnetMainThread方法中是不能执行耗时操作的。
onEventBackground:如果使用onEventBackgrond作为订阅函数,那么如果事件是在UI线程中发布出来的,那么onEventBackground就会在子线程中运行,如果事件本来就是子线程中发布出来的,那么onEventBackground函数直接在该子线程中执行。
onEventAsync:使用这个函数作为订阅函数,那么无论事件在哪个线程发布,都会创建新的子线程在执行onEventAsync。
这四种订阅函数都是使用onEvent开头的,它们的功能稍有不同,注意两个概念:
告知观察者事件发生时通过EventBus.post函数实现,这个过程叫做事件的发布,观察者被告知事件发生叫做事件的接收,是通过订阅函数实现的。