您如何处理没有明确退订位置的情况？
在 Android 的 BroadcastReceiver 中，没有可以调用 EventBus 取消订阅的生命周期结束方法。这个 BroadcastReceiver 可以被多次调用。由于没有取消注册，该事件在第一个事件之后以指数方式（实际上是算术）触发更多动作，因为我们在初始化方法（onReceive）中再次注册。
我猜这种情况很常见，可以在这里讨论。
我们正在检查是否有特定事件的现有订阅者，只有在没有订阅者时才在总线上注册。
这似乎是骇人听闻且不可靠的方法。举个例子，如果代码的另一部分开始依赖相同的事件并且也必须注册怎么办？我们已经有一个来自新位置的公共汽车上的订阅者，我们的旧代码不会自行注册。我们的逻辑将失败，或者必须变得更加复杂，并且与订阅者的数量等紧密耦合。
如果问题不容易理解，请指出，我可能会尝试另一种解释方式。
广播接收器由 Android 创建来处理一个广播。它们在处理 UI 的主线程上运行。因此，它们应该运行得非常快，并且绝对不做任何长时间运行的任务或访问网络。
鉴于此，他们在事件总线上注册根本没有意义。
相反，您的广播接收器应该只在 Android 服务上开始一些工作，该服务具有已定义的生命周期，是注册事件总线的理想选择。
好吧，我在这里回答。
第一的 ：
这个 BroadcastReceiver 可以被多次调用。由于没有取消注册，该事件在第一个事件之后以指数方式（实际上是算术）触发更多动作
我不知道您使用的是哪个 EventBus。但是，如果 EventBus 持有对您的订阅者的强引用，那么如果您无法取消订阅，您将会发生内存泄漏。这也可能是您的 BCR 多次注册的原因，因为实例在其onReceive方法被调用后实际上并没有被销毁（但应该被销毁）（只是一个理论，有待确认）。
如果您在 BCR 中收到某些内容后必须执行长时间的任务，请启动Service。只要它的任务没有完成，Service就会运行（实际上，你也可以让它处理自己的生命周期）。AService的设计目的是为了长期存在，并且是订阅 EventBus 的良好候选者，因为它实际上定义了一个生命周期，这意味着您可以轻松订阅和取消订阅。
我不确定您的问题与以下相关：
这似乎是骇人听闻且不可靠的方法。举个例子，如果代码的另一部分开始依赖相同的事件并且也必须注册怎么办？我们已经有一个来自新位置的公共汽车上的订阅者，我们的旧代码不会自行注册。