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中一定要写好必要的注释信息，否则在后续工作交接中会产生很多不必要的麻烦。