读取音频文件时出现大量内存峰值

Question

我目前正在使用狄拉克的(OSStatus) readFloatsConsecutive:(SInt64)numFrames intoArray:(float**)audio函数从文件中读取音频浮点数。我创建一个浮点指针**

arrayToFill = malloc(channelCount * sizeof(float*));
for(int i = 0; i < channelCount; ++i)
{
    arrayToFill[i] = malloc(frameCount * sizeof(float));
}

并将其传递给狄拉克函数 当所有浮点数都错位时，我得到了一个巨大的内存峰值。

在

仪器中，我得到的峰值增加了大约 90MB，由于某种原因，这个应用程序仍然在设备上运行。

例如15839544 * 2 个浮点数会导致这些巨大的峰值吗？

它怎么能使用这么多内存？是虚拟内存吗？我没有看到任何 VM 分配。

我不明白加载单个文件（例如 5MB 音频文件）如何导致内存出现如此巨大的峰值。

Answer 1

例如，15839544 * 2 个浮点数会导致这些巨大的峰值吗？

是的，绝对。浮点数为 4 个字节，因此两个 1580 万个浮点数的数组总共约为 120 MB。

至于你如何从一个5 MB的输入文件中得到这个： 音频压缩是一件了不起的事情。 :)

Answer 2

它可能是虚拟内存 - 尽管不是通常（错误）理解的方式。

虚拟内存是映射到进程中的可用地址空间。它可能会也可能不会使用内存的物理页进行备份。

访问未如此备份的页面会导致页面错误，然后内核以多种方式之一提供服务：

• 分配新的清零页面
• 分配页面并用内存映射文件的页面填充其内容
• 分配页面并从页面文件中填充其内容
• 不执行上述任何操作并终止应用程序

因此，当操作系统有足够的 RAM 来分配页面描述符以将虚拟空间映射到进程中时，大量内存（大于可用物理页）的malloc()往往会成功（尽管如果此时超出资源限制，它可能会下降）。 尝试实际写入分配的空间会逐渐将物理页面拉入该过程。

您指示的大小实际上是~128MB内存。 在iDevice上玩这么多物理RAM的可能性很小，所以我认为我们可以假设它并没有全部被使用。 您可能会获得页面错误数量的统计信息 - 这将使您对使用的数量有一个很好的了解（大概是每页 4kB）。

我希望您的进程的 VM 统计信息包含此分配。