解读

国内面试中，EventBus 常被当作“解耦神器”来提问，但面试官真正想听的是“你为什么敢用、又为什么不敢用”。回答时要围绕“生命周期、线程、内存、异常、维护”五个维度，把“风险”拆成“现象→原因→后果→规避”，并给出可落地的替代方案。切忌只背“粘性事件会内存泄漏”这种结论，而要展示“我能在真实项目里量化风险并收口”。

知识点

1. 生命周期错位：Activity/Fragment 已销毁但订阅者未注销，导致非法状态访问。
2. 粘性事件内存泄漏：sticky 事件持有对外部类或 View 的强引用，GC Root 无法释放。
3. 线程模型失控：post 默认 POSTING 线程，若在主线程触发耗时计算直接 ANR；切换线程时未捕获异常导致 crash 被系统直接回收。
4. 异常传播：订阅方法抛出未检查异常会沿调用栈向上冒泡，若发生在主线程则直接触发 crash，且无法通过 try-catch 兜底。
5. 订阅者索引缺失：未使用 subscriber index，反射遍历方法列表在低端机首次注册耗时 50-100 ms，引发启动卡顿。
6. 混淆错位：R8/ProGuard 规则漏配导致方法被裁剪，运行时 NoSubscriberException，线上灰度 1% 直接触发热修。
7. 调试黑洞：post 事件无调用链，Systrace 无法追踪，复杂业务中“谁发了、谁收了”只能靠日志 grep，排查成本指数级上升。
8. 模块化污染：EventBus 默认单例，跨模块通信时所有事件集中在一个总线，违反“模块边界清晰”原则，造成编译期耦合回潮。
9. 合规风险：国内 SDK 合规检测要求“通信链路可溯源”，EventBus 的隐式调用被认定“行为不可解释”，上架华为、OPPO 商店需额外说明。
10. 替代方案认知：LiveData、SharedFlow、RxBus、Service Locator、依赖注入作用域，各自适用场景与迁移成本。

答案

“我在项目中把 EventBus 风险总结为‘四颗雷’：

第一颗雷，生命周期雷。Fragment 在 ViewPager2 中被回收后若未 unregister，收到事件再访问 view 直接空指针。我的做法是统一在 Fragment 的 DefaultLifecycleObserver 里绑定/解绑，利用 Lifecycle 感知能力把注销动作下沉到基类，零侵入业务。

第二颗雷，内存雷。粘性事件缓存的是‘对象’而不是‘数据’，曾经因为缓存了 BitmapDrawable 导致 7 天线上 OOM 上涨 0.8%。我改成只 sticky 纯数据 DTO，并在 Application 的 onTrimMemory 里主动 removeStickyEvent，OOM 回落到 0.1% 以内。

第三颗雷，线程雷。post 事件如果在主线程触发数据库查询，ANR 阈值 5 秒直接被击穿。我制定团队规约：所有事件处理方法必须加 @Subscribe(threadMode = BACKGROUND) 并配 @WorkerThread 注解，配合 Lint 自定义规则扫描，编译期失败，彻底杜绝主线程耗时。

第四颗雷，崩溃雷。订阅方法里抛出的异常 EventBus 不会捕获，主线程直接闪退。我引入 Kotlin Coroutine 的 supervisorScope，把事件处理搬到协程并设置 CoroutineExceptionHandler，把异常收敛到统一日志平台，crash 率从 0.3% 降到 0.02%。

完成以上收口后，我们把 EventBus 当成‘有限场景’工具：仅用于进程内、生命周期短、无粘性、无共享状态的广播，例如页面内 UI 刷新信号。跨模块、跨进程、配置变化后的状态恢复一律使用 Flow+Repository 模式，半年内逐步把 EventBus 调用从 600 处降到 30 处，可维护性提升 40%，并通过了国内主流商店合规审计。”

拓展思考

1. 如果团队决定全面移除 EventBus，如何量化迁移收益？可建立“事件链路可视化”脚本，在编译期扫描所有 post 与 subscribe，生成调用图，计算每个事件的订阅者数量与生命周期跨度，优先迁移“多订阅+长生命周期”事件，预计减少 70% 的注销遗漏。
2. 在车载多屏场景下，系统级服务需要向多个 Display 的 Fragment 发送事件，是否仍用 EventBus？答案是否。车载安全要求 ASIL-B，EventBus 的隐式调用无法满足追溯要求，应使用 CarService 提供的 PropertyManager+HIDL 接口，并通过 AIDL 回调实现强类型契约。
3. Kotlin 2.0 之后，官方推荐“共享状态用 StateFlow，一次性事件用 SharedFlow”，但 SharedFlow 的 replay=0 会丢事件，如何兼顾“生命周期安全”与“事件不丢失”？可引入“事件持有者”模式：ViewModel 持有 SharedFlow，UI 层在 Lifecycle.repeatOnLifecycle 中收集，配置变更时数据保存在 SavedStateHandle，既无泄漏也不丢事件，完全替代粘性事件。