Ext&OPOA的内存释放改进 (Ext3.0.0)

帖子发了好几天，可惜么人回 
好在经过几天的努力，发现这个问题也没那么困难。
目前修改了一些Ext组件，使用sIEve检查发现除form节点外，其它的都可以正常释放掉。
(form节点无法释放好像是IE自身的特性)
不过只是想要个是否可行的答案罢了，现在看来貌似是可行的。

自己做的补丁帖在3楼
由于是做非常简单的可行性测试，所以只有部分标准UI组件的修正，有兴趣的可以回帖交流。

---2009-9-14

-----------------------------传说中的分割线---------------------------------------

最近准备使用Ext3.0.0开发一个one page one application的网站
预先做了一个测试页面，使用动态加载JS，多Tab切换，无iframe。

界面效率问题不用说了，一直就那样，还勉强可以接受。
但在IE下测试内存占用的时候，发现问题真的很严重。
一个新Tab页面，里面有两Tab，每Tab里有Tree、Grid、Chart、Form面板各一个
每多开一个Tab页，内存占用上升9M左右。关闭Tab页释放的内存也极少
开始以为IE本身特性就是这样(不立即释放内存)
但测试开了20来个Tab页，性能下降了一倍左右，内存占用近200M，关闭Tab页也没有释放几M。

于是使用sIEve来检测，发现每开关一个Tab页，都会出现近100来个孤立(Orphan)Dom节点无法释放。
在开关20来次后，总Dom节点达到了近5K的水平
Dom节点无法释放，肯定是有引用它们的JS对象，这些对象也属于无用数据，应当被清除掉才对。

后来上网查找资料，发现Ext2.2有人写过一个补丁，也是做opoa时发现问题并手工修正的：
http://www.extjs.com/forum/showthread.php?t=45782
这个帖的作者是中国人： Location: nanning, china
不过我们要用到Ext3.0的一些新功能，所以不会考虑Ext2.2
并且他好像很久没上过线，也没有其它联系方式可以交流，真的很可惜。

实在查不到可用的解决方案只好自己尝试：
查找各组件的destroy方法，看它是否完全销毁了各种引用
换句话说，看它是否将自己创建的已经无用的对象销毁，是否将自身与其它任何dom节点、组件切断关系。
没有的话就给它打补丁。

接触Ext也没多久，忙了好几天，只修改了几个组件，并且还不知道有没有其它问题。

例如Ext.Panel组件的修改：

Ext.override(Ext.Panel,{
    onDestroy : function(){
        Ext.destroy(
            this.header,
            this.tbar,
            this.bbar,
            this.footer,
            this.body,
            this.bwrap,
			this.dd
        );
		delete this.header;
		delete this.tbar;
		delete this.bbar;
		delete this.footer;
		delete this.body;
		delete this.bwrap;
		delete this.dd;
        Ext.Panel.superclass.onDestroy.call(this);
    }
});

注：原beforeDestroy没有考虑this.dd的销毁，没有彻底清除dom节点，没有最后delete解引用
开始是直接修改beforeDestroy方法的，但发现删除顺序有些问题，造成继承它的一些组件destroy时出错
所以新建了onDestroy方法
这些属性都是在Panel这一层定义的，销毁也应该在这一层进行。

以上示例测试过，发现所有节点都能释放。

另外还尝试过修改Ext.dd、Ext.ux.Portal的释放
由于水平不足，对自己的修改很没信心，就先不帖出来了。

希望这帖子能起到抛砖引玉的作用，大家一起讨论解决方法
(有点私心的说 )