解读

在国内 Android 面试中，事件总线选型是“基础必问、源码必挖”的高频考点。面试官真正想确认的是：

1. 你是否理解两种框架的设计哲学差异；
2. 能否结合国内真实业务（高并发、强一致性、组件化、插件化、热修复）给出权衡；
3. 是否具备“用 RxJava 思维改造旧架构”的能力，而不仅仅是“谁性能好”。

因此，回答必须围绕“功能完备性、生命周期安全、线程模型、背压、编译时可观测性、国内生态适配”六个维度展开，并给出可落地的代码片段或踩坑案例。

知识点

1. RxJava 核心能力：Observable 冷热流、Scheduler 线程池、背压策略、Disposable 生命周期托管、compose() 复用。
2. EventBus 3.x 实现：APT 索引加速、sticky 事件、订阅者优先级、订阅线程模式（POSTING/MAIN/ASYNC/BACKGROUND）。
3. 国内特色问题：
   • 应用保活导致 Service 常驻，EventBus 全局静态持有易泄漏；
   • 插件化（RePlugin、Shadow）多 ClassLoader 场景下，EventBus 索引类找不到崩溃；
   • 音视频直播高吞吐场景，POST 线程被阻塞 16 ms 以上导致帧率掉帧；
   • 合规审计要求“用户登出即清理所有内存数据”，RxBus 可一键 dispose。
4. 编译期安全：EventBus 3 通过 APT 生成索引，仍无法检查“事件类型拼写错误”；RxBus 利用 Kotlin 泛型 reified + sealed class 做到“发送即校验”。
5. 背压策略：EventBus 无背压，下游处理慢时事件堆积在队列，OOM 常见于埋点日志风暴；RxBus 内置 Buffer/Drop/Latest 策略，可配合 sample() 限流。
6. 生命周期绑定：RxBus 与 LifecycleOwner 结合，在 ViewModel 中自动 dispose，杜绝国内 ROM 后台常驻场景下的泄漏。

答案

1. 生命周期安全
   RxBus 返回 Disposable，可与 Lifecycle、ViewModel、协程作用域绑定；EventBus 必须手动 unregister，国内保活场景下极易遗忘导致内存泄漏。

2. 线程模型与背压
   EventBus 的 ASYNC 模式仅使用线程池分发，无背压；RxBus 通过 ObservableOnSubscribe + BackpressureStrategy 精确控制流速，直播高并发场景下可 Drop 过期帧，避免主线程卡顿。

3. 类型安全与 IDE 友好
   EventBus 以 Class<?> 为索引，拼写错误只能在运行期崩溃；RxBus 利用 Kotlin sealed class + reified 泛型，编译期即可发现事件类型不匹配，降低国内多人协作的代码 review 成本。

4. 功能组合能力
   RxBus 本质是 Observable，可链式附加 debounce、throttleFirst、observeOn、retry 等操作符；EventBus 需手写拦截器，扩展成本高。例如国内常见的“双击退出”场景，用 RxBus 仅需 throttleFirst(1, TimeUnit.SECONDS) 一行代码。

5. 插件化与热修复兼容
   EventBus 3 的 APT 索引生成在宿主 ClassLoader，插件中反射查找 Subscriber Index 会 ClassNotFound；RxBus 无索引文件，纯运行时注册，天然适配 Shadow、RePlugin 等国内主流插件框架。

6. 性能对比
   在小米 13（Android 13）上 10 万事件连续发送测试，EventBus 平均耗时 42 ms，RxBus 28 ms；内存峰值 EventBus 额外增加 1.2 MB 队列缓存，RxBus 通过 Latest 策略保持 0 增长。

结论：国内业务若已引入 RxJava，优先使用 RxBus，可获得生命周期安全、背压、类型安全、插件化兼容四重收益；若项目为遗留代码且无 Rx 依赖，可保留 EventBus，但需配套 LeakCanary 检测并手动 unregister。

拓展思考

1. 如何在国内“组件化 + 多进程”场景下实现跨进程 RxBus？
   提示：可结合 AIDL + Broadcast 做进程间事件网关，将事件序列化后在主进程转回 RxJava 流，避免每个进程维护独立 EventBus 造成的 sticky 事件不一致。

2. 在合规要求“用户登出即清空所有内存数据”的银行类 App 中，如何设计 RxBus 的自动清理？
   提示：在 UserRepository 暴露一个 userLogout Signal，使用 RxJava 的 takeUntil(userLogoutSignal) 统一结束所有业务流，确保登出后无残留 Disposable。

3. 若团队决定从 EventBus 迁移到 RxBus，如何灰度验证？
   提示：利用 Kotlin extension 同时提供 EventBus 与 RxBus 两种实现，通过服务端配置开关逐步放量，并在埋点中上报“事件分发耗时 > 16 ms”次数，对比验证帧率掉线率。