Android架构为何无需事件总线，竟无需依赖中间件实现组件间通信？

在过去的几年里EventBus几乎成了 Android 项目里“解耦神器”的代名词。它只要一行 post 就能把信息抛向全局， 又只要一行 @Subscribe 就能把消息拦截下来仿佛把所有组件都绑在了一根看不见的绳子上。只是 当我们站在 Jetpack 与 Kotlin 协程 的十字路口回望，会惊讶地发现：原来真正高效、平安的组件间通信根本不需要再靠这根老旧的“总线”，啥玩意儿？。

一、为什么“事件总线”已经成了负担？

1. 隐式耦合让调试变成盲盒。发送方只知道自己调用了 EventBus.getDefault.post 却无法预知究竟有多少订阅者在监听，更别提这些订阅者到底会做什么。代码审查时常常只能看到“一堆 @Subscribe 方法”， 但谁负责业务逻辑、谁负责 UI 更新都模糊不清，一旦线上出现异常，只能通过日志去追溯事件链，这种“黑盒”式的交互方式极易埋下隐蔽的定时炸弹，离了大谱。。

2. 类型平安缺失。EventBus 的核心是基于对象的运行时匹配——只要类名相同就能收到消息。编译器无法帮我们检查错误，一旦拼写错误或者改动了事件类名，就会导致运行时崩溃或“收不到消息”。比一比的话， Kotlin Flow/StateFlow 或者基于接口的服务调用，都可以在编译阶段捕获类型不匹配。

3. 生命周期盲区。EventBus本身对 Android 生命周期毫无感知。页面旋转、Fragment 重建后需要手动注册/注销，否则很容易产生内存泄漏或错过关键事件。而 Jetpack 的 LiveData/ViewModel 天生具备生命周期感知，无需额外代码即可平安地完成订阅与取消，不是我唱反调...。

4. 维护成本随项目膨胀而指数增长。