我在项目中使用EventBus，它运行良好，但一些大学表示他们对这个库有问题。我不是在谈论EventBus模式的concreate实现，有两种广泛使用的实现
但两者都使用反射。反射并不便宜，尤其是在移动设备上
所以我的问题是为什么不避免使用反射
例如，我的想法是使用Android服务作为事件总线管理器，或者您可以使用在应用程序生命周期中可用的自定义应用程序类。例如，服务将能够注册订阅者，通知他们，注销。。。EventBus所能做的一切。就服务是高优先级组件而言，我们可以确保它在我们需要发送事件时是活动的，例如，如果我们在应用程序类中引用它，那么它将是活动的
关于订阅者，为什么不只实现通用接口OnEventSubscriber<E extends BaseEvent>呢？如果你对多个事件感兴趣，你可以实现另一个具有适当事件类型的接口。并实现特定类型的onEvent方法。
为什么当前的实现使用反射方法而不是上面描述的方法？创建这些库的人都是经验丰富的开发人员，所以实现是这样的肯定是有原因的。
如有任何解释和意见，我将不胜感激。提前Thx。
请详细说明您指的是哪个EventBus实现？
Event Bus使用的一些真正优势：
- 快速简单的一对多事件(单个调度器-多个接收器(
- 来自应用程序任何部分的全局引用
- 从不同线程发送/接收事件
- 速度
- 粘性事件(在初始比赛条件场景中非常方便(，尤其是涉及多个数据层的情况
Greenrobot EventBus是实现上述功能的强大事件总线。
你也可以看到这种比较。
LocalBroadcastManager 1(不能满足以上所有2(需要更多的编码来调度/侦听