現在的web應用越來越複雜,需要響應各種各樣的用戶觸發事件,因而也就不可避免的,需要給我們的html頁面上的dom元素增加事件監聽函數.
我們知道給dom元素綁定事件監聽函數的方法有如下3種:
1 : 頁面html:
2: 頁html:
程式碼如下:
document.getElementBylickon(“btn =”). test;
程式碼:
複製程式碼
程式碼：
複製代碼
程式碼如下:
document.getElementById(“btn”).atachEvent(“onclick”,test); //ie
這3種方法的功能效果與差異,大家都了解,在此就不在贅述了,但是這3種方法,對頁面渲染的速度,資源的消耗,卻是有很大不同的.
正文後面的html程式碼是一個demo頁面,大家可以用ie瀏覽器開啟,透過註解不同的程式碼片段,檢視頁面運作效果.
可以看到第一種方式的效率是最低的,隨著頁面節點的增多,頁面渲染時間急劇增加,在ie7下運行,大概670ms;
第二種方式明顯好一些,在ie7下,大概250ms
而第三種方式則是最快的方法,也是web前端開發推薦的標準寫法,在ie7下,大概188ms;
然後我們去掉事件綁定的邏輯,發現只渲染dom元素,不綁定事件的時間,僅僅125ms,可見事件綁定的時間消耗還是很大的,尤其是第一種方式,也就是Dom Level 0 Event,最耗時. 另外,大家運行各段代碼的時候,不妨打開任務管理器,找到瀏覽器對應的進程,查看代碼運行時cpu的消耗以及內存的使用.
我們可以看到,Dom Level 0 Event,對cpu的消耗明顯要高很多.
對內存的消耗分析
:
重新開啟瀏覽器,空白頁面的記憶體佔用量大概是37M,虛擬記憶體為28M,頁面渲染後:
1 記憶體使用54M,虛擬記憶體41M
2 記憶體使用44M,虛擬記憶體使用54M,虛擬記憶體41M
2 記憶體使用44M,虛擬記憶體31M
3 記憶體使用44M,虛擬記憶體31M 可見Dom Level 0 Event對記憶體的消耗,也遠遠超出了其它方式. 為什麼Dom Level 0 Event會這麼消耗系統資源呢?對cpu和記憶體的消耗都遠遠超出了其它方式.我們來做一個簡單分析. 為了便於分析,我們不妨修改一下我們的程式碼 ,然後運行頁面,在ie的script debugger裡我們找到堆疊調用這一項,可以看到有一個anonymos function,這個function是從何而來的呢.原來瀏覽器在對Dom Level 0 Event做綁定的時候,會自動產生一個包含我們的程式碼的匿名函數,然後把這個匿名函數綁定到事件.類似於如下方式:
複製程式碼
程式碼如下: document.getElementById(“btn”).onclick = function(event){ test(); } ;
而ie瀏覽器又沒有足夠的智能,區分出眾多內部功能完全一致的匿名函數並合併它們的引用,所以導致了隨著dom事件綁定的越來越多,匿名函數的個數也越來越多.因為要聲明數量眾多的事件處理匿名函數,也就不難明白,為什麼會消耗如此多的系統資源了.
隨著dom元素的增多,這個資源消耗就會越來越嚴重.而且我們可以嘗試著刷新一下頁面,發現隨著刷新的次數增加,頁面運行越來越慢,cpu消耗也越來越多,內存也會有少量增加.可見,Dom Level 0 Event還會帶來少量的記憶體洩漏.至於時間的延長,cpu消耗的加聚,推測是因為瀏覽器忙於釋放眾多的匿名函數所佔用的資源所帶來的後果.
進一步深入,由於ie瀏覽器是基於冒泡的事件模型,子元素的event會冒泡到父元素,所以更極致的優化,是去掉眾多子元素的事件綁定,而將事件綁定到父元素,在正文後的demo中,也有這方面的嘗試,可以看到不僅cpu,內存消耗最低,時間上也跟渲染乾淨的html頁面是一樣的.
所以我們在頁面事件綁定中,要盡量避免Dom Level 0 Event,而且要盡可能的將事件上升． （當然也要考慮事件處理的彈性）．
demo：
<script> <BR>var d = new Date() <BR>var str = []; <BR>for(var i = 0 ;i<count;i ){ <BR>str.push('<li onclick="test();">' i '') <BR>} <BR>ul.innerHTML = str.join (""); <BR>alert(new Date - d); <BR>//670 刷新時時間增加85 <BR></script>
