【问题标题】:How to release memory when activity goes to stack?当活动进入堆栈时如何释放内存?
【发布时间】:2014-06-17 08:49:18
【问题描述】:

我的应用程序由(例如)3 个活动组成:Activity1、Activity2、Activity3。每个活动在 XML 文件中声明的所有主要布局上都有一个唯一的背景图像。 从 Activity1 用户转到 Activity2 和 Activity3 旁边,所以前 2 个被推入堆栈。 问题是前 2 个活动占用了太多内存,在 Activity3 中我有时会出现 OOM 异常。 我找到了关于这种行为原因的答案 - https://stackoverflow.com/a/4836241/1159507 在此之前,我相信当活动进入堆栈时,它会释放所有内存。 我相信片段堆栈的相同行为。 所以我的问题是 - 如何在活动或片段进入堆栈时释放内存并在后按时保持负责任的 UI?

【问题讨论】:

  • startActivity(intent)之后尝试使用finish()
  • 如果我打电话给finish(),我以后将无法通过后按返回此活动。
  • 如果他使用finish(),则activity会被销毁。然后他必须再次传递来自onBackPressed() 的第二个和第三个活动的意图。可以通过这种方式实现,但在更改 Android 的默认行为时以这种方式实现是不好的做法。

标签: android memory-management back-stack


【解决方案1】:

Activity 的资源(在 onPause、onStop、...中未释放)在 Activity 进入后台时不会被释放。

  • 您可以在 onPause() 中移除背景,这样 GC 将 能够摧毁它。但是,“空白背景”会在那里 几分之一秒。重要的是要提到,你必须 在 onPause() 中执行此操作。 (我认为 onPause 之后的更改(如 onStop 中的更改)会在 Activity 进入前台时生效,因此当 Activity 在后台时,对背景的引用仍会被 Activity 持有。)
  • 另一种方法是调用finish(),自己管理堆栈。你 必须记住开始的活动,并导航到它 当用户按下后退按钮时手动进行。
  • 我想到的最后一个解决方案是通过在清单中声明 android:process 属性,使每个包含大量资源的 Activity 成为一个单独的进程。这样一来,您的所有活动都会有一个单独的完整大小的堆可供使用。

【讨论】:

  • >>>值得一提的是,您必须在 onPause() 中执行此操作,因为这是您可以触摸 UI 的最新点
  • 还有startActivity时,根据测试,方法会依次调用:Activity1_onPause, Activity2_onCreate, Activity2_onStart, Activity2_onResume, Activity1_onStop
  • 正如我所说,您不能在 onStop 中触摸 UI。你可以试试看:)
  • 我试过了,效果很好。我的意思是 getBackground() 和 setBackgroundResource(0)
  • 好吧,我错了,你仍然可以在 onStop 中操作 UI。但是,我担心 Activity 仍然会以这种方式保存对背景的引用。你能验证一下吗?
【解决方案2】:

您可以将所有消耗大量内存的对象(例如:在您的情况下为大图像)保存到您的第一个活动的 onStop() 的本地存储中,当用户按下时,您可以将它们加载到您的第一个活动的 onStart() 中。

【讨论】:

  • 如果我在 XML 中设置,如何释放图像的内存,比如我的根布局的 "android:background="@drawable/some_image"?
  • 实际上我看到了一种方法 - 将图像手动放入 onStart() 并以某种方式将其从背景中删除 onStop()。但它非常不方便且不明显,如果我从 XML 中删除此代码,我也不会在 xml IDE 预览中看到我的图像,或者如果不从 XML 中删除,我会做两次相同的工作。
  • @anber 下面提到的链接将消除您的所有疑问。如果您仍有任何疑问,请回复我。 curious-creature.org/2008/12/18/avoid-memory-leaks-on-android
  • 好的,所以我有一个用户经常在活动之间切换,这意味着他们可能在 20 秒内切换了 15 个活动。这可能是导致内存不足错误的原因吗?我应该怎么做才能修复它?谢谢!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-07-25
  • 2013-07-13
  • 1970-01-01
  • 2015-08-13
  • 2012-09-17
  • 2011-05-23
相关资源
最近更新 更多