folks，我不认为这是重复的，并且不是我如何避免 ooms 问题之一。这是对知识的真正追求
想象我有500x500像素的JPEG。我将其加载为ARGB_8888，为" bad as it gets"。
我希望Android能够分配500x500x4 bytes = a little under 1MB，但是，请看 HEAP DUMP ，您会发现Android分配得更多，通常是5-10倍的因素。
您经常在此处看到有关 ooms 的问题，其中 stack Trace 显示heap request of say 15MB，并且它是始终比仅需要大得多的按住图像的字节。OP通常会捕获一些下跌投票，然后轰炸有关使用较少内存（感谢Romain！）和缩放的股票答案和评论。我认为这里有更多的眼睛。
有人知道为什么这是？
如果没有明显的答案，我将把 sscce 放在一起。
ps。我认为jpeg vs png等是无关紧要的，因为我们谈论的是衬板位图的记忆使用情况，这只是x times y times y times bpp-还是我很慢？
它曾经是内存管理的一个常见技巧，可以抓住一个池或内存块，该记忆被包裹在较小的请求中。当我使用嵌入式系统时，维护不同尺寸的内存池是一种常见的做法，而我们只是分配了一个比池中要求的数量大的块。这是防止过多记忆力碎片的方便方法。也许这是在这里发生的。