BitmapFactory OOM 让我抓狂

Question

我做了很多搜索并且认识了很多人 BitmapFactory 也遇到同样的 OOM 内存问题。我的 使用 Runtime.getRuntime 应用程序仅显示 4MB 的可用总内存 ().totalMemory()。如果限制是 16MB，那么为什么总数不 内存增长以便为位图腾出空间？相反，它会抛出错误。

我也不明白如果我有 1.6MB 的可用内存 到 Runtime.getRuntime().freeMemory() 为什么我会收到错误消息“VM 不会让我们分配 614400 字节”？在我看来我有足够的 可用内存。

我的应用程序是完整的，除了这个问题，当我 重新启动手机，以便我的应用程序是唯一运行的。我正在使用 用于设备测试的 HTC Hero (Android 1.5)。

在这一点上，我认为解决这个问题的唯一方法就是以某种方式 避免使用 BitmapFactory。

任何人对此有任何想法或解释为什么 VM 不会 当有 1.6MB 空闲内存时分配 614KB？

Answer 1

[请注意（正如 CommonsWare 下面指出的那样）此答案中的整个方法仅适用于 2.3.x（Gingerbread）及包括 2.3.x（Gingerbread）。从 Honeycomb 开始，位图数据分配在 VM 堆中。]

位图数据未分配在 VM 堆中。 VM 堆（很小）中有对它的引用，但实际数据是由底层 Skia 图形库在 Native 堆中分配的。

不幸的是，虽然 BitmapFactory.decode...() 的定义表明，如果图像数据无法解码，它会返回 null，但 Skia 实现（或者更确切地说，Java 代码和 Skia 之间的 JNI 粘合）会记录您正在处理的消息看到（“VM 不会让我们分配 xxxx 字节”），然后抛出 OutOfMemory 异常，并带有误导性消息“位图大小超出 VM 预算”。

问题不在于 VM 堆，而在于 Native 堆。本机堆在正在运行的应用程序之间共享，因此可用空间量取决于正在运行的其他应用程序及其位图使用情况。但是，鉴于 BitmapFactory 不会返回，您需要一种方法来确定调用是否会在调用之前成功。

有一些例程可以监视 Native 堆的大小（请参阅 Debug 类的 getNative 方法）。但是，我发现 getNativeHeapFreeSize() 和 getNativeHeapSize() 并不可靠。因此，在我的一个动态创建大量位图的应用程序中，我执行以下操作。

本机堆大小因平台而异。因此，在启动时，我们检查允许的最大 VM 堆大小，以确定允许的最大本机堆大小。 [幻数是通过 2.1 和 2.2 上的测试确定的，在其他 API 级别上可能有所不同。]

long mMaxVmHeap     = Runtime.getRuntime().maxMemory()/1024;
long mMaxNativeHeap = 16*1024;
if (mMaxVmHeap == 16*1024)
     mMaxNativeHeap = 16*1024;
else if (mMaxVmHeap == 24*1024)
     mMaxNativeHeap = 24*1024;
else
    Log.w(TAG, "Unrecognized VM heap size = " + mMaxVmHeap);

然后每次我们需要调用 BitmapFactory 时，我们都会在调用之前检查表单。

long sizeReqd        = bitmapWidth * bitmapHeight * targetBpp  / 8;
long allocNativeHeap = Debug.getNativeHeapAllocatedSize();
if ((sizeReqd + allocNativeHeap + heapPad) >= mMaxNativeHeap)
{
    // Do not call BitmapFactory…
}

请注意，heapPad 是一个幻数，它允许以下事实：a) 本机堆大小的报告是“软”的；b) 我们希望在本机堆中为其他应用程序留出一些空间。目前我们正在使用 3*1024*1024（即 3Mbytes）的 pad 运行。

Answer 2

1.6 MB 的内存看起来很多，但也可能是内存碎片严重，无法一次性分配这么大的内存块（这听起来确实很奇怪）。

使用图像资源时出现 OOM 的常见原因之一是解压缩具有非常高分辨率的 JPG、PNG、GIF 图像。您需要记住，所有这些格式都经过很好的压缩，占用的空间非常小，但是一旦您将图像加载到手机上，它们将使用的内存类似于 width * height * 4 字节。此外，当解压缩开始时，需要加载一些其他辅助数据结构以用于解码步骤。

Answer 3

似乎 Torid 的回答中给出的问题已在最新版本的 Android 中得到解决。

但是，如果您使用图像缓存（专用的缓存，甚至只是常规的 HashMap），则很容易通过创建内存泄漏来获得此错误。

根据我的经验，如果您无意中保留了您的位图引用并创建内存泄漏，OP的错误（参考BitmapFactory 和本机方法）会导致您的应用程序崩溃（最高可达 ICS - 14 和 +？）

为了避免这种情况，请让您“放开”您的位图。这意味着在缓存的最后一层使用软引用，以便位图可以从中收集垃圾。这应该可行，但如果您仍然遇到崩溃，您可以尝试使用 bitmap.recycle()，请记住，如果 < a href="http://developer.android.com/reference/android/graphics/Bitmap.html#isRecycled%28%29" rel="nofollow noreferrer">bitmap.isRecycled()。

顺便说一句，LinkedHashMaps 是一个很好的工具，可以轻松实现相当好的缓存结构，特别是当您像 这个示例（从第 308 行开始）...但是使用硬如果你搞砸了，引用也是让你陷入内存泄漏情况的方法。

Answer 4

虽然捕获错误通常没有意义，因为通常它们仅由 vm 抛出，但在这种特殊情况下，错误是由 jni 粘合代码抛出的，因此处理无法加载图像的情况非常简单：只需捕获 OutOfMemoryError。

Answer 5

虽然这是一个相当高水平的答案，但对我来说问题是在我的所有视图上使用硬件加速。我的大多数视图都有自定义位图操作，我认为这是大型本机堆大小的来源，但事实上，当禁用硬件加速时，本机堆使用量减少了 4 倍。

似乎硬件加速会对视图进行各种缓存，创建自己的位图，并且由于所有位图共享本机堆，因此分配大小可能会显着增长。