內存釋放在使用Ext開發(fā)OPOA系統(tǒng)時顯得尤為重要
去年開始接觸Ext開發(fā)，中間花了很多時間來解決內存泄漏。
最開始Ext還是3.0版，泄漏得一塌胡涂，也沒什么處理頭緒，只知道在onDestroy里加delete語句，用sIEve看效果。
而Ext3.1有了一個很大的進步，基本上絕大多數(shù)組件都沒有泄漏了。但并不意味著Ext沒泄漏，做出的頁面也沒泄漏。JS是自動回收的，而只要 有一個引用沒有釋放就可能導致一大片JS對象及Dom節(jié)點無法釋放，所以遲早還是會面對這個問題。
本人不擅長表達，就直接列心得吧。
一、泄漏的分類
1. 組件創(chuàng)建后未銷毀(Ext層面)
這里說的組件一般是指繼承自Ext.Component的，它在創(chuàng)建時會注冊到Ext.ComponentMgr中，不調用destroy方法是 不會從中移除的，所以它永遠不會被釋放。
大部分組件是放置于Container中，Container銷毀會將子組件一起銷毀，是不存在這個問題。但當它是Ext.Window(沒有父 容器)或手工render的組件(例如用模板畫html，再render到指定Dom節(jié)點)時，如果不主動銷毀問題就發(fā)生了。
2. 組件自身有泄漏或使用不當(JS&Dom層面)
目前Ext原生組件的泄漏已經(jīng)很少了，但自己擴展的組件不注意的話會造成瀏覽器無法釋放的泄漏。
(參考：http://www.ibm.com/developerworks/cn/web/wa-memleak/index.html)
而使用不當是指破壞了組件內部結構，導致無法完全釋放。
3. JS對象微量泄漏(JS層面)
舉一個典型的例子，Ext.lib.Ajax中，poll與timeout屬性用于記錄狀態(tài)監(jiān)聽與超時監(jiān)聽任務的ID，在請求完成后只是簡單的置 為null，從而導致這兩個對象屬性越來越多。不要小看這一點增長，在IE下大概6次Ajax請求這里就會多占1K內存，設想一個頁面每2秒發(fā)送Ajax 請求一次，1天就會造成43200 * 2個null無用屬性，在IE下約等于6M內存。(當前Ext仍存在這個問題)
另一個Ext對此作處理的例子，就是Ext中的elCache清理(Ext中定義的garbageCollect定時執(zhí)行)，與IE的bug相 關：http://www.sencha.com/forum/showthread.php?89317-quot-IE-object-leaks- quot-What-s-going-on
看似很少，積少成多也不得了，在1,2類泄漏解決完后，就要面對這樣的問題了。
二、泄漏檢查
1. 組件泄漏
這個比較簡單，可以寫個函數(shù)記錄Ext.ComponentMgr.all(Ext.util.MixedCollection)中的組件列表， 從而判斷哪些組件還沒有被銷毀。
2. 組件內部泄漏
這個就要用sIEve查看了，創(chuàng)建、銷毀，看Dom列表。
3. 微量泄漏
只能用笨辦法，使用IE，調快邏輯執(zhí)行，長時間運行，記錄任務管理器中顯示的虛擬內存（不能用其它瀏覽器，經(jīng)測試FF和Chrome緩存很厲害， 很難測出增長。也不能用sIEve，它監(jiān)控內存及dom數(shù)量時也會造成內存增長）
三、定位并解決
1. 組件泄漏
找到?jīng)]銷毀的，擴展onDestroy，在其中銷毀掉。
2. 組件內部泄漏
定位泄漏的Dom節(jié)點關聯(lián)的代碼，查檢有沒有調用removeNode移除，有沒有循環(huán)引用
具體的不好講，原因非常多，可以邊改邊用sIEve看效果。
3. 微量泄漏
這個沒啥辦法。。。只能調快操作長時間運行查看平均增長，然后一步步改代碼排除了……
關于內存泄漏的解決方法，以上幾乎沒寫什么有用的東西，說實話，我也不知道該寫些什么。
因為我處理的內存泄漏大部分都是排除法定位并解決的，現(xiàn)在除了sIEve能查看Dom節(jié)點泄漏，沒啥好用的工具能檢查與之相關的JS對象的情況。 從而導致只能靠蒙來找到造成泄漏的代碼。
PS：有個firefox相關的工具可以查看JS運行狀態(tài)，非常詳細非常專業(yè)，但我研究了一天沒弄懂
有會用的人發(fā)發(fā)心得吧。。。
http://www.softwareverify.com/javascript/memory/index.html
點頁面右邊的eval獲取評估版注冊碼。
本站僅提供存儲服務，所有內容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權內容，請
點擊舉報。
