关于Ext内存泄漏的部分心得

[color=gray]-------
昨天发帖，没想到只加到博客中，论坛中没有...重发一下~
-------[/color]
内存释放在使用Ext开发OPOA系统时显得尤为重要
去年开始接触Ext开发，中间花了很多时间来解决内存泄漏。
最开始Ext还是3.0版，泄漏得一塌胡涂，也没什么处理头绪，只知道在onDestroy里加delete语句，用sIEve看效果。
而Ext3.1有了一个很大的进步，基本上绝大多数组件都没有泄漏了。但并不意味着Ext没泄漏，做出的页面也没泄漏。JS是自动回收的，而只要有一个引用没有释放就可能导致一大片JS对象及Dom节点无法释放，所以迟早还是会面对这个问题。

本人不擅长表达，就直接列心得吧。

[b]一、泄漏的分类[/b]
[b]1. 组件创建后未销毁(Ext层面)[/b]
这里说的组件一般是指继承自Ext.Component的，它在创建时会注册到Ext.ComponentMgr中，不调用destroy方法是不会从中移除的，所以它永远不会被释放。
大部分组件是放置于Container中，Container销毁会将子组件一起销毁，是不存在这个问题。但当它是Ext.Window(没有父容器)或手工render的组件(例如用模板画html，再render到指定Dom节点)时，如果不主动销毁问题就发生了。

[b]2. 组件自身有泄漏或使用不当(JS&Dom层面)[/b]
目前Ext原生组件的泄漏已经很少了，但自己扩展的组件不注意的话会造成浏览器无法释放的泄漏。
(参考：http://www.ibm.com/developerworks/cn/web/wa-memleak/index.html)
而使用不当是指破坏了组件内部结构，导致无法完全释放。

[b]3. JS对象微量泄漏(JS层面)[/b]
举一个典型的例子，Ext.lib.Ajax中，poll与timeout属性用于记录状态监听与超时监听任务的ID，在请求完成后只是简单的置为null，从而导致这两个对象属性越来越多。不要小看这一点增长，在IE下大概6次Ajax请求这里就会多占1K内存，设想一个页面每2秒发送Ajax请求一次，1天就会造成43200 * 2个null无用属性，在IE下约等于6M内存。(当前Ext仍存在这个问题)
另一个Ext对此作处理的例子，就是Ext中的elCache清理(Ext中定义的garbageCollect定时执行)，与IE的bug相关：http://www.sencha.com/forum/showthread.php?89317-quot-IE-object-leaks-quot-What-s-going-on

看似很少，积少成多也不得了，在1,2类泄漏解决完后，就要面对这样的问题了。

[b]二、泄漏检查[/b]
[b]1. 组件泄漏[/b]
这个比较简单，可以写个函数记录Ext.ComponentMgr.all(Ext.util.MixedCollection)中的组件列表，从而判断哪些组件还没有被销毁。

[b]2. 组件内部泄漏[/b]
这个就要用sIEve查看了，创建、销毁，看Dom列表。

[b]3. 微量泄漏[/b]
只能用笨办法，使用IE，调快逻辑执行，长时间运行，记录任务管理器中显示的虚拟内存（不能用其它浏览器，经测试FF和Chrome缓存很厉害，很难测出增长。也不能用sIEve，它监控内存及dom数量时也会造成内存增长）

[b]三、定位并解决[/b]
[b]1. 组件泄漏[/b]
找到没销毁的，扩展onDestroy，在其中销毁掉。

[b]2. 组件内部泄漏[/b]
定位泄漏的Dom节点关联的代码，查检有没有调用removeNode移除，有没有循环引用
具体的不好讲，原因非常多，可以边改边用sIEve看效果。

[b]3. 微量泄漏[/b]
这个没啥办法。。。只能调快操作长时间运行查看平均增长，然后一步步改代码排除了……

关于内存泄漏的解决方法，以上几乎没写什么有用的东西，说实话，我也不知道该写些什么。
因为我处理的内存泄漏大部分都是排除法定位并解决的，现在除了sIEve能查看Dom节点泄漏，没啥好用的工具能检查与之相关的JS对象的情况。从而导致只能靠蒙来找到造成泄漏的代码。

PS：有个firefox相关的工具可以查看JS运行状态，非常详细非常专业，但我研究了一天没弄懂
有会用的人发发心得吧。。。
http://www.softwareverify.com/javascript/memory/index.html
点页面右边的eval获取评估版注册码。