window.URL.revokeObjectURL（）不会立即释放内存（或根本不释放内存）？ [英] window.URL.revokeObjectURL() doesn't release memory immediately (or not at all)?

问题描述

我正在制作一个html界面，用Drag& amp ;;在服务器上上传图像。删除和多个选择文件。我想在将图片发送到服务器之前显示图片。所以我首先尝试使用 FileReader ，但我遇到了一些问题，例如这篇文章。所以我改变了方式，我决定在帖子中使用blob：url，就像ebidel推荐一样，使用 window.URL.createObjectURL（）和窗口。 URL.revokeObjectURL（）释放内存。

I'm making an html interface to upload images on a server with Drag & Drop and multiple selection files. I want to display the pictures before sending them to the server. So I first try to use FileReader but I have had some problems like in this post. so I change my way and I decided to use blob:url like ebidel recommands in the post, with window.URL.createObjectURL() and window.URL.revokeObjectURL() to release memory.

但是现在，我有另外一个问题，类似于这一个。我希望客户可以随时上传200张图片。但浏览器崩溃了，使用的ram非常高！所以我认为可能同时显示的图像太多了，我使用数组设置了一个等待文件队列的系统，以便每次只处理10个文件。但问题仍然存在。

But now, I've got another problem, wich is similar to this one. I want that a client could upload 200 images at time if he wants. But the browser crashed and the ram used was very high! So I thought that maybe too much images were displayed at the same time, and I set up a system with a waiting queue of files using an array, in order to treat only 10 files at time. But the problem still occurs.

在谷歌浏览器上，如果我检查 chrome：// blob-internals / 文件（通常已由 window.URL.revokeObjectURL（）发布）在延迟8秒后近似释放。在Firefox上我不确定，但似乎文件没有发布（我检查 about：memory - >图像）

On Google Chrome, if I check chrome://blob-internals/ the files (which are normally already released by window.URL.revokeObjectURL()) are released approximatively after a 8 seconds delay. On Firefox I'm not sure but it seems like if the files were not released (I check on about:memory -> images for that)

我的代码是坏的，还是独立于我的问题？是否有解决方案迫使导航员立即释放内存？如果它可以提供帮助，这是问题发生的JavaScript的一部分:(抱歉，我在这里给出了一个链接，因为新成员的图像垃圾邮件机制） http://www26.zippyshare.com/v/14195278/file.html 。

Is my code which is bad, or is it a problem independent of me? Is there a solution to force the navigators to release immediatelly the memory? If it can help, this is the part of JavaScripton wich the problems occurs: (Sorry but I give here a link because of the image spam mechanism for new members) http://www26.zippyshare.com/v/14195278/file.html.

编辑

这是一种自己的答案+对bennlich的答案（评论的文字太长）

我从user1835582的答案中了解到我确实可以删除Blob / File但是当浏览器需要图像时它会将它们保存在内存中（这是合乎逻辑的）。所以显示图像（许多和重）让我崩溃和事实的事实是这样的。减速，而不是 revokeObjectURL 方法。而且，每个浏览器都以自己的方式管理内存，导致不同的行为。以下是我得出这个结论的方法。

I understood from the answer of user1835582 that I could indeed remove the Blob/File but while the browser needs images it keeps them somewhere in memory (which is logical). So it's the fact to display images (many & heavy) that gave me crashes & slow downs, not the revokeObjectURL method. Moreover, each browser manages the memory by its own way, leading to different behaviors. Here is how I came to this conclusion.

首先，让我们试试 revokeObjectURL 效果很好，举个简单的例子使用 https://developer.mozilla.org/en的源代码-US /文档/ Using_files_from_web_applications＃Example.3A_Using_object_URLs_to_display_images 。
使用Chrome，您可以通过检查 chrome：// blob-internals / 或尝试将显示的图片打开到新标签中来验证Blob是否已被撤销是空白的。注意：要完全释放Blob引用，请添加 document.getElementById（fileElem）。value =。几年前我发布问题时，发布blob大约需要8秒钟，现在几乎是即时的（可能是由于Chrome和/或更好的电脑的改进）

First, let's try that revokeObjectURL works well, with a simple example using the source code of https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Example.3A_Using_object_URLs_to_display_images. Using Chrome you can verify that Blob are well revoked, by checking chrome://blob-internals/ or trying to open displayed images into a new tab that will be blank. Note : to fully release Blob references, add document.getElementById("fileElem").value = "". When I posted my question some years ago, it was about 8 seconds to release blob, now it's almost immediate (probably due to improvements in Chrome & / or to a better computer)

然后，进行充电测试的时间。我做了一百个每个约2.5 Mo的jpg。显示图像后，我滚动页面。 Chrome崩溃，Firefox速度很慢（未在其他浏览器上测试过）。但是，当我评论 li.appendChild（img）一切顺利，即使有大量的图像。这表明问题不是来自 revokeObjectURL 方法，该方法实际上可以正常工作，但是显示了大量繁重的图像。您还可以测试创建一个包含数百个重图像的简单html页面并滚动它=>相同结果（崩溃/减速）。

Then, time for a charge test. I did it with a hundred of jpg of ~2.5 Mo each. After that images have been displayed, I scrolled the page. Chrome crashed and Firefox was slow (not tested on others browsers). However, when I commented li.appendChild(img) all went well, even with a huge bunch of images. This shows that problems are not coming from revokeObjectURL method which in fact works properly, but from displaying lot of heavy images. You can also test to create a simple html page with hundreds of heavy images and scroll it => same result (crash / slow down).

最后要深入了解图像内存管理，在Firefox上有趣的是：内存。例如，我看到当窗口处于活动状态时，Firefox解压缩图像（图像 - >未压缩堆上升），而raw（图像 - >原始）总是稳定的（相对于加载的图像数量）。这里有关于内存管理的很好的讨论： http：// jeff.ecchi.ca/blog/2010/09/19/free-my-memory 。

Finally to look deeper about images memory management, it's interesting on Firefox to look into about:memory. For example I saw that when the window is active, Firefox uncompresses the images (images -> uncompressed-heap goes up), while raw (images -> raw) is always stable (relative to the the quantity of images loaded). There is a good discussion about memory management here : http://jeff.ecchi.ca/blog/2010/09/19/free-my-memory.

推荐答案

随着 window.URL.revokeObjectURL（）您只能获取 [Blob] 或 [File] 对象。您无法强制从内存中删除。

With window.URL.revokeObjectURL() you can only get [Blob] or [File] object. You can not force remove from memory.

注意。
浏览器尚未最终确定，并且可能会从这些设施泄漏。如果您实施动画，则必须自行承担风险。

Note. Browsers are not finalized and they can leak from these facilities. If you implement the animation, you have to understand that at your own risk.

这篇关于window.URL.revokeObjectURL（）不会立即释放内存（或根本不释放内存）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！