欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  web前端

JS类库Bindows1.3中的内存释放方式分析_javascript技巧

程序员文章站 2022-04-25 19:53:33
...
我在前段时间介绍过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虚拟内存。都可以在任务管理器中查看。