轉載請註明來源:http://blog.csdn.net/horkychen
因為JavaScript的語言特性決定了,它的記憶體管理更主要的是交給瀏覽器的JavaScript解譯器來處理,這其中被廣為人知是記憶體回收(Garbage Collection)機制。不過天生的限制使得JS使用的記憶體也需要加以控制,特別是現在使用HTML5的遊戲對JS記憶體管理的要求也越來越高。
目前很多的資料都是關注在JavaScript的執行效能上的。如FireBug等工具都能提供相應的功能。下面是一些參考網頁:
Javascript效能分析——工具(YUI Profiler)
JSProfiler – JS效能分析工具
移動Web應用程式開發 高效能JavaScript篇 (三) JavaScript 載入解析和部署
javascript 記憶體泄露工具使用 (記憶體泄露和記憶體消耗不算是一個話題,但也可以做為參考)
目前,確實只有Chrome的開發工具,可以擷取當前指令碼佔用的堆(Heap)的狀況。在Profiles選擇對Heap進行快照分析就可以了。
(顯示的是某個對象佔用17M多的記憶體)
詳細的說明,請點這裡。
對於其它的瀏覽器可以使用vmmap對瀏覽器查看其總體的記憶體狀況:
以下是Mac OS下vmmap對Safari擷取結果 (執行是vmmap pid. 這個pid是Safari運行叫起的另一個進程):
REGION TYPE VIRTUAL
=========== =======
...
JS JIT generated code 256.0M
JS JIT generated code (reserved) 768.0M reserved VM address space (unallocated)
JS VM register file 4096K
JS garbage collector 34.6M
MALLOC 625.0M see MALLOC ZONE table below
...
注意:如果其中JS garbage collector後面數字比較大,表示指令碼裡有可能存在較多的閉包使得GC不能及時發揮作用。
再使用heap指令,可以看到Malloc Zone中的狀況:
VIRTUAL ALLOCATION BYTES
MALLOC ZONE SIZE COUNT ALLOCATED % FULL
=========== ======= ========= ========= ======
JavaScriptCore FastMalloc_0x7fff7d8b8148 534.1M 2863601 307.6M 57%
DefaultMallocZone_0x10b033000 41.1M 42615 9643K 22%
......
我想你已經看出一些問題了,記憶體開銷跑到500M以上去了!
下一步,就是要分析具體是什麼在耗費我們的記憶體,從而最佳化指令碼執行。
Good Luck!
*Windows下也有vmmap, 來自大名鼎鼎的SysInternals組件, 到這裡看看 [MSDN LINK].
*Windows下的Heap View在這裡。