現在的web應用越來越復雜，需要響應各種各樣的用戶觸發事件，因而也就不可避免的，需要給我們的html頁面上的dom元素增加事件監聽函數。

我們知道給dom元素綁定事件監聽函數的方法有如下3種：

1. 頁面html:

2. 頁面html:

Javascript:

 3. 頁面html:

 Javascript:

這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，虛擬內存31M；

3. 內存使用44M，虛擬內存31M。

可見Dom Level 0 Event對內存的消耗，也遠遠超出了其它方式。

為什么Dom Level 0 Event會這么消耗系統資源呢?對cpu和內存的消耗都遠遠超出了其它方式，我們來做一個簡單分析。

為了便于分析，我們不妨修改一下我們的代碼 <button onclick=”debugger;test();”></button> ，然后運行頁面，在ie的script debugger里我們找到堆棧調用這一項，可以看到有一個anonymos function，這個function是從何而來的呢?原來瀏覽器在對Dom Level 0 Event做綁定的時候，會自動生成一個包含我們的代碼的匿名函數，然后把這個匿名函數綁定到事件，類似于如下方式:

而ie瀏覽器又沒有足夠的智能，區分出眾多內部功能完全一致的匿名函數，并合并它們的引用，所以導致了隨著dom事件綁定的越來越多，匿名函數的個數也越來越多。因為要聲明數量眾多的事件處理匿名函數，也就不難明白，為什么會消耗如此多的系統資源了。

隨著dom元素的增多，這個資源消耗就會越來越嚴重。而且我們可以嘗試著刷新一下頁面，發現隨著刷新的次數增加，頁面運行越來越慢，cpu消耗也越來越多，內存也會有少量增加。可見，Dom Level 0 Event 還會帶來少量的內存泄露，至于時間的延長，cpu消耗的加劇，推測是因為瀏覽器忙于釋放眾多的匿名函數所占用的資源所帶來的后果。

進一步深入，由于ie瀏覽器是基于冒泡的事件模型，子元素的event會冒泡到父元素，所以更極致的優化是去掉眾多子元素的事件綁定，而將事件綁定到父元素。在正文后的demo中，也有這方面的嘗試，可以看到不僅cpu，內存消耗最低，時間上也跟渲染干凈的html頁面是一樣的。

所以，我們在頁面事件綁定中，要盡量避免Dom Level 0 Event，而且要盡可能的將事件上升（當然也要考慮事件處理的靈活性）。

demo：