網页核心四元素内存使用及回收.docxVIP

网页核心四元素内存使用分析问题引入及工具介绍近日在WebEx 11项目中，发起了一次对JavaScript内存回收和泄漏问题的讨论。JavaScript内存回收问题是目前各个主流框架(Ext JS, jQuery)都会遇到的问题。我们的项目中使用了jQuery作为核心库，而jQuery对于IE中Dom节点的回收是存在问题的，本身这个问题并不严重(我们将会在下面的文章中分析)，但因为WebEx 11中会大范围的使用无刷新技术，从而会使内存回收的问题暴露出来。而同时，在无刷技术中，会暴露出内存问题的并不仅是JavaScript环节，所以我对网页当中内存占有的四个核心元素进行了分析。本文中会使用到的内存检测工具：Drip-0.5.exe , sIEve-0.0.8.exe以上两个软件是对Dom节点侵入检测，而后文中提到的JavaScript写法中产生的内存问题，还需要我们根据经验和windows内存工具来判断。在网页当中有4个元素:Dom, CSS, JavaScript, Images。可以说，我们目前所接触的网页都不可能完全离开这几个元素。在这四个环节，IE和Firefox等浏览器对其内存回收的机制是不尽相同的，了解这四部分的内存占用及回收机制可以给WebEx 11带来更少的bug，更快的访问速度，更优秀的用户体验，同时也对我们提高前端代码质量有帮助。Dom节点的内存占用及回收Dom相关的内存问题存在于两个方面：Dom节点的内存回收Dom节点的事件绑定引起的内存泄漏Dom节点的内存回收在网页当中，如果我们有这样的一个结构：(例1)打开sIEve工具，在地址栏输入这个文件的地址我们注意一下右侧(2)处的几个指标：usage：内存占用，以k为单位#inUse: 使用中的Dom节点，目前是10个#leaks: Dom节点泄漏数,目前是0如果我们需要移除div1节点，我们可能会使用类似的方法：(例2)在网页中点击”_removeNode div1”按钮，我们执行这个方法，会看到下面的结果：我们目测已经可以看出，原网页的(1)处已经被移除了，但右侧(2)处的#inUse还是10个，内存变没有变小，但#leaks却还是0。这就得到一个结果：通过parentNode.remove的常规方法移除节点，并没有从内存中移除，但是也没有造成真正意义上的“泄漏”。那么这种情况我们可以怎么分析？首先，我们来找一下，那个被移除的节点到底在哪里。点击，右侧(3)处的“show in use”按钮，会弹出一个窗口可以看到div1在(1)处出现，在Orphan列。它已是一个孤立的点。孤点：我们的html结构其实就像是一个xml文件，在网页中静态或动态创建的节点都被加到以html为根节点的一个树状结构中，而不在这个树状结构中，同时又在该网页的内存段中的Dom节点，就称为“孤点”。它为什么不算是内存泄漏？百度百科定义：内存泄漏也称作“存储渗漏”，用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元。直到程序结束。即所谓内存泄漏。而在我们测试中可以简单的表现为，当浏览器刷新页面后或是转向其它页面，泄漏点依然存在。回到我们的问题，div1变成了孤点，在网页刷新的时候，div1被回收了，他不再存在。所以在#leaks指标中并没有它。变成孤点并不可怕，但是和无刷联系在一起就会产生问题，如果网页在较长一段时间都不会刷新并持续操作，就会出现越来越多的孤点，并不释放内存。解决办法：在网页中先创建一个不在Dom树上的孤点，所有要删除的节点可以都挂靠在这个节点之下。这时，我们只要清空这个父级节点，就可以起到真正删除元素的效果。代码如下：Dom节点的事件绑定引起的内存泄漏Dom节点事件绑定引起的内存泄漏是由于加入Native对象（Dom对象，ActiveX对象）的循环引用造成的。对于这种泄漏，有三点建议：避免将一个DOM对象和一个JS对象相互引用将事件处理函数放在定义它的函数的外部不要在创建DOM对象时插入script下面我们来逐条分析一下出现错误的代码：DOM对象和JS对象相互引用如果html有LeakedDiv节点，那么当执行了SetupLeak后，一旦我们移除了LeakedDiv节点，在IE下就必然会形成泄漏，并且，在IE8下，泄露依然存在。可能有人会说，这样的代码有点低级，一般不会出现的，那我们就来一个更隐蔽的(例3)在执行new Encapsulator时会创建一个JavaScript Object,然后这个对象引用了element,element又引用了这个对象，那么这样的问题就比较不容易被发现，但它的确会有问题！Dom事件绑定的循环引用(闭包)在对IE下事件绑定内存泄漏问题分析前我们需要了解一下JavaScript的scope chain