从解码的音频流中清理内存的正确方法（移动）答案

【问题标题】：Proper way to clean up memory from decoded audio stream (mobile)从解码的音频流中清理内存的正确方法（移动）
【发布时间】：2017-08-09 03:12:47
【问题描述】：

我正在使用 WebAudio 播放音乐曲目。首先我用

完全解码

self.ctx.decodeAudioData(xhr.response, function (buffer) {
    this.cache = buffer;
})

并将解码后的缓冲区保存到某个变量中，以备我需要开始播放时使用。

当我想切换音轨时，我正在清理音频节点

node.source.onended = function (value) {
    node.source = null;
};

和缓存：

this.cache = null;

并将下一曲目解码为相同的变量。

问题是，如果我多次切换曲目是快速连续的（例如 3-4 个 3 分钟的曲目），基于 iOS 的移动浏览器只会重新加载页面，因为看起来我正在为选项卡使用所有可用内存。虽然我只使用一个缓冲区变量，但我猜垃圾收集器不会释放我不再使用的音频缓冲区的内存。

对如何改进实施有任何想法吗？

【问题讨论】：

你确定你已经释放了每个对内存的引用，包括xhr对象？你能发一个minimal reproducible example 来展示这个问题吗？
例如 - 这可能是有问题的。主要是因为我需要创建单独的简约示例来显示问题。这不是你可以在飞行中做的。我今晚试试。
至于对内存的引用——我看到我们有 3 个：1. 缓存——我们正在清理它 2. node.source.buffer——我们不能直接清除缓冲区，但我们确实清除了 node.source 变量。所以它应该解决这个问题。 3. xhr 对象。请求在私有函数中完成，xhr.response 被传递给 self.ctx.decodeAudioData。我们需要对这种情况进行额外的清理吗？

【解决方案1】：

事实证明，问题出在垃圾收集器上。真正清理以前的内存最多需要 20-30 秒。所以对我有用的解决方案 - 我开始播放曲目并禁用切换到另一首曲目的能力 30 秒。内存清理一切的时间已经足够了。

【讨论】：