正确处置浏览器资源 [英] Properly disposing of browser resources
问题描述
我有一个Web应用程序，可以长时间动态地加载数据.数据中有指向图像的链接，这些图像然后在浏览器中呈现.
I have a web application which dynamically loads in data over a long period of time. Within the data there are links to images which are then rendered in the browser.
例如
var object = {
Name: ko.observable("Foo"),
Ref: ko.observable("Bar"),
ImageUrl: ko.observable("http://.....")
}
我正在使用 Knockoutjs 的模板绑定在屏幕上呈现数据.
I am using Knockoutjs 's template binding to render the data on the screen.
<img data-bind="attr: { src: imageUrl }" />
因此，每次通过Ajax调用更改对象时，都会使用数据重新渲染Knockoutjs模板，并且图像也会更改.
So every time the object changes via an Ajax call, the Knockoutjs template is re-rendered with the data, and the images change.
长时间后，这些图像会堆积起来，并会占用更多的内存.现代浏览器似乎可以更好地应对，但问题主要出在IE8上(我们不支持< IE8).即使在现代浏览器中，内存最终也会变得很高，以至于浏览器无法运行.
After a long period of time, these images build up and will eat up more memory. Modern browsers seem to cope better, but the problem is mainly with IE8 (we do not support < IE8). Even in modern browsers the memory will eventually get so high that the browser freezes.
有关构建图像资源的示例，请参见此屏幕截图.
See this screen shot for an example of the image resources building up.
我决定看看如果使用<iframe />而不是使用<img />标记会发生什么情况.
I decided to see what would happen if instead of using an <img /> tag, use a <iframe />.
所以我的代码现在看起来像
So my code now looks like
<iframe data-bind="attr: { src: imageUrl }"></iframe>
现在发生的事情是创建了框架，但是一旦imageUrl更改，框架就会简单地更新，而不会创建其他资源.
What happens now is that the frame is created, but as soon as the imageUrl changes, the frame simply updates and does not create additional resources.
因此，如果我想降低浏览器的内存使用量，可以使用此<iframe />技术，但我不喜欢它.这迫使我对应用程序进行许多其他更改，另外我还需要使用iframe！
So if I want to keep the browser memory usage down, I can use this <iframe /> technique, but I don't like it. It forces me to make many other changes to the application, plus I need to use iframes!
我现在已经进行了各种测试，以查看使用这两种技术消耗了多少内存，并且在相同的时间段内，内存将从81,000k增加到200,000k(使用<img />)，而从81,000k增加到98,000 k(带有<iframe />)
I have run various tests now to see how much memory is used up using both techniques, and over the same period of time the memory will increase from 81,000k to 200,000k (with <img />) compared to 81,000k to 98,000k ( with <iframe />)
问题
是否有更好的方法来管理浏览器中的图像资源?有没有办法正确处理此图像? 我已经在网上搜索了答案，但是到目前为止我还没有找到任何东西.
Is there a better way to manage image resources within a browser? Is there a way to properly dispose of this image? I have searched the web for an answer, but so far I have not found anything.
修改
在最基本的层面上.我试图通过jQuery方法remove()删除图像，但是从未删除图像资源.请参阅此小提琴中的一个非常基本的示例. http://jsfiddle.net/ezb9e/
At the very basic level. I have tried to remove an image via the jQuery method remove(), but the image resource is never removed. See this fiddle for a very basic example. http://jsfiddle.net/ezb9e/
代码:
html
<img src="http://www.fillmurray.com/200/300" />
JS
$(function(){
setTimeout(function(){
$('img').remove();
$('body').append($('<img />', { attr: { src: 'http://www.fillmurray.com/300/200' }}));
}, 3000);
});
推荐答案
我将尝试使用自定义绑定，并在其中创建和销毁图像.去年，我在使用SVG时遇到了类似的问题，这就是我必须要做的.
I would try using a custom binding, and create and destroy the images in that. I had a similar problem last year with an SVG, and that's what I had to do.
ko.bindingHandlers.createImage = {
update: function (element, valueAccessor, allBindingsAccessor, viewModel, bindingContext) {
// Use something unique to identify this image object
var imageName = viewModel.Name();
var parent = bindingContext.$parent;
var imageObject = parent.Images[imageName];
if (imageObject) {
$(element).empty()
imageObject = null;
}
imageObject = $(element).append('<img src="' + viewModel.imgSrc() + '" />')[0];
parent.Images[imageName] = imageObject;
}
};
在这里重新创建您的原始问题:
Here's recreating your original problem:
http://jsfiddle.net/manzanotti/ezb9e/5/
这是我的版本:
http://jsfiddle.net/manzanotti/ezb9e/13/
内存最初会上升，但是会不时地收集垃圾，因此它永远不会失控.在IE9和Chrome中对此进行了测试.
Memory goes up initially, but it gets garbage collected every now and again, so it never gets out of control. This is tested in IE9 and Chrome.
更新嗯，我现在不相信这完全可以解决IE8中的问题.我已经在sIEve中运行了小提琴，并且内存仍在增加，尽管sIEve在DOM节点中添加了挂钩，但这可能是在sIEve中运行它的结果. Chrome绝对可以，但是IE9至少要好很多，即使不是完全固定的.
Update Hmmm, I'm not now convinced that this completely fixes the problem in IE8. I've run the fiddle in sIEve, and the memory is going up still in that, though as sIEve adds hooks into DOM nodes, it could be a result of running it in sIEve. Chrome is definitely fine though, and IE9 seems, at the very least, to be a lot better, if not completely fixed.
这篇关于正确处置浏览器资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
