Android消息处理:EventBus、BroadCast和Handler-优缺点比较
上一篇研究了EventBus的使用方法,但随之而来的一系列问题也是值得思考,EventBus到底给项目带来了什么?它与Android原有的消息处理机制有什么区别和优缺点?项目在什么场景下采用EventBus会比较合适?因此,本篇就通过EventBus、BroadCast和Handler(Message)三者的比较解释这三个问题。
1、BroadCast
广播是相对消耗时间、空间最多的一种方式,但是大家都知道,广播是四大组件之一,许多系统级的事件都是通过广播来通知的,比如说网络的变化、电量的变化,短信发送和接收的状态,所以,如果与android系统进行相关的通知,还是要选择本地广播;在BroadcastReceiver的 onReceive方法中,可以获得Context 、intent参数,这两个参数可以调用许多的sdk中的方法,而eventbus获得这两个参数相对比较困难;
因此广播相对于其他的方式而言,广播是重量级的,消耗资源较多的方式。他的优势体现在与sdk连接紧密,如果需要同 android 交互的时候,广播的便捷性会抵消掉它过多的资源消耗,但是如果不同android交互,或者说,只做很少的交互,使用广播是一种浪费;
广播作为Android组件间的通信方式,可以使用的场景如下:
1.同一app内部的同一组件内的消息通信(单个或多个线程之间);
2.同一app内部的不同组件之间的消息通信(单个进程);
3.同一app具有多个进程的不同组件之间的消息通信;
4.不同app之间的组件之间消息通信;
5.Android系统在特定情况下与App之间的消息通信。
广播的不可替代性在于它可以跨进程进行通信,也就是不同APP之间可以通过广播进行传递数据,并且在OnReceiver中更容易使用Context和Intent对象来执行必要的操作。单就同一app内部的消息通信而言,使用广播是较为消耗资源和笨重的。
2、Handler
handler一般用于线程间通信,它可以分发Message对象和Runnable对象到主线程中, 每个Handler实例,都会绑定到创建他的线程中(一般是位于主线程),它有两个作用:
1.安排消息或Runnable 在某个主线程中某个地方执行;
2.安排一个动作在不同的线程中执行。
本篇只讨论handler中与Message相关的的消息通信,一般Handler的使用方法即在调用线程内创建Handler的内部类,并重写handlerMessage(Message msg) 方法,而在发布消息时使用sendMessage方法进行发布,在处理时通过switch(msg.what)进行消息分发并进行相应的处理。这里,Hander内部类和其定义类是绑定的,这就造成了事件发布者和接受者之间的高耦合。而Handler的最大好处是发生问题时,可以非常明确、快速的进行定位,通过msg.what很容易就可以理清每一条消息流的逻辑。
3、EventBus
EventBus的使用方法就不再多做介绍,详细请了解Android开源框架:Android EventBus 的使用
EventBus的优势在于调度灵活。不依赖于 Context,使用时无需像广播一样关注 Context 的注入与传递,也解除了Handler所带来的耦合,父类对于通知的监听和处理可以继承给子类,这对于简化代码至关重要;通知的优先级,能够保证 Subscriber 关注最重要的通知;粘滞事件(sticky events)能够保证通知不会因 Subscriber 的不在场而忽略。可继承、优先级、粘滞,是 EventBus 比之于广播、观察者等方式最大的优点,它们使得创建结构良好组织紧密的通知系统成为可能。
但EventBus也有很明显的缺陷,在EventBus中事件的分发是通过注解函数的参数类型确定的,因此在事件发布遭到大量滥用时,特别有多个订阅者、多个相同参数时,很难从事件发布者开始理清消息流,无法快速的找出是哪个订阅者接受并处理了消息导致的问题,这就要求了参与者必须对整个通知过程有着良好的理解。当程序代码适量时,这是一个合理的要求,然而当程序太大时,这将成为一种负担。在EventBus中一定要写好必要的注释信息,否则在后续工作交接中会产生很多不必要的麻烦。