0

这一直困扰着我一段时间。

简而言之，是否可以在不阻止操作系统在适用时破坏它的情况下传递活动上下文？

例子：

在套接字上发出一个异步请求，附加到它的是一个哈希图，其中 key=request_id 和 value=activity_context。根据响应，id 被链接以获取 activity_context 并调用活动中的方法（即使用接口、强制转换等）。

我知道存储对上下文的弱引用，但已知 android OS 垃圾收集会在它仍然“活着”且频率越来越高的情况下清理弱引用。

请随时索取更多信息，我真的很想得到一个结论性的答案。

4

2 回答 2

1

感谢您的回复，非常感谢！

关于你的说法，

它不能是另一种方式：你不能阻止一个活动的破坏。但是，如果您保留对此类对象的引用，则它不会被垃圾收集，而对您没有真正用处。简而言之，就是您可能希望避免的内存泄漏。这是否会阻止创建具有相同上下文的新活动？即我不想回到以前的上下文。

在回答您的问题时：

  1. 套接字的生命周期：活动相关？一个用于整个应用程序，直到进程被杀死或用户注销？
    • 套接字链接到应用程序进程，由用户登录启动并在用户注销时断开连接（和应用程序背景......我知道，客户请求）
  2. 当设备配置更改并重新创建活动时：您想在新活动中接收对旧请求的响应吗？
    • 是的，我愿意，尽管到目前为止这不是一个大问题，因为使用 android:configChanges="orientation|screenSize" 和 android:screenOrientation="nosensor" 等元标记禁用了方向更改
  3. 当您在响应准备好之前完成活动（或用户按 BACK）然后返回它之后，您希望看到它吗？
    • 嗯...棘手，大多不是。我正在使用@CommonsWare 提到的greenrobot 的EventBus，它允许粘性事件。例如，用户在启动登录过程时回退应用程序，我需要捕获结果以避免重复登录会话

关于

你的意思是当对象有强引用时，WeakReference 的引用为空？我认为这不可能发生。

我为此道歉。我现在无法备份它，我只记得在 Google 小组中读到过这个。如果我再次看到它，我会在这里发布。

于 2013-07-08T09:50:16.563 回答
0

可以在不阻止操作系统在适用时破坏它的情况下传递活动上下文吗？

它不能是另一种方式：你不能阻止一个Activity. 但是，如果您保留对此类对象的引用，则它不会被垃圾收集，而对您没有真正用处。简而言之，您可能想要避免的内存泄漏。

在套接字上发出一个异步请求，附加到它的是一个哈希图，其中 key=request_id 和 value=activity_context。根据响应，id 被链接以获取 activity_context 并调用活动中的方法（即使用接口、强制转换等）。

这种方法没有什么特别错误的，但是为了避免泄漏（以及由它们引起的潜在崩溃），我建议在它进入破坏状态时从Map所有与之相关的请求中删除。Activity如果您的架构可以做到这一点，您也可以取消这些请求。

也就是说，最好遵循 CommonsWare 的建议并使用他评论中为此类用例构建的一种方法。

我可以在这里进行理论化并最终在这里写一篇完整的文章，因此最好使用以下信息更新您的问题：

  • 套接字的生命周期：Activity相关？一个用于整个应用程序，直到进程被杀死或用户注销？
  • 当设备配置更改并重新创建活动时：您是否希望在新请求中接收对旧请求的响应Activity？
  • 当您（或用户finish在Activity响应准备好之前按 BACK）然后返回它之后，您希望看到它吗？

我知道存储对上下文的弱引用

问题WeakReferences在于它们无助于避免泄漏。是的，它们有助于避免永久性泄漏，在这种情况下您会无限期地保留一个错误的引用，但它们不会阻止对已经被破坏的调用Activity。

众所周知，android 操作系统垃圾收集会在它仍然“活着”且频率越来越高的情况下清理弱引用。

你的意思是WeakReference' 的引用是空的，而有对对象的强引用？我认为这不可能发生。

于 2013-06-26T17:42:02.187 回答