JS类库Bindows1.3中的内存释放方式分析
我在前段时间介绍过IE中JavaScript脚本Memory Leak的问题,后来在几位热心网友的讨论下,基本认可了内存泄露的事实和原理。在小规模的测试case下,本来都达到了基本避免IE中脚本的ML问题。可是近来发现只以"仔细"来防止IE中脚本ML似乎是非常困难的一件事情,难道开始的讨论有错误吗?
何谓"仔细"呢?就是说在有对象相互引用的时候,在对象丢弃时(不一定是页面refresh)断开彼此的引用链,特别是脚本中创建的对象和DHTML中的对象间的引用;清除HTML元素中的所有自定义属性;清除所有HTML元素中的事件处理函数回调;对数组在废弃时尽力delete掉内部元素。
最重要的就是,尽量不创建冗余的脚本对象和DHTML元素对象,能通过修改属性来达到的效果,即使麻烦一些也不重新生成新的对象。
通过上面的步骤后,IE的内存使用增长率有所下降。可是仍然不能完全满足对复杂的脚本运行的支持(接近Bindows这种复杂程度),体现在以下几点:
一、在脚本执行过程中,内存使用量仍然是个只增不减的过程;
二、使用最小化IE窗口方式强制IE进行GC,只能GC物理内存,对虚拟内存无效;
三、页面跳离(URL改变)原脚本执行域,内存释放量太少甚至不释放;
四、必须关闭IEXPLORE.EXE进程(即所有IE窗口),才能完全释放IE所使用的内存。
今天突然想起来久违的Bindows,跑去一看,2月底release了一个1.3版本,于是开始运行主页上面给的demo。效果不用说了,自己去看一下就行了,效率也相当的高。demo里还有一个类似多维数据显示的GRID,居然还支持行和列的表头都固定。炫已经是bindows亘古不变的特点了,在还没有被迷昏前,我想起应该看看Bindows对内存的处理怎么样?真是不看不知道,一看吓一跳!
打开www.bindows.net,我的IE内存使用量在(28PM+18VM)M左右,打开它的demo program。内存上到(38PM+35VM)M左右,然后再操作了几下,内存到了(80PM+75VM)M左右。于是关掉demo窗口,IE释放了大概15M左右内存,就停在(70PM+70VM)M的水平,在改变当前IE的URL,跳到了google,IE的内存使用量似乎还是没有减少@_@。哈哈,Bindows也有Memory Leak~。真是小人得志,555... 过了一段短时间再看,IE的内存使用降到和开启IE时差不多了:)。真实好消息,看来不能再冤枉IE了,于是开始跟踪Bindows在onunload时的处理代码。
怎么能一下就跳到onunload的代码里去呢?这里有个hack,先对IE按下Alt+V,u,b(需要uncheck IE options高级中的"禁止脚本调试",菜单View里才有U快捷键选项)。然后立即关闭Bindows的演示dome窗口,选择VS.NET 2003作为Script调试器,就直接跳到onunload的入口处了。
在管理IE中的脚本内存使用中,Bindows做的很非常周到的。复杂对象都实现了完备的dispose方法,用来作什么呢?在被调用时,首先切断DHTML对象实例和脚本对象实例的引用链;清除全局cache变量中的数据,使用delete关键字;使用attachEvent方式导入的事件处理函数,需要detach;其它事件处理回调,使用赋null的方式清空;切断脚本对象之间的parent或child关系引用链。
这里有点使人迷惑的是,IE的GC的触发是不确定的(目前知道的确定触发就是最小化IE窗口),就是你做好了上述工作,在你的页面刚onload时,内存也是不会立即释放的。不过一段时间使用后,IE使用的内存会减少。所以就不用怀疑先前讨论的方法了,并且除了"切断脚本对象之间的parent或child关系引用链"这一点外,Bindows的dispose的原理和处理方法我前面讨论基本一致。
注:PM物理内存,VM虚拟内存。都可以在任务管理器中查看。