|
|
何謂"仔細"呢？就是說在有對象相互引用的時候，在對象丟棄時(不一定是頁面refresh)斷開彼此的引用鏈，特別是腳本中創(chuàng)建的對象和DHTML中的對象間的引用；清除HTML元素中的所有自定義屬性；清除所有HTML元素中的事件處理函數(shù)回調；對數(shù)組在廢棄時盡力delete掉內部元素。
最重要的就是，盡量不創(chuàng)建冗余的腳本對象和DHTML元素對象，能通過修改屬性來達到的效果，即使麻煩一些也不重新生成新的對象。
通過上面的步驟后，IE的內存使用增長率有所下降。可是仍然不能完全滿足對復雜的腳本運行的支持(接近Bindows這種復雜程度)，體現(xiàn)在以下幾點：
一、在腳本執(zhí)行過程中，內存使用量仍然是個只增不減的過程；
二、使用最小化IE窗口方式強制IE進行GC，只能GC物理內存，對虛擬內存無效；
三、頁面跳離(URL改變)原腳本執(zhí)行域，內存釋放量太少甚至不釋放；
四、必須關閉IEXPLORE.EXE進程(即所有IE窗口)，才能完全釋放IE所使用的內存。
今天突然想起來久違的Bindows，跑去一看，2月底release了一個1.3版本，于是開始運行主頁上面給的demo。效果不用說了，自己去看一下就行了，效率也相當?shù)母摺emo里還有一個類似多維數(shù)據(jù)顯示的GRID，居然還支持行和列的表頭都固定。炫已經(jīng)是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做的很非常周到的。復雜對象都實現(xiàn)了完備的dispose方法，用來作什么呢？在被調用時，首先切斷DHTML對象實例和腳本對象實例的引用鏈；清除全局cache變量中的數(shù)據(jù)，使用delete關鍵字；使用attachEvent方式導入的事件處理函數(shù)，需要detach；其它事件處理回調，使用賦null的方式清空；切斷腳本對象之間的parent或child關系引用鏈。
這里有點使人迷惑的是，IE的GC的觸發(fā)是不確定的(目前知道的確定觸發(fā)就是最小化IE窗口)，就是你做好了上述工作，在你的頁面剛onload時，內存也是不會立即釋放的。不過一段時間使用后，IE使用的內存會減少。所以就不用懷疑先前討論的方法了，并且除了"切斷腳本對象之間的parent或child關系引用鏈"這一點外，Bindows的dispose的原理和處理方法我前面討論基本一致。
注：PM物理內存，VM虛擬內存。都可以在任務管理器中查看。
JavaScript技術：JS類庫Bindows1.3中的內存釋放方式分析，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
