帝王谷资源网 Design By www.wdxyy.com
我在前段时间介绍过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虚拟内存。都可以在任务管理器中查看。
何谓"仔细"呢?就是说在有对象相互引用的时候,在对象丢弃时(不一定是页面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虚拟内存。都可以在任务管理器中查看。
帝王谷资源网 Design By www.wdxyy.com
广告合作:本站广告合作请联系QQ:858582 申请时备注:广告合作(否则不回)
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
帝王谷资源网 Design By www.wdxyy.com
暂无评论...
更新日志
2024年10月28日
2024年10月28日
- 群星2013-青春缤纷辑压箱宝大公开3CD2[新加坡限量版][WAV整轨]
- 林育群.2013-BalladShow(日本版)【环球】【WAV+CUE】
- 陈加洛.1992-痛到感觉不到【宝丽金】【WAV+CUE】
- 群星.2023-宿命之敌电视剧原声带【韶愔音乐】【FLAC分轨】
- 東京事変-大発見[FLAC+CUE]
- 椎名林檎-三文ゴシップ[FLAC+CUE]
- 2024年08月04日
- 裘德《裘德「最后的水族馆」演唱会LIVE》[320K/MP3][228.89MB]
- 裘德《裘德「最后的水族馆」演唱会LIVE》[24bit 48kHz][FLAC/分轨][2.08G]
- 基因三重奏《如果你什么都不说 音乐会现场录音》[320K/MP3][145.37MB]
- 孟庭苇.1996-月亮说话(2020环球24KGOLD限量版)【上华】【WAV+CUE】
- 群星.1997-新艺宝优质音响系列·国语精选监听版【新艺宝】【WAV+CUE】
- 阿桑.2005-寂寞在唱歌(星外星引进版)【华研国际】【WAV+CUE】
- 基因三重奏《如果你什么都不说 音乐会现场录音》[FLAC/分轨][287.43MB]
- 蔡题谦《我爱你,却依然要看你走》[320K/MP3][88.65MB]