Android 事件总线的使用、内存和体系结构

我开始在我的应用程序中使用EventBus，它的使用非常好，它解决了很多问题，简化了代码，在应用程序中的所有线程和所有内容的传播都非常棒，但我感觉我可能滥用了事件的使用

现在一切都很好，我正在强大的设备上测试，应用程序的响应非常好，但我还有很多代码要做，我开始质疑自己，如果应用程序中触发了太多事件，会有什么影响

因此，问题是对于任何有该库经验的人来说，如果我的应用程序中有很多事件存在一些问题，如果使用这些事件时存在一些已知的内存问题。我试图明智地使用它，但很难不在您的体系结构中包含它，因为它是一个非常好的功能。无论如何，如果你对这个主题有什么要说的话，那就很好了，因为我有很多代码要做，如果我的架构有问题的话，那将是一个问题，我必须回去进行更改，因为一些问题与事件有关

警察局。我说的是原生安卓应用，有很多网络

---

Thx

我理解你的意思，我还在我们公司开发大量的代码库，我们经常使用事件总线。你只需要小心一点，但如果你想知道应用程序中哪些地方订阅了某个特定的活动，那会让你很恼火。如果有多个订阅，那么必须通过应用程序进行搜索不是很有趣。作为一个解决方案，我喜欢使用这个惊人的Android Studio插件，用于Otto事件总线，它将无缝地将您从事件和它的订阅者联系起来，反之亦然

https://github.com/square/otto-intellij-plugin

---

这将大大简化事件和订阅者之间的导航。

只要您遵循组件生命周期更改，在应用程序中有许多事件并不成问题：在

onStart（）

中注册事件，在

onStop（）

中注销事件。如果您这样做，那么只有相对较小的活动组件子集将订阅事件，这使得整个解决方案更加精简

---

在我的应用程序中，我对中央单例事件总线实例有一些问题，这就是为什么我使用一个能够连接到活动并尊重其生命周期的实例。有了它，我可以为每个活动创建一个总线实例，这非常轻量级。

我个人认为，我滥用事件要比使用

侦听器-观察者模式（或者在iOS上使用委托模式）容易得多，尽管它们非常相似。事件在架构上没有本质上的错误，但是您必须小心处理它们。如果你一开始就有这种感觉，那是有原因的。我会尽量坚持使用
listener-observer
，除非实现某种目标的唯一方法是使用事件。只是重申一下，这只是我的观点。是的，我担心的是，它可能变得棘手，难以维护和扩展，目前，我正在使用volley库进行网络连接，我正在处理所有事件回调，我还使用事件处理我应用程序中需要停止执行并需要在整个应用程序中传播的关键错误/问题，例如，在web服务调用之前请求internet连接，如果在当前可见的活动/片段或Toast中没有显示对话框屏幕，但我发现自己越来越倾向于使用它，这就是为什么我问：是的，它看起来像一个不错的工具，但我没有使用Otto，而是使用greenrobot EventBus库：。我正在处理大量的调用和回调，试图在一个大项目中尽可能有组织地进行，现在看起来不错，让我们看看维护和可伸缩性在时间上是什么样子。Thx对于响应，不要认为它是正确的，因为它只用于Otto，但对其他人来说是一个很好的工具，所以你得到了我的投票。是的，我在我的项目中处理注册/取消注册事件非常好，我使用的EventBus库处理这部分非常好，正在查看你的库和示例，它看起来很好。在greenrobot的EventBus库中，事件处理程序singleton已经由库提供，因此您只需注册即可。谢谢你的回复