我正在编写一个图片库应用程序，并且我一直遇到内存不足错误。我缓存了所有图像但是当我尝试在图像非常快之间切换时会出现问题。我假设应用程序分配的内存比GC有时间释放它们更快（因为当我慢慢切换图像时不会发生崩溃）。
在对这个问题进行了几天的敲击之后，我终于决定尝试在清单文件中提供largeHeap设置。在此设置之后，无论我在图像之间切换多快，我的应用程序都不会崩溃。
现在，我想知道是否有任何使用largeHeap设置的约定或一般指导原则，因为如果使用注释应用程序使用largeHeap可能没有多大意义。一般来说，哪些应用程序适合largeHeap设置？
由于
答案 0 :(得分：23)
一般来说，哪些应用程序适合largeHeap设置？
你可以向用户证明 的原因为什么你强迫所有其他应用程序没有内存，为你提供大量的堆空间。
就个人而言，我不认为“图片库应用程序”符合资格。 AutoCAD，视频编辑器等都符合条件。
关于内存管理问题，请确保在API Level 11+上运行时在inBitmap上使用BitmapOptions，因此您可以回收现有缓冲区而不是通过垃圾回收。特别是对于图像库，您可能有很多相当一致的缩略图大小，回收现有的缓冲区将是一个巨大的好处。这可以帮助整体内存消耗（即，你真的内存不足）和内存碎片（即，你得到一个有足够堆空间的OutOfMemoryError，但没有足够大的单个块来分配，因为Android的frakkin'非压实垃圾收集器）。
您也可以考虑查看现有的图像缓存实现，例如Picasso具有的实现，以查看是否有一些您可以学习的技巧（或者可能只是重用）。
答案 1 :(得分：1)
首先，确保您没有加载比必要更大的位图：
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时，请大量使用你的应用程序 - 是否有现在“更缓慢”的地方，或动画“口吃”或其他方面看起来不那么顺畅？确保在至少一个较旧的设备和一个高分辨率设备上进行测试。
由于堆较大，您可能会看到GC时间过长。
或者你可以得出结论largeHeap对你有用，现在你可以自信地说它是你情况下的最佳选择。