jQuery绑定事件的四种方式

http://www.51edu.com/it/bckf/35687.html
http://blog.csdn.net/yeliping2011/article/details/7407389
jQuery绑定事件的四种方式

jQuery提供了多种绑定事件的方式，每种方式各有其特点，明白了它们之间的异同点，有助于我们在写代码的时候进行正确的选择，从而写出优雅而容易维护的代码。下面我们来看下jQuery中绑定事件的方式都有哪些。

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

<ol id="myol">
<p> </p>
<p> </p>
<li>列表元素1</li>
<p> </p>
<p> </p>
<li>列表元素2</li>
<p> </p>
<p> </p>
<li>列表元素3</li>
<p> </p>
<p> </p>
<li>列表元素4</li>
<p> </p>
<p> </p>
</ol>

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

function getHtml(){

alert(this.innerHTML);

}

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

bind是使用频率较高的一种，作用就是在选择到的元素上绑定特定事件类型的监听函数，参数的含义如下：

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

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

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

我们来瞄一眼bind的源码：

bind: function( types, data, fn ) {

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

}

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

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

bind的特点就是会把监听器绑定到目标元素上，有一个绑一个，在页面上的元素不会动态添加的时候使用它没什么问题。但如果列表中动态增加一个“列表元素5”，点击它是没有反应的，必须再bind一次才行。要想不这么麻烦，我们可以使用live。

jQuery还有一种事件绑定的简写方式如a.click(function(){});、a.change(function(){});等，它们的作用与bind一样，仅仅是简写而已。

live(type, [data], fn)

live的参数和bind一样，它又有什么蹊跷呢，我们还是先瞄一眼源码：

live: function( types, data, fn ) {

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

return this;

}

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

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

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

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

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

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

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

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

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

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

delegate: function( selector, types, data, fn ) {

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

}

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

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

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

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

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

参数与delegate差不多但还是有细微的差别，首先type与selector换位置了，其次selector变为了可选项。交换位置的原因不好查证，应该是为了让视觉上更舒服一些吧。

我们先不传selector来看一个例子：

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

可以看到event.currentTarget是li自己，与bind的效果一样。至于传selector进去，就是跟delegate一样的意义了，除了参数顺序不同，其他完全一样。

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

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

（bind和live的区别）

Jquery中绑定事件有三种方法：以click事件为例

   （1）target.click(function(){});

   （2）target.bind("click",function(){});

   （3）target.live("click",function(){});

第一种方法很好理解，其实就和普通JS的用法差不多，只是少了一个on而已

第二、三种方法都是绑定事件，但是二者又有很大的不同，下面着重讲解一下，因为这个如果用到Jquery的框架的话是用的挺多的，尤其要注意二者的区别。

【bind和live的区别】

       live方法其实是bind方法的变种，其基本功能就同bind方法的功能是一样的，都是为一个元素绑定某个事件，但是bind方法只能给当前存在的元素绑定事件，对于事后采用JS等方式新生成的元素无效，而live方法则正好弥补了bind方法的这个缺陷，它可以对后生成的元素也可以绑定相应的事件。那么live方法的这个特性是怎么实现的呢？下面来探讨一下其实现原理。

      live方法之所以能对后生成的元素也绑定相应的事件的原因归结在“事件委托”上面，所谓“事件委托”就是指绑定在祖先元素上的事件可以在其后代元素上进行使用。live方法的处理机制就是把事件绑定在DOM树的根节点上，而不是直接绑定在某个元素上。举一个例子来说明：

              $(".clickMe").live("click",fn);

             $("body").append("<div class='clickMe'>测试live方法的步骤</div>");

    当我们点击这个新增的元素时会依次发生如下步骤：

      （1）生成一个click事件，传递给div来做处理

      （2）由于没有事件直接绑定在div上，所以事件直接冒泡到DOM树上

      （3）事件不断冒泡，直到DOM树的根节点上，默认情况下，根节点上就绑定了这个click事件

      （4）执行由live绑定的click事件

      （5）检测绑定事件的对象是否存在，判断是否需要继续执行绑定的事件。检测事件对象是通过检测 

              $(event.target).closest('.clickMe') 能否找到匹配的元素来实现的。

     （6）通过（5）的测试，如果绑定事件的对象存在的话，就执行绑定的事件。

      由于只有在事件发生的时候，live方法才会去检测绑定事件的对象是否存在，所以live方法可以实现后来新增的元素也可实现事件的绑定。相比之下，bind会在事件在绑定阶段就会判断绑定事件的元素是否存在，而且只针对当前元素进行绑定，而不是绑定到父节点上。

根据上面的分析，live的好处真是很大，那么为什么还要使用bind方法呢？之所以jquery要保留bind方法而不是采用live方法去替代bind，也是因为live在某些情况下是不能够完全替代bind的。主要的不同如下：

     （1）bind方法可以绑定任何JavaScript的事件，而live方法在jQuery1.3的时候只支持click, dblclick, keydown, keypress,

               keyup,mousedown, mousemove, mouseout, mouseover, 和 mouseup.在jQuery 1.4.1中，甚至也支持 focus 和 blue

               事件了（映射到更合适，并且可以冒泡的focusin和focusout上）。另外，在jQuery 1.4.1中，也能支持hover（映射

              到"mouseenter mouseleave"）。

    （2）live() 并不完全支持通过DOM遍历的方法找到的元素。取而代之的是，应当总是在一个选择器后面直接使用 .live()

              方法。

    （3）当一个元素采用live方法进行事件的绑定的时候，如果想阻止事件的传递或冒泡，就要在函数中return false,仅仅调

              用stopPropagation()是无法实现阻止事件的传递或者冒泡的