在单例中使用 BroadcastReceiver 的最巧妙方法等等

Posted 2023-03-12

【中文标题】在单例中使用 BroadcastReceiver 的最巧妙方法等等

【英文标题】：Slickest way to use BroadcastReceiver in a singleton and more

【发布时间】：2010-09-17 14:51:17

【问题描述】：

我有一个单例，它存储有关我的应用程序用户的一些谨慎信息。目前，它存储用户的登录信息和用户的位置。

1) 该位置是通过服务找到的。目前，服务直接引用我的单例来将经度和纬度填充到其中。我想使用 BroadcastReceiver 来发送单例听到并用于更新值的广播。

但是，要注册 BroadcastReceiver，我需要在我的单例中添加一个 Context。实现我想要的最巧妙的方法是什么。 BroadcastReceiver 可能不是合适的对象吗？

2) 另外，我在使用单例时会遇到什么问题？我假设 android 可能会在任何给定时间回收此内存（这显然很糟糕）；那么我该如何防止呢？传入应用程序的 Context 并将其存储在成员变量中会阻碍这一点吗？

Android 文档指出：“但是，静态对象的生命周期并不受您的控制；因此要遵守生命周期模型，应用程序类应在 onCreate() 中启动和拆除这些静态对象和应用程序类的 onTerminate() 方法”，但我不完全确定如何完成。

【参考方案1】：

但是，要注册 BroadcastReceiver，我需要在我的单例中添加一个 Context。是什么 实现我想要的最巧妙的方法。 BroadcastReceiver 可能不是合适的 > 对象吗？

“最巧妙的方法”是不做你正在做的事。请仅从 Activity、Service 或 也许 Application 注册 BroadcastReceiver。当Activity、Service 或Application 被销毁时，您必须取消注册此BroadcastReceiver。

我假设 Android 可能会在任何给定时间回收此内存（这将 显然是坏的）；那我该如何预防呢？

你没有。 Android 保留随时终止您的进程的权利（例如，回收内存）。 Android 2.1 及更早版本的任务杀手将随时终止您的进程。一旦您的应用程序的所有组件都被销毁，Android 可能随时回收您的进程，同时清除您的堆。以此类推。

只把不介意丢失的东西放在记忆中。

最好将您的“应用程序”视为一篮子松散耦合的组件，而不是一个单一的实体。

会传入应用程序的上下文并将其存储在成员变量中 这个？

没有。

Android 文档指出：“但是，静态的生命周期并不完全在您的 控制;所以要遵守生命周期模型，应用程序类应该启动并 在 onCreate() 和 onTerminate() 方法中拆除这些静态对象 应用程序类”，但我不完全确定如何完成此操作。

创建Application 的子类，并通过<application> 元素上的android:name 属性在清单中指出Android 应该使用它。

【讨论】：

感谢您的意见。您如何推荐“随身携带”：此信息？您是否建议每次需要时都从数据库中读取它（假设“它”是通过 Web 服务传递的登录信息）？

是的，将其存储在数据库中或SharedPreferences

那么，您是否建议将我的单例与保存登录信息的成员变量一起保留，并在单例中创建一个方法来检索它们，该方法要么返回所要求的值，要么如果未设置（即：单例被销毁并重新创建），从数据库中读取，设置并返回？

为什么要滚动自己的单例而不是使用服务？

我对 Android 开发还很陌生。我知道服务避免被回收；这就是人们避免这个问题的方式吗？是不是很讨厌？