.net - .NET 图像类的内存使用和碎片 : Bitmap vs. 元文件

Question

由于看似过早的内存不足异常，我们一直在仔细检查各种 .NET 结构的内存使用情况……尤其是大型对象，它们往往会使大对象堆碎片化，从而导致过早的内存不足异常。一个有点令人惊讶的领域是 .NET 图像类:位图和元文件。

以下是我们认为我们已经了解的内容，但无法找到 MS 文档进行验证，因此如果其他人可以提供任何确认，我们将不胜感激:

(1) 当您从压缩的光栅文件(JPG、PNG、GIF 等)创建位图对象时，它会在该文件的全分辨率下为完全未压缩的像素阵列消耗内存。因此，例如，一个 9000x3000 像素的 5MB JPG 将被扩展为 9000x3000x3 字节(假设 24 位颜色，无 alpha)，或消耗 81MB 内存。对吗？

(1a) 有一些证据(参见下面的 2b)表明它还存储原始压缩格式……因此，在这种情况下实际上是 86MB。但这还不清楚……有人知道吗？

(2) 当您创建一个 Metafile 对象，然后在其中绘制一个光栅文件(JPG、PNG、GIF 等)时，它只会消耗压缩文件的内存。因此，如果您将 9000x3000 像素的 5MB JPG 绘制到 Metafile 中，它只会消耗大约 5MB 的内存。对吗？

(2a) 要将光栅文件绘制到 Metafile 对象中，唯一的方法似乎是使用文件加载 Bitmap，然后将 Bitmap 绘制到 Metafile 中。有没有更好的方法不涉及临时加载庞大的位图数据(并导致相关的内存碎片)？

(2b) 当您将位图绘制到元文件中时，它使用大小类似于原始压缩文件的压缩格式。它是否通过将原始压缩文件存储在位图中来做到这一点？还是通过使用原始压缩设置重新压缩展开的位图来做到这一点？

(3) 我们最初假设大 (>85KB) 图像对象将被放置在大对象堆中。事实上，情况似乎并非如此。相反，每个位图和每个元文件都是小对象堆中的一个 24 字节对象，它指的是包含真实数据的 native 内存块。对吗？

(3a) 我们假设这样的 Native Memory 就像 Large Object Heap 一样，不能被压缩……一旦大对象放入 Native Memory，它就永远不会被移动，因此 Native Memory 的碎片会导致大对象堆的碎片化问题很多。真的？或者是否对底层位图/元文件数据进行特殊处理更有效？

(3b) 因此，似乎有四个独立的内存块分别管理，每个内存块用完都会导致相同的内存不足异常:小对象堆(托管对象 < 85KB，由 GC 压缩) )、大型对象堆(由 GC 收集的大于 85KB 的托管对象，但未压缩)、 native 内存(非托管对象，可能未压缩)和桌面堆(管理窗口句柄和此类有限资源)。我是否正确记录了这四个？还有其他我们应该注意的吗？

任何人都可以就上述内容提供的任何清晰度将不胜感激。如果有很好的书或文章可以充分解释上述内容，请告诉我。 (我很高兴完成必读；但绝大多数书籍都没有那么深，因此不要告诉我任何我不知道的东西。)

谢谢!

Answer 1

有两种存储图像数据的方法:像素或向量。 Bitmap 是关于像素的，Metafile 是关于像素和向量的。矢量数据的存储效率要高得多。

为了允许对位图进行操作，它们的数据必须未压缩地存储在内存中。否则 GetPixel 和 SetPixel 将不得不为每次更改解压缩、更改、重新压缩位图(如果这甚至可以开始的话)。

Metafiles由 Microsoft 创建并旨在与 GDI 一起使用，因此它可能包含一些内存效率更高的压缩算法，这些算法直接与显卡一起使用。此外，元文件没有 GetPixel SetPixel 方法，因此不必在内存中解压缩以进行操作。

---

您不必关心运行时使用的内存池。还有更多，运行时决定它放置对象的位置。此外，您不应该关心可能可能因使用(大)对象而引起的内存不足异常。运行时将尽其所能(将对象放在其他对象之间的间隙中，压缩堆，扩展可用的虚拟内存)以确保您不会遇到内存不足的异常。如果您确实遇到了这样的异常，那么您的代码中可能还有另一个问题需要修复(例如内存泄漏)。

内存堆、映射和表的概述:( source )

---

此外，您关于将超过 85 KiB 的对象放置在大对象堆上的假设并不完全正确。对于 当前 版本的 CLR 中的 大多数 对象是正确的，但例如在大对象堆上也分配了一个 8 KiB 的 double 组(1000 个 double )。让运行时自己关心这个。