xhr blob responseType(Chrome)的内存使用情况

时间:2013-05-30 21:44:46

标签: google-chrome memory-management xmlhttprequest blob

使用谷歌浏览器,假设我使用ajax将文件下载为blob,如下所示:

var xhr = new XMLHttpRequest();
xhr.open('GET', 'some/path', true);
xhr.responseType = 'blob';

xhr.onload = function(e) {      
    //Save xhr.response using FileSystem API
};

xhr.send();

我是否需要担心内存使用(假设下载的文件可能非常大,或者我可能会以这种方式下载大量文件)?

我的理解是,由于我指定的响应类型为'blob'而不是'arraybuffer',因此下载的数据不会被加载到Javascript可用的内存中。但是,下载的数据必须存储在某处。它只是存储在内存中,还是浏览器会在必要时将其置于某种内存缓存中?如果它被保存在内存中,那么在我完成它之后有没有办法让我处理它(例如,在我的例子中,一旦我使用FileSystem API保存它)。

4 个答案:

答案 0 :(得分:1)

我想它也归于记忆。我记得一些关于镀铬能够处理800 MB ram的东西,某处不确定。

但我对~1 GB的电影进行了测试,并查看了网络标签。最正确的是,当我看到~760 MB的基准测试时,它崩溃了。因此,您最好的选择是请求块并将其附加到文件系统

答案 1 :(得分:0)

我无法回答您关于数据存储位置的具体问题,但我认为它会转移到磁盘上的内存中。

我可以回答的部分是如何释放blob对象本身使用的内存(不一定是数据,只是blob对象)。只要您未在当前范围内使用该对象或范围已结束,它将自动清除。例如,在闭包或匿名函数内部,当函数结束时,在该作用域中创建的任何内容都将被垃圾回收。您也可以手动将其指定为null或调用delete。

您应该从MDN上了解delete operator。 MDN上还有memory management page,可以更详细地解释上述过程。

答案 2 :(得分:0)

数据始终存储在nsCString中的内存中,该nsCString通过加倍动态增长。因此260 MB文件可以保存高达~512 MB的内存。如果要将响应数据复制到arraybuffer中,内存峰值最多可增加到772 MB,因为还需要分配阵列缓冲区(260MB)。

只要XHR对象存在,临时512 MB nsCString就会保留。所以你必须设置xhr = null,以进行垃圾收集并释放内存。当然,许多移动系统没有太多可用内存,并且可能因“内存不足”而崩溃。某些浏览器版本每个选项卡的内存限制,并且在内存使用量为768MB时崩溃。

那里有一个新的Fetch-API,允许基于块的阅读。流响应主体可以提高内存使用率。在XHR中,整个响应将被缓冲,而不是能够以块的形式操作数据。

答案 3 :(得分:0)

对于二进制或Blob数据,Chrome使用复杂的系统,该系统由用于标签的内存缓冲区和异步全局存储逻辑组成,该逻辑还将数据交换到磁盘。选项卡内存,全局存储容量以及重要的是在两者之间传输数据和交换数据的速度受到限制。

这与可用的JavaScript内存不同,后者可保存您的代码和常规变量。

无法确切知道这些限制是什么,但是创建Blob的速度起着至关重要的作用。将此类操作减慢到慢速磁盘的速度,可以极大地增加应用程序可用的内存。

有关Chrome Blob存储的说明,请参见以下网址: https://chromium.googlesource.com/chromium/src/+/master/storage/browser/blob/README.md

要回答您的问题:是的,您需要担心那里的内存。如果您一口气在XHR请求中加载的数据大于可用的选项卡内存,则选项卡将崩溃。同样,如果您随着时间的推移而超出了全局存储容量,或者加载得太快,则许多较小的文件也将遇到问题。