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虚拟内存。都可以在任务管理器中查看。

上一个：使用onbeforeunload属性后的副作用
下一个：区分JS中的undefined,null,"",0和false