EventBus 能否替代 Handler 消息机制 ？？？

目录

简介

一、 Handler消息机制

         优点和缺点：

 二、 EventBus 

 三、 总结

---

简介

网上有很多关于 EventBus 源码分析的文章， 但很少有 EventBus 和 Handler 消息机制对比的文章，那 EventBus 能否替代 Handler 消息机制那？ 

一、 Handler消息机制

由于 Android 应用启动的时候会创建一条主线程（也叫 UI 线程）， 应用默认运行在主线程中， 在主线程里不可做耗时操作，不然很容易造成 ANR ，同时 UI 操作只能在 主线程里操作 （子线程不可操作 UI）， 引入了 Handler 消息机制来解决这个复杂的问题， 当需要做耗时操作时需要另起一线程， 当需要做UI的操作时，  必要在主线程里操作； Handler 内部类一般创建在主线程， 通过消息对象与子线程间通信， 而消息对象持有 Handler 对象引用， 从而通过回调 Handler 对象里重写的 handlerMessage 方法刷新UI界面， 达到线程间通信的目的； 消息对象持有 Handler 对象， 并通过引用回调 handlerMessage， 从而可以在主线程中操作 UI ；

优点和缺点：

由于消息对象持有 Handler 引用，造成了消息通信双方的高耦合； 同时不雅的使用Handler容易造成内存泄漏（Handler 是匿名内部类，持有外部类的引用），但是 Handler 机制最大的好处是发生问题时， 可以快速明确的定位、 理清每一条信息流的逻辑;

 二、 EventBus 

网上分析 EventBus 源码的文章很多， 这里我就不做过多介绍， 直接来分析 EventBus 优缺点；

 EventBus 是 针对 Android 的一款高效的发布/订阅事件总线机制， 使用了发布订阅设计模式（Publish/Subsribe）， 也称观察者设计模式； 可以用来替代传统的组件通信方式（ Intent 、Handler 、 Broadcast 或接口函数在 Fragment 、 Activity 、Service 、线程之间传递数据），其优势如下：

1. 简化组件之间的通信方式
2. 引入了注解让业务代码更加简洁
3. 发送方和接收方的完全解耦
4. 指定事件处理线程，同时可以指定事件优先级
5. 粘性事件保证了不会因为 Subscriber 不在场而忽略
6. 子类可以继承父类的时间监听和处理

EventBus  有明显的缺陷，EventBus 中通过注解函数的参数类型来分发事件， 因此在事件发布遭到大量滥用时，特别是多个订阅者，多个相同的参数时，很难从事件发布者开始理清消息流， 无法快速找出是哪个订阅者接受并处理了消息导致的问题。 当程序代码适量时，这是一个合理的要求，然而当程序太大时，这将成为一种负担，故 EventBus 也不能滥用；

 三、 总结

虽说 EventBust 高度解耦、使用简洁优雅，但是也不能完全完全替代 Handler，毕竟 Android 中大量使用了 Handler  机制, 如果全部用 EventBus 替代，容易让接收你代码的人难以理解；同时发生问题时，消息流不能快速分辨， Handler 虽说耦合比较高，但是消息逻辑清晰； 故各有利弊吧。