【问题标题】:Getting OutofMemoryError/InvocationTargetException with finished activities and low kb images?使用已完成的活动和低 kb 图像获取 OutofMemoryError/InvocationTargetException?
【发布时间】:2013-09-23 20:58:51
【问题描述】:

基本上我的应用程序一直在崩溃。但是,我所有的活动都有'finish();',它应该结束活动并释放内存(至少这是我的理解)。同样,我的图像只有几百 KB,以 PNG 格式保存。

我的代码至少在 Java 包资源管理器中没有立即出现错误。在 DDMS 中,我得到标题中列出的错误。按照这里的问题和答案,我遵循了我的项目最合乎逻辑的步骤,但它没有奏效。到目前为止,我已经检查了图像大小(文件大小很小)并且我添加了 finish();到我的活动。

基本上我进行了大约 10 个活动,然后它就崩溃了。我总共有大约 60 个活动,每个活动都有一个图像、图像按钮和一个滚动文本视图。有些人偶尔会在屏幕上显示一个图像,该图像会暂停并继续下一个活动。我会发布代码,但没有一页代码是立即相关的——或者至少我可以解析。

至于 AVD,它只是一款 SD 卡内存较低的中档产品,但是,即使在中高档的真实设备上,该应用也存在同样的问题。

感谢任何帮助!

【问题讨论】:

  • 使用 Fragments 会更适合您的情况吗?它们会根据需要加载和卸载。
  • 如果您不需要将某些活动保留在后台堆栈中,请考虑在启动新意图后对其调用 finish()。
  • 如果问题确实是真正的泄漏,请使用 MAT 确定内存泄漏所在的位置。除此之外,您可能会考虑编辑您的问题以澄清您的图像来自哪里(资源?本地文件?从 Internet 上即时下载?)。
  • “我的图像只有几百 KB,以 PNG 格式保存。” - 请注意,文件大小与内存要求几乎不相关。在运行时,Android 会将每个图像解码为Bitmap,通常为 32 位/像素(= 4 字节/像素)。因此,一个 512 x 512 像素的图像将需要 1 MB 的 mdpi 内存。 xhdpi 上的相同图像将在两个维度上缩放 2 倍,因此需要 4 MB。简而言之:像素大小将决定内存分配,而不是文件大小。
  • 为关于位到像素转换的解释干杯,它进一步加深了我的理解!

标签: android memory memory-leaks android-activity invocationtargetexception


【解决方案1】:

我经常看到这种行为很安静,首先让我告诉你,完成一项活动并不一定意味着操作系统会释放资源,操作系统足够聪明,可以留下一些资源,以防你可能决定再次打开该活动,即使您之前已销毁该活动,现在当您打开更多活动时,操作系统可能会决定完全释放以前“已销毁”活动的一些资源,因为它可能需要这些资源用于最新活动。

关于您的内存问题,我几乎可以肯定它与图像大小调整机制有关,即使您的应用程序的图像只有几 KB,如果没有将这些图像存储在正确的可绘制文件夹中,这些图像可能会变成几 MB ,因为操作系统会尝试使用以下公式调整这些图像的大小以适合您的活动:ImageWidth * ImageHeight * 4Bytes,Alpha/R/G/B 为 1Byte,并且在 DDMS 中通过跟踪堆,您可以注意到何时你去一个活动堆增加得非常快。

为了确保问题与调整大小机制无关,如果您发现性能存在巨大差异,请将所有可绘制对象放在一个名为 drawable-nodpi 的文件夹中(这样您就可以告诉操作系统不要调整大小)那么这意味着问题在于您的可绘制对象在每个屏幕密度的大小上都没有正确设计......

希望这会有所帮助。

问候!

【讨论】:

  • 感谢您提供如此详细的回答!现在有点晚了,但我明天第一件事就会开始并发布结果。很有道理,非常感谢!
  • 非常感谢这篇文章!经过进一步的混乱,它解决了我的问题。基本上我将像素高度降低到大约 500 并将它们全部保存在 nodpi 文件夹中,一切都快如闪电,没有任何崩溃或内存泄漏。感谢您如此快速有效地分享您的经验!
  • 呵呵呵呵,没问题,请记住始终根据android指南正确设计资产,这可以为您省去很多麻烦...问候...
猜你喜欢
  • 2014-12-17
  • 2018-12-28
  • 2017-01-16
  • 1970-01-01
  • 2011-07-26
  • 1970-01-01
  • 2014-02-24
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多