我在前段时间介绍过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虚拟内存。都可以在任务管理器中查看。
免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！
如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com
狼山资源网 Copyright www.pvsay.com
暂无“JS类库Bindows1.3中的内存释放方式分析”评论...
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。