Javascript事件模型系列（三）jQuery中的事件监听方式及异同点

作为全球最知名的js框架之一，jQuery的火热程度堪称无与伦比，简单易学的API再加丰富的插件，几乎是每个前端程序员的必修课。从读《锋利的jQuery》开始，到现在使用jQuery有一年多的时间了，对jQuery算是比较了解了，唯一没做到的就是读源码。网上看到有人写jQuery源码解析的，我也没细看，个人觉得如果光是为了解析源码而解析源码，未免有点太劳神了，没有实际用途，我更倾向于在实际应用中遇到不懂的方法或是文档说明不清楚的地方，可以查找到相应的位置看下源码，足矣。

闲话不多讲了，今天的主题是jQuery中的事件监听器的绑定方式。在学习jQuery之初，就在网上不只一次搜过相关主题，看了几篇被抄来抄去的文章，算是了解了内情。今天去搜网上的文章依旧有很多，所以我就在思考我这篇文章该写成什么样子，既能表达清楚主题而又与其他的文章不同。思考良久我决定，从jQuery源码的角度结合各种例子来把整个来龙去脉说个透彻，让读者看过这篇文章后就再也不需看别人的，理想有点丰满哈~好像又是闲话了，速度奔主题。。。

jQuery中的四种事件监听方式

jQuery中提供了四种事件监听方式，分别是bind、live、delegate、on，对应的解除监听的函数分别是unbind、die、undelegate、off。在开始看他们之前，先来声明一个例子，各函数的用法将围绕这个例子进行，html代码如下：

1
2
3
4
5
6
7
1<ol id="myol">

2    <li>列表元素1</li>

3    <li>列表元素2</li>

4    <li>列表元素3</li>

5    <li>列表元素4</li>

6</ol>

7

同时再声明一个函数，用来作为监听函数，JS代码如下：

1
2
3
4
1function getHtml(){

2    alert(this.innerHTML);

3}

4

看完例子大家应该明白想要干什么了，没错，就是实现点击每个列表元素的时候，把它的内部html弹出来，灰常简单~

忍不了了，奔主题奔主题！下面来分别看一下这四种方式：

bind(type,[data],function(eventObject))

在我初学jQuery的时候，这个函数用的是最多的（基本上就认它），作用就是在选择到的元素上绑定特定事件类型的监听函数，参数的含义如下：

type:事件类型，如click、change、mouseover等；

data:传入监听函数的参数，通过event.data取到。可选；

function:监听函数，可传入event对象，这里的event是jQuery封装的event对象，与原生的event对象有区别，使用时需要注意。

来看看bind的源码：

1
2
3
4
1bind: function( types, data, fn ) {

2        return this.on( types, null, data, fn );

3    }

4

可以看到内部是调用了on方法，这个on是什么样的呢？稍后我们再看。先用我们上面的例子来试试：

1
2
1$('#myol li').bind('click',getHtml);

2

1. 列表元素1
2. 列表元素2
3. 列表元素3
4. 列表元素4

bind的特点就是会把监听器绑定到目标元素上，有一个绑一个，在页面上的元素不会动态添加的时候使用它没什么问题。但如果列表中动态增加一个“列表元素5”，点击它是没有反应的，必须再bind一次才行。要想不这么麻烦，我们可以使用live。jQuery还有一种事件绑定的简写方式如a.click(function(){});、a.change(function(){});等，它们的作用与bind一样，仅仅是简写而已。

live(type, [data], fn)

****参数与bind一样，源码是怎样的呢？

1
2
3
4
5
1live: function( types, data, fn ) {

2        jQuery( this.context ).on( types, this.selector, data, fn );

3        return this;

4    }

5

可以看到live方法并没有将监听器绑定到自己(this)身上，而是绑定到了this.context上了。这个context是什么东西呢？其实就是元素的限定范围，看了下面的代码就清楚了：

1
2
3
4
1$('#myol li').context; //document

2$('#myol li','#myol').context; //document

3$('#myol li',$('#myol')[0]); //ol 

4

通常情况下，我们都不会像第三种方式那样使用选择器，所以也就认为这个context通常就是document了，即live方法把监听器绑定到了document上了。不把监听器直接绑定在元素上，你是不是想起事件委托机制来了呢？若没有，可以点击这里回忆一下。live正是利用了事件委托机制来完成事件的监听处理，把节点的处理委托给了document。在监听函数中，我们可以用event.currentTarget来获取到当前捕捉到事件的节点。下面的例子来揭晓：

1
2
1$('#myol li').live('click',getHtml);

2

1. 列表元素1
2. 列表元素2
3. 列表元素3
4. 列表元素4

使用事件委托的优点一目了然，新添加的元素不必再绑定一次监听器。看来live这货还真不错，以后抛弃bind就用它了！可以吗？答案是否定的，而且是大大的否定。因为将监听器绑定到了document上，所以事件的处理得等待层层冒泡，直到冒泡到根节点才开始处理，在DOM树较深或者节点的嵌套关系很复杂时，会有意想不到的结果，根节点的负担太重了。就像四世同堂、五世同堂，甚至八世同堂（现实中不太可能，但在HTML中层级关系可能远比这还多），老爷子肯定记不清哪个孙子是哪个儿子的，哪个重孙又是哪个儿子的儿子的，老爷子脑子一乱，糊涂了，事情就办错了。为此，jQuery官方已宣布在1.7版本开始废弃live，改用其他方式代替。所以我们也顺应号召，罢用此方法。

正因为live存在那样的缺点，所以我们就思考，既然老爷子负担那么重，可不可以别把监听器绑定在document上呢，绑定在就近的父级元素上不就好了。顺应正常逻辑，delegate诞生了。

delegate(selector,type,[data],fn)

参数多了一个selector，用来指定触发事件的目标元素，监听器将被绑定在调用此方法的元素上。看看源码：

1
2
3
4
1delegate: function( selector, types, data, fn ) {

2        return this.on( types, selector, data, fn );

3    }

4

又是调用了on，并且把selector传给了on。看来这个on真的是举足轻重的东西。照样先不管它。看看示例先：

1
2
1$('#myol').delegate('li','click',getHtml);

2

1. 列表元素1
2. 列表元素2
3. 列表元素3
4. 列表元素4

我们在例子中将监听器绑定到ol上，event.currentTarget显示当前捕获到事件的元素是ol。这下，我们的选择又多了一些灵活性，不单可以利用事件委托，还可以选择委托的对象。毕竟老麻烦同一个人帮忙很不好嘛。对于如何选择委托对象，还是需要一定的策略的，毕竟父级元素可以有很多。我觉得原则应该是选择最近的“稳定”元素，选择最近是因为事件可以更快的冒泡上去，能够在第一时间进行处理。所谓“稳定”是指该父级元素是一开始就在页面上的，不是动态添加上来的，而且将来也不会消失掉，这样可以保证它可以时时监控着自己的孩子。

看了这么多，你是不是迫不及待想看看这个on的真实面目了呢，这就来：

on(type,[selector],[data],fn)

参数与delegate差不多但还是有细微的差别，首先type与selector换位置了，其次selector变为了可选项。交换位置的原因不好查证，应该是为了让视觉上更舒服一些吧。至于selector为什么是可选了呢，速度回想。。。对了，bind也调用了它，因为bind是绑定在了自己身上，所以只能传个null进来。对吗？不对，传null和不传是两回事啊，差点掉坑里。看看on的源码里能不能找到线索呢，打开源码只发现一句关键的：

1
2
3
4
1return this.each( function() {

2            jQuery.event.add( this, types, fn, data, selector );

3        })

4

在on的内部，又调用了event.add方法，纳尼？顺着再走一步好了，进入event.add查看，越加复杂，不过还好，看到了一段熟悉的代码：

1
2
3
4
5
6
1if ( elem.addEventListener ) {

2     elem.addEventListener( type, eventHandle, false );

3     } else if ( elem.attachEvent ) {

4         elem.attachEvent( "on" + type, eventHandle );

5        }

6

看来已经开始进行事件监听，不会再往深走了，舒一口气继续往下看：

1
2
3
4
5
6
7
1// Add to the element's handler list, delegates in front

2if ( selector ) {

3     handlers.splice( handlers.delegateCount++, 0, handleObj );

4     } else {

5     　　handlers.push( handleObj );

6       }

7

传不传selector的区别就在此处了！但是！区别到底是什么啊，智商捉急！翻来覆去就是看不明白。哎，本来想通过源码把事情说明白的，可惜在下不才，还是献丑了。暂时还是说不明白了。等待日后更新此处吧。

         不过，解释不明白源码还是可以通过例子来理解嘛！我们先不传selector来看看：

1
2
1$('#myol li').on('click',getHtml);

2

1. 列表元素1
2. 列表元素2
3. 列表元素3
4. 列表元素4

可以看到event.currentTarget是li自己，与bind的效果一样。我为什么一直要纠结这个传不传selector的区别呢？老老实实传进去不就完了。其实是因为之前有看过文章提到如何用on来代替bind和live的写法，其中代替bind的写法就是不传selector进去，今日就想探清楚这个究竟。至于传selector进去，就是跟delegate一样的意义了，除了参数顺序不同，其他完全一样。

终于看到on的真实作用了，那么，这么多的事件绑定方式，我们该如何进行选择呢？

bind、live、delegate、on如何选择？

其实这个问题是完全不必纠结的，因为你已经知道他们之间的区别了不是么？根据实际情况斟酌使用就行。不过官方有一个推荐就是尽量使用on，因为其他方法都是内部调用on来完成的，直接使用on可以提高效率，而且你完全可以用on来代替其他三种写法。至于如何代替我想就不必这么直白的写出来了，真正理解它们的区别之后自然而然也就不是难事了。

总结一下

jQuery的事件监听方式就分析完了，除了后面看event.add源码有点水分之外，应该是能把整个原理解释明白了。