我正在编写一个图片库应用程序，但一直遇到内存不足的错误。我缓存了所有图像，但是当我尝试在图像之间切换时出现问题非常快。我假设应用程序分配内存的速度快于 GC 释放它们的时间（因为当我缓慢切换图像时不会发生崩溃）。
在解决这个问题几天后，我终于决定尝试在清单文件中设置 largeHeap。进行此设置后，无论我在图像之间切换多快，我的应用程序都不再崩溃。
现在，我想知道使用 largeHeap 设置是否有任何约定或一般准则，因为如果记笔记应用程序使用 largeHeap 可能没有多大意义。一般来说，哪些应用程序适合使用 largeHeap 设置？
谢谢
【问题讨论】：
bitmap.recycle();，那么该位图的大部分内存将立即被释放。 （当 GC 处理它时，剩下的只是一个小对象。）
一般来说，哪些应用适合设置 largeHeap？
您可以向用户证明为什么要强制他们所有其他应用程序内存不足的原因，以便为您提供超大的堆空间。
就个人而言，我不认为“图片库应用”符合条件。 AutoCAD、视频编辑器等都符合条件。
关于内存管理问题，请确保在 API 级别 11+ 上运行时在 BitmapOptions 上使用 inBitmap，以便回收现有缓冲区而不是进行垃圾收集。特别是对于图像库，您可能有很多相当一致的缩略图大小，回收现有缓冲区将是一个巨大的好处。这可以帮助整体内存消耗（即，您确实内存不足）和内存碎片（即，您得到一个具有大量堆空间的OutOfMemoryError，但由于Android的frakkin'，没有一个块足够大以供您分配非压缩垃圾收集器）。
您还可以考虑查看现有的图像缓存实现，例如 Picasso 的实现，看看是否有一些技巧可以学习（或者可能只是重复使用）。
【讨论】：
Bitmap 对象？等等。
首先，确保您加载的位图没有超出所需：
Load a Scaled Down Version into Memory。
然后，在尝试largeHeap之前，尝试自己快速释放内存：
如果您在确定不再使用位图后立即致电bitmap.recycle();，则该位图的大部分内存将立即释放。 （当 GC 处理它时，剩下的只是一个小对象。）
在较新的 Android 版本上，有一些替代方案（而不是 recycle）可能更有效：
Managing Bitmap Memory
就个人而言，我仍然经常使用recycle，特别是如果我可能正在加载不同尺寸的图像，所以不能reuse 现有的。此外，当更改为不同的片段或活动时，我发现将旧媒体的“卸载”与新媒体的“加载”分开编码更容易：
保留旧片段，所有旧位图我都recycle（然后，如果可以从静态字段访问，则设置为null）。
是否使用largeHeap 的经验法则是，在您尝试了减少内存使用的替代方法之后再考虑。
对您的应用进行编码，以便您可以将其再次关闭，然后继续运行。
例如，monitor your memory usage，以及在内存紧张时加载“按比例缩小”的位图。如果给定的图像不是他们设备的“视网膜”分辨率，用户真的会注意到吗？
或者，如果它是较旧、较慢的设备，largeHeap 是否会让您的应用感觉无响应/生涩？如果是这样，您能否进一步降低分辨率，或者一次显示更少的位图？
让您的应用在所有情况下都能运行， largeHeap [通过上述技术]。注意：您可以“强制测试”在紧张的内存上运行，方法是分配一些“虚拟”位图，并将对它们的引用保存在全局字段中，这样它们就不会被释放。
现在您可以评估权衡，因为它会影响您的应用：
当您打开largeHeap 时，请大量使用您的应用程序 - 是否存在现在“更迟钝”、动画“卡顿”或其他看起来不太流畅的地方？请务必在至少一台较旧的设备和一台 HIGH_RESOLUTION 设备上进行测试。
由于堆较大，您可能会看到较长的 GC 时间。
或者您可能会得出结论，largeHeap 非常适合您，现在您可以自信地说它是您所处环境的最佳选择。
【讨论】：