Android中基于LiveData实现的集中式事件系统为何属于不良实践？

• 静态伴生对象导致的多实例响应异常
  Kotlin中BaseActivity的伴生对象属于类级别的静态存储，其持有的MutableLiveData全局唯一。如果应用任务栈中同时存在多个BaseActivity子类的存活实例（例如A Activity启动B Activity后，两个页面都未销毁），所有实例都会观察同一个全局通知LiveData，单次事件下发会触发所有存活Activity同时弹出通知，不符合仅给当前前台页面展示通知的预期。
• 粘性事件带来的脏数据问题
  MutableLiveData本身是粘性观察者，新Activity实例创建后开始观察时，会自动收到LiveData中存储的最近一次历史事件，导致新打开的页面毫无缘由弹出之前的旧通知，产生意料之外的业务故障。
• 内存泄漏风险
  虽然LiveData具备生命周期感知能力，会在LifecycleOwner销毁时自动解绑观察者，但如果事件本身持有上下文相关对象，或是观察者匿名内部类隐式持有了Activity实例，静态LiveData的长生命周期会导致这些对象无法被GC回收，应用长期运行会积累大量内存泄漏。
• 架构耦合度高、扩展性差
  这套方案强制所有页面必须继承BaseActivity，违反了「组合优于继承」的设计原则，后续如果需要引入其他基础Activity类、或是在Fragment、Service等非Activity组件下发通知，这套机制完全无法复用。同时全局可写的LiveData没有统一收口，无法做事件拦截、日志、去重等统一处理，排查问题成本极高，也无法单独抽离逻辑做单元测试。

你可以改用内部实现了单次消费逻辑的非粘性LiveData变体（常被称为SingleLiveEvent）作为事件载体，同时通过Application注册Activity生命周期回调的方式获取当前栈顶的Activity实例分发事件，无需强制所有页面继承BaseActivity，扩展性更强。

内容的提问来源于stack exchange，提问作者Lheonair