jQuery對事件的綁定分別有幾個API

.bind()/.live()/.delegate()/.on()

不管是用什么方式綁定，歸根到底還是用addEventListener/attachEvent處理的,正如選擇器一樣不管如何匹配最終還是那么幾個瀏覽器接口處理,既然如此,事件為什么還要區(qū)分那么多不同的處理方案?

這里就要涉及到 DOM 事件處理模型了，就是常提到的捕獲與冒泡，傳統(tǒng)的事件處理給某一元素綁定了一個點擊事件，傳入一個回調(diào)句柄處理。

element.addEventListener('click',doSomething,false)

這樣的代碼再正常不過了，但是，如果頁面上有幾百個元素需要綁定（假設(shè)），那么務(wù)必就要綁定幾百次啦。
這樣問題就出現(xiàn)了：

第一：大量的事件綁定，性能消耗，而且還需要解綁（IE會泄漏）
第二：綁定的元素必須要存在
第三: 后期生成HTML會沒有事件綁定，需要重新綁定
第四: 語法過于繁雜

有沒有辦法優(yōu)化呢？答案是肯定的，那就是采用委托的機制

事件委托

DOM 有個事件流的特性，也就是說我們在頁面上觸發(fā)節(jié)點的時候事件都會上下或者向上傳播，事件捕捉和事件冒泡。

DOM2.0 模型將事件處理流程分為三個階段：

一、事件捕獲階段
二、事件目標階段
三、事件起泡階段

事件傳送可以分為3個階段。
（1）在事件捕捉（Capturing）階段，事件將沿著DOM樹向下轉(zhuǎn)送，目標節(jié)點的每一個祖先節(jié)點，直至目標節(jié)點。例如，若用戶單擊了一個超鏈接，則該單擊事件將從document節(jié)點轉(zhuǎn)送到html元素，body元素以及包含該鏈接的p元素。在此過程中，瀏覽器都會檢測針對該事件的捕捉事件監(jiān)聽器，并且運行這件事件監(jiān)聽器。
（2）在目標（target）階段，瀏覽器在查找到已經(jīng)指定給目標事件的事件監(jiān)聽器之后，就會運行該事件監(jiān)聽器。目標節(jié)點就是觸發(fā)事件的 DOM 節(jié)點。例如，如果用戶單擊一個超鏈接，那么該鏈接就是目標節(jié)點（此時的目標節(jié)點實際上是超鏈接內(nèi)的文本節(jié)點）。
（3）在冒泡（Bubbling）階段，事件將沿著DOM樹向上轉(zhuǎn)送，再次逐個訪問目標元素的祖先節(jié)點到document節(jié)點。該過程中的每一步。瀏覽器都將檢測那些不是捕捉事件監(jiān)聽器的事件監(jiān)聽器，并執(zhí)行它們。
利用事件傳播（這里是冒泡）這個機制，就可以實現(xiàn)事件委托

具體來說，事件委托就是事件目標自身不處理事件，而是把處理任務(wù)委托給其父元素或者祖先元素，甚至根元素（document）

委托這么好的特性 jQuery 當(dāng)然不會放過，所以就衍生出  .bind()、.live() .on()和.delegate()，jQuery 的事件綁定有多個方法可以調(diào)用，以 click 事件來舉例：

click方法
bind方法
delegate方法
on方法

這里要清楚的認識：不管你用的是（click / bind / delegate)之中哪個方法，最終都是 jQuery 底層都是調(diào)用 on 方法來完成最終的事件綁定。因此從某種角度來講除了在書寫的方便程度及習(xí)慣上挑選，不如直接都采用 on 方法來的痛快和直接。

所以在新版的 API 中都這么寫到:

.on()方法事件處理程序到當(dāng)前選定的 jQuery 對象中的元素。在jQuery 1.7中，.on()方法提供綁定事件處理的所有功能、效果不言而喻了，除了性能的差異，通過委托的事件還能很友好的支持動態(tài)綁定，只要 on 的delegate 象是 HTML 頁面原有的元素，由于是事件的觸發(fā)是通過Javascript的事件冒泡機制來監(jiān)測，所以對于所有子元素（包括后期通過JS生成的元素）所有的事件監(jiān)測均能有效，且由于不用對多個元素進行事件綁定，能夠有效的節(jié)省內(nèi)存的損耗。