javascript - 有没有办法阻止 Web Audio API decodeAudioData 方法内存泄漏？

Question

问题

当使用 Web Audio API 创建音频缓冲区时，会存在由 decodeAudioData 方法创建的缓冲区，这些缓冲区驻留在内存中，显然无法通过 JavaScript 访问。它们似乎在浏览器选项卡的整个生命周期中都存在，并且永远不会被垃圾收集。

问题的可能原因

我知道这些缓冲区是从主线程中分离出来的，设置在另一个线程上进行异步解码。我也知道 API 规范说不应允许 decodeAudioData 对同一个输入缓冲区进行两次解码，我认为这就是为什么要保留解码缓冲区和/或编码输入缓冲区的副本的原因。但是，在 Chromecast 等内存有限的设备上，这会导致大量内存累积并导致 Chromecast 崩溃。

可重复性

在我的示例代码中，我使用 Ajax 获取 mp3，然后将 arraybuffer 传递给 decodeAudioData 函数。通常在该函数中有一个 onsuccess 回调，它可以将解码后的 AudioBuffer 作为参数。但是在我的代码中，我什至没有传入它。因此在解码后我也不对解码缓冲区做任何事情。我的代码中的任何地方都没有引用它。它完全留在 native 代码中。但是，每次调用此函数都会增加内存分配，并且永远不会释放。例如，在 Firefox 中，about:memory 显示选项卡生命周期内的音频缓冲区。非引用应该足以让垃圾收集器摆脱这些缓冲区。

那么我的主要问题是，是否有任何对这些解码音频缓冲区的引用，比如在 audiocontext 对象中，或者我可以尝试将它们从内存中删除的其他地方？还是有任何其他方法可以使这些已存储且无法访问的缓冲区消失？

我的问题与目前关于 decodeAudioData 的所有其他问题不同，因为我表明即使没有用户存储任何引用或什至不使用返回的解码音频缓冲区，内存泄漏也会发生。

重现代码

function loadBuffer() {
    // create an audio context
    var context = new (window.AudioContext || window.webkitAudioContext)();

    // fetch mp3 as an arraybuffer async
    var url = "beep.mp3";
    var request = new XMLHttpRequest();
    request.open("GET", url, true);
    request.responseType = "arraybuffer";

    request.onload = function () {

        context.decodeAudioData(
                request.response,
                function () {// not even passing buffer into this function as a parameter
                    console.log("just got tiny beep file and did nothing with it, and yet there are audio buffers in memory that never seem to be released or gc'd");
                },
                function (error) {
                    console.error('decodeAudioData error', error);
                }
        );
    };

    request.onerror = function () {
        console.log('error loading mp3');
    }
    request.send();
}

预测一些可能的响应。

1. 我必须使用网络音频 API，因为我在 Chromecast 上播放来自四个音频文件的四声部和声，而 html 音频元素不支持在 Chromecast 上同时播放多个。
2. 可能是您可能引用的任何 JS 库 [例如Howler.js、Tone.js、Amplitude.js 等] 是建立在 Web Audio API 之上的，因此它们都会共享这个内存泄漏问题。
3. 我知道 WAA 的实现取决于每个浏览器。我目前主要关心的是 Chromecast，但我尝试过的每个浏览器都存在这个问题。
4. 因此，我认为这是一个与规范相关的问题，规范需要非重复编码规则，因此实现者在浏览器级线程上保留缓冲区的副本，以便他们可以根据新的 xhr 输入检查它们。如果规范编写者碰巧读到了我的问题，是否没有办法让用户可以选择这种行为，并在他们愿意时选择退出，以防止移动和精简内存平台上的内部缓冲存储？
5. 我无法在任何 JS 对象中找到对这些缓冲区的任何引用。
6. 我知道我可以 audio_context.close() 然后希望对 audio_context 持有的所有资源进行垃圾回收，然后希望我可以用一个新资源重新实例化 audio_context，但根据经验，这还不够及时为我的申请。 Chromecast 在 GC 清除垃圾之前崩溃。

Answer 1

实用的解决方法

我找到了一种方法来解决 Web Audio API audiobuffers 无限期传递并导致 Chromecast 和其他移动平台崩溃的问题。 [[我没有在所有浏览器上测试过这个 - 你的里程可能会有所不同。 ]]

加载阶段

1. 在 iFrame 中使用 Web Audio API 加载文档。
2. 加载您的音频缓冲区并尽一切努力播放它们。

清理阶段

1. 在您引用的所有播放节点上调用 sourceNode.stop。
2. 调用 source.disconnect();在所有源节点上。
3. 调用 gainNode.disconnect();在所有增益节点上，这些源节点与之关联(以及您可能使用的任何其他类型的 WAA 节点具有断开连接方法)
4. 将所有引用的gainNodes和sourceNodes设置为null；
5. 清空您引用的所有缓冲区，包括解码的和 xhr 提取的编码音频缓冲区；
6. 关键:在 WAA 页面中调用 audio_context.close()；然后设置 audio_context=null； (这可以使用 contentWindow 从 iFrame 的父级完成)。
7. 注意:其中一些归零步骤可能不是绝对必要的，但这种方法对我很有效。

重新加载阶段

1. 从父页面重新加载 iframe。这将导致所有音频缓冲区在下一轮 GC 中被垃圾收集，包括隐藏(非 JS)内存区域中的音频缓冲区。
2. 您的 iframe 必须重新实例化网络音频上下文并加载其缓冲区并创建节点等，就像您第一次加载它时所做的那样。

注意:您必须决定何时使用此清除方法(例如，在加载并播放了如此多的缓冲区之后)。您可以在没有 iframe 的情况下执行此操作，但您可能必须重新加载页面一次或两次才能触发垃圾收集。对于那些需要在 Chromecast 或其他移动设备等内存精简平台上加载大量 Web Audio API 音频缓冲区的人来说，这是一种实用的解决方法。

来自 parent

  function hack_memory_management() {
                var frame_player = document.getElementById("castFrame");
                //sample is the object which holds an audio_context
               frame_player.contentWindow.sample.clearBuffers();
                 setTimeout(function () {
                    frame_player.contentWindow.location.reload();
                }, 1000);
            }

在 WAA 框架内

CrossfadeSample.prototype.clearBuffers = function () {
    console.log("CLEARING ALL BUFFERS -IT'S UP TO GC NOW'");
    // I have four of each thing because I am doing four part harmony

    // these are the decoded audiobuffers used to be passed to the source nodes
    this.soprano = null;
    this.alto = null;
    this.tenor = null;
    this.bass = null;
    if (this.ctl1) {

        //these are the control handles which hold a source node and gain node 
        var offName = 'stop';
        this.ctl1.source[offName](0);
        this.ctl2.source[offName](0);
        this.ctl3.source[offName](0);
        this.ctl4.source[offName](0);

        // MAX GARGABE COLLECTION PARANOIA

        //disconnect all source nodes
        this.ctl1.source.disconnect();
        this.ctl2.source.disconnect();
        this.ctl3.source.disconnect();
        this.ctl4.source.disconnect();

        //disconnect all gain nodes
        this.ctl1.gainNode.disconnect();
        this.ctl2.gainNode.disconnect();
        this.ctl3.gainNode.disconnect();
        this.ctl4.gainNode.disconnect();

        // null out all source and gain nodes
        this.ctl1.source = null;
        this.ctl2.source = null;
        this.ctl3.source = null;
        this.ctl4.source = null;

        this.ctl1.gainNode = null;
        this.ctl2.gainNode = null;
        this.ctl3.gainNode = null;
        this.ctl4.gainNode = null;
    }

    // null out the controls
    this.ctl1 = null;
    this.ctl2 = null;
    this.ctl3 = null;
    this.ctl4 = null;

    // close the audio context
    if (this.audio_context) {
        this.audio_context.close();
    }
    // null the audio context
    this.audio_context = null;

};

更新:

可悲的是，即使这样也不能可靠地工作，并且 Chromecast 仍然会在一些清晰且加载新 mp3 的情况下崩溃。请参阅本页其他地方的“我目前的解决方案”。