我在 android 3.1 上测试，大堆大小选项，大约 250M 可用内存。
我将以下代码设置为在我点击应用首选项中的测试按钮时运行:
float [][][]foo = new float[3][2048][2048];
Bitmap bm = Bitmap.createBitmap(2048, 2048, Bitmap.Config.ARGB_8888);
bm.recycle();
bm = null;
foo = null;
我有足够的内存力——我可以按几次按钮没有问题。
但如果我继续按下按钮，最终(少于 20 次点击)它会因 OutOfMemory 而死。 [通常在android.graphics.Bitmap.nativeCreate(Native Method)]
没有其他事情发生——我永远不必离开 PreferencesActivity。当我点击按钮时，还会显示一个小的 Toast，因此正在进行少量其他 UI Activity 。
这是由于 fragment ，还是只是 android Bitmap 代码和/或 GC 中的一个可怕的错误？还是我只是在做一些愚蠢的事情？ (请让它变得愚蠢......)
有人有解决方法吗？因为上面的内容相当代表了我的代码在每次用户调用它时必须执行的操作，而现在尽管仔细清除了变量，但它在几次使用后就死了。 (这已经让我发疯了很长时间了!)
[更新]
我已经确认这是一个 fragment 问题或 gc 错误，因为堆转储显示我只使用了 5.6M，而空闲(无泄漏)在处理期间达到了大约 26M 的峰值。 (此外， native 堆保持在 4M 以下。)与此同时，Java 堆的范围一直增长到我的测试设备上的 280M 限制，此时我开始收到 OutOfMemory 异常。所以我在高峰期只使用了 10% 的可用堆，但是却出现了 OutOfMemory。
[不幸的是，添加对 System.gc() 的调用修复了我上面给出的简单测试用例。我说不幸是因为(A)它不应该有什么不同，(B)因为我已经在我的真实代码中定期调用它，所以这意味着我上面的简单测试用例太简单了。]
还有其他人遇到过这种情况吗？任何解决方法？有没有优雅的方式来重启我的应用？
[更新]
以下版本在 3 到 4 次调用(按下按钮)中可靠地导致 OutOfMemory:
float [][][]foo = new float[3][2048][2048];
Bitmap bm = Bitmap.createBitmap(2048, 2048, Bitmap.Config.ARGB_8888);
int []bar = new int[3*2048*2048];
bm.recycle();
bm = null;
System.gc();
foo = null;
System.gc();
bar = null;
System.gc();
内存跟踪显示堆在每次调用时稳定增长，直到达到限制并死亡。如果我删除三个分配中的任何一个，它就会达到平衡并无限期地存在。删除除最后一个 gc() 之外的所有内容会导致它稍早死亡。
我会说这是一个 fragment 问题，而不是 gc 错误本身。如果有人知道如何解决它，请告诉我。 int[] 分配用于编写 Bitmap，因此我没有将其分配为 2d 数组的选项(android Bitmap 库的限制)。
最佳答案
这是另一个显然有解决此问题的方法的 SO 页面:
Strange out of memory issue while loading an image to a Bitmap object
具体来说，以法莲的回答(摘录):
"1) 每次执行 BitmapFactory.decodeXYZ() 时，请确保传入 BitmapFactory.Options 并将 inPurgeable 设置为 true(最好将 inInputShareable 也设置为 true)。
"2) 永远不要使用 Bitmap.createBitmap(width, height, Config.ARGB_8888)。我的意思是永远不要!我从来没有让那东西在几次通过后不会引发内存错误。没有多少 recycle(), System.gc ()，不管有什么帮助。它总是引发异常。另一种实际可行的方法是在您的可绘制对象(或您使用上面的步骤 1 解码的另一个位图)中有一个虚拟图像，将其重新缩放为您想要的任何内容，然后操作生成的位图(例如将其传递给 Canvas 以获得更多乐趣)。因此，您应该使用的是:Bitmap.createScaledBitmap(srcBitmap, width, height, false)。如果出于任何原因，您必须使用蛮力创建方法，那么至少通过 Config.ARGB_4444。”
在评论中，有人说这解决了他们的问题，这与这里的OP非常相似。
我要补充一点，Diane Hackborn 评论说，从 3.0 开始，Android 不再从 native 堆分配位图，而是直接从常规堆分配它们。这可能会使您的 native 堆数据无关紧要。查看 hackbod 在此页面上的评论:
我想这意味着 Honeycomb 在位图分配方面发生了相当大的变化，因此这可以解释为什么这种分配存在错误(如果有的话)。我不知道此更改对 recycle() 命令有什么影响，但根据 Ephraim 的上述评论，答案可能是“不是一个很好的答案”。
最后，
使用 largeHeap 摄取巨大的位图可能会被视为与其他应用程序不兼容，尤其是当您接近设备的物理限制时。我不确定如何避免这种情况，但是当您的应用程序踩到其他应用程序时，请为大量的 onPause()/onResume() Activity 做好准备，而他们又会退回到您的应用程序。这个 SO 答案包括对此的讨论:
关于Android GC 内存 fragment 失败。解决方法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10682049/