html5画布应用程序中的JavaScript base64图像源内存管理

让我们直接了解代码：

function drawImg(img) {                       
    var image = new Image();
    image.onload = function() {                                     
        context.drawImage(image, 0, 0);
    }; 
    image.src = img; 
}; 

这是将图像绘制到html5画布上下文的一个非常常见的基本实现

传递给drawImg函数img的值是base64字符串，类似于

"data:image/png;base64,somebase64stuffhere...."

现在让我们假设drawImg每秒被调用15次（15fps），base64编码的img的大小是20-30k

FireFox和InternetExplorer的10,11表现足够好。FF上的GC和内存峰值有点疯狂，但在可接受的范围内。IE的早期版本，最令人沮丧的是chrome，无法管理图像对象的内存分配，并且在短时间内将消耗所有可用内存并崩溃

• 我已经注释掉了这段代码的画布部分
• 我已经注释掉了代码的整个部分，以检查drawImg函数之外的内存泄漏
• 我的结论是，image、image.onload、image.src代码位导致了崩溃的内存增长
• 这里类似的问题证实了这一想法，但我还无法验证针对我的具体案例的任何解决方案

因此，我的问题是：在某些浏览器中，如何在不消耗内存的情况下最好地实现此功能？

注意事项：

• 我不希望偏离获取base64字符串的概念太远，在任何时候我都不会向文件系统写入内容，也不希望以这种方式保存它
• 我没有自由简单地刷新页面

---

这似乎是Chrome的一个众所周知的问题：

在TC中仍然会观察到增长，但大部分应该是这样的 由于GC启发，因此最终将被收集，保留 内存使用受限

截至1月21日：

最新的开发人员现在应该已经安装了它。（我想是34.0.1788.0）

---

版本34目前是金丝雀。

我发现在类似的东西中内存使用要低得多，保存画布历史快照。使用dataURL，ram的速度非常快，但当我尝试简单地克隆绘制的画布元素并隐藏旧的元素时，一切又变得非常快。您可能只需循环池图像标记，其速度比泵送base64数据快得多，而且没有图像解码等功能。为什么每次要绘制图像时都要加载图像？只需在全局范围或父范围内加载一次，然后重新使用它。@ken图像数据每帧都不同，我在全局范围内加载了var图像，看起来差别不大。我的大部分研究表明，当src变化如此之快时，一些浏览器无法取消对它的引用。@dandavis谢谢，我曾试图想出一种实现dataURL的方法，但也许现在我可以避免这种情况。我只有base64数据可以使用，它是通过WebSocket从远程位置推送到浏览器的。注意，已经排除了websocket连接和传输作为泄漏源的可能性，它在该图像中最明显。src@tremor是唯一的图像15*∞? 看看这个例子，它可能与你正在做的事情有很大的不同，但可能会激发一些想法：这可能是Chrome，我需要重新测试IE的旧版本，将我的图像标签更改为评论中建议的全局范围。我目前的Chrome是32，所以我将进入开发频道并尝试一下。