【问题标题】:recycle bitmap ice cream sandwich force close回收位图冰淇淋三明治力关闭
【发布时间】:2012-02-24 18:34:05
【问题描述】:

在我的 ondestroy 方法中,我回收了所有用于释放内存并防止应用程序在屏幕旋转期间崩溃的位图。事实证明,在冰淇淋三明治 (android 4.0) 之前,这对所有 API 都是正确的做法。现在,当我在 ICS 上旋转时,我会强制关闭并且 logcat 没用。我无法将其追溯到我的代码,但是当我删除位图回收时,它对 ICS 非常有用。对此有何想法?

【问题讨论】:

  • 这可能无关紧要,但最近我看到 ICS 中的 initial 内存使用量上升了。我相信它现在正在预取所有可绘制对象。也许即使您没有对可绘制对象的引用,框架仍然存在并且它正在尝试设置您回收的位图?
  • 你能判断崩溃是在 onDestroy() 期间还是之后发生的吗?如果您在几个可能有助于发现的地方粘贴 Log.d(TAG, "message") 调用?如果是在实际的 recycle() 调用期间,如果只在 isRecycled() 返回 false 的 Bitmap 对象上调用 recycle() 会发生什么?

标签: android bitmap rotation android-4.0-ice-cream-sandwich recycle


【解决方案1】:

您是否正在回收从资源中检索到的位图?听起来操作系统保留了对位图的引用,并将其用于将来对同一资源的调用。在这种情况下,当屏幕旋转时,它会尝试使用您刚刚回收的同一个 Bitmap。这将导致强制关闭。

您可能根本不需要手动回收位图。这是一个非常危险的调用,尤其是在从资源加载的位图上。

【讨论】:

  • 是的,我正在回收来自资源的位图。我可以不调用回收,但这是我发现在非 ICS 版本上防止 OutOfMemoryErrors 的唯一方法。你有什么建议吗?我需要这个才能在 Froyo 及更高版本上工作....
  • 在我们的应用程序中,我们下载并缓存了大量图像。我们永远无法确定是否仍在使用一个,所以我们每隔一段时间就会调用 System.gc()。您可能会在之前调用 recycle() 的地方调用 System.gc()。附带说明一下,我们还在 try/catch 中包围 OutOfMemoryErrors,并在 System.gc() 之后重试。
  • 据我了解,System.gc() 对 ICS 前代码中的位图内存泄漏没有帮助。如果版本之间的事情从“如果你不回收位图,你的图像密集型应用程序将会死”到“如果你回收位图,你的图像密集型应用程序将会死”,那么我就是一个最不为所动的开发者。
  • 我在位图回收方面遇到了很多问题。我不知道系统在配置更改时持有资源,但我知道 1 如果 Bitmap 已使用 setImageBitmap (Bitmap) 放入 ImageView 中,则您必须 setImageBitmap(null) 以释放内存,即使您ve 调用了 recycle() 和 2,如果您在 View 中设置了资源,并且您将它们设为空以释放第二个 Activity 的内存,则只有在 onPause() 中执行此操作时才会释放内存--onStop() 为时已晚。即使通过 recycle() 调用,系统也会非常顽固地保留位图数据。
  • +1 表示不回收从资源中解码的位图。我有一个类似 Volley 的复杂系统,可以跟踪来自 url 的位图并在其使用量为 0 时回收,但只是针对资源和 crashcrashcrashcrash 进行扩展,直到不回收这些。
猜你喜欢
  • 1970-01-01
  • 2012-05-02
  • 1970-01-01
  • 1970-01-01
  • 2012-03-11
  • 2014-03-26
  • 2012-03-21
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多