【转】关于编写性能高效的javascript事件的技术

原文转自：http://blog.jobbole.com/80170/

如何能做出高效的web前端程序是我每次做前端开发都会不自觉去考虑的问题。几年前雅虎里牛逼的前端工程师们出了一本关于提升web前端性能的书籍，轰动了整个web开发技术界，让神秘的web前端优化问题成为了大街的白菜，web前端优化变成了菜鸟和大牛都能回答的简单问题，当整个业界都知道了惊天秘密的答案，那么现有的优化技术已经不能对你开发的网站产生的质的飞越，为了让我们开发的网站性能比别人的网站更加优秀，我们需要更加深入的独立思考，储备更加优秀的技能。

Javascript里的事件系统是我想到的第一个突破点。为什么会是javascript的事件系统呢？我们都知道web前端包含三个技术：html、css和javascript，html和css如何结合真是一目了然：style、class、id以及html标签，这个没啥好讲的，但是javascript是如何切入到html和css中间，让三者融合呢？最后我发现这个切入点就是javascript的事件系统，不管我们写多长多复杂的javascript代码，最终都是通过事件系统体现在html和css上，因此我就在想既然事件系统是三者融合的切入点，那么一个页面里，特别是当今越来越复杂的网页里必然会有大量事件操作，没有这些事件我们精心编写的javascript代码只有刀枪入库，英雄无用武之地了。既然页面会存在大量事件函数，那么我们按习惯写事件函数，会存在影响效率的问题吗？我研究下来的答案是真有效率问题，而且还是严重的效率问题。

为了说清楚我的答案，我要先详细讲解下javascript的事件系统。

事件系统是javascript和html以及css融合的切入点，这个切人点好比java里的main函数，一切神奇都是由这里开始，那么浏览器是如何完成这种切入呢？我研究下来一共有3种方式，它们分别是：

方式一：html事件处理

html事件处理就是将事件函数直接写在html标签里，因为这种写法和html标签紧耦合，所以称为html事件处理。例如下面代码：

如果click事件函数复杂了，这么写代码肯定会带来不便，因此我们常常把函数写在外部，onclick直接调用函数名，例如：

上面这个写法是一种很美的写法，所以时下还是很多人会不自觉的使用它，但是也许很多人不知道，后一种写法其实没有前一种写法健壮，这个也是我前不久在研究非阻塞加载脚本技术时候碰到的问题，因为根据前端优化的原则，javascript代码往往是位于页面的底部，当页面有被脚本阻塞时候，html标签里引用的函数可能还没执行到，这个时候我们点击页面按钮，结果会报出“XXX函数未定义的错误”，在javascript里这样的错误是会被try，catch所捕获，因此为了让代码更加健壮，我们会有如下的改写：

看到上面代码岂是一个恶心能描述的。

方式二：DOM0级事件处理

DOM0级事件处理是当今所有浏览器都支持的事件处理，不存在任何兼容性问题，看到这样一句话都会让每个做web前端的人们激动不已。DOM0事件处理的规则是：每个DOM元素都有自己的事件处理属性，该属性可以赋值一个函数，例如下面的代码：

DOM0级事件处理的事件属性都是采用“on+事件名称”的方式定义，整个属性都是小写字母。我们知道DOM元素在javascript代码里就是一个javascript对象，因此从javascript对象角度理解DOM0级事件处理就非常容易，例如下面代码：

那么按钮的点击事件被取消了。

再看下面的代码：

后面一个函数会将第一个函数覆盖。

方式三：DOM2事件处理和IE事件处理

DOM2事件处理是标准化的事件处理方案，但是IE浏览器自己搞了一套，功能和DOM2事件处理相似，但是代码写起来就不太一样了。

在讲解方式三之前，我必须要补充一些概念，否则是无法讲清楚方式三的内涵。

第一个概念是：事件流

在页面开发里我们常常会碰到这样的情况，一个页面的工作区间在javascript可以用document表示，页面里有个div，div等于是覆盖在document元素上，div里面有个button元素，button元素是覆盖在div上，也等于覆盖着document上，所以问题来了，当我们点击这个按钮时候，这个点击行为其实不仅仅发生在button之上，div和document都被作用了点击操作，按逻辑这三个元素都是可以促发点击事件的，而事件流正是描述上述场景的概念，事件流的意思是：从页面接收事件的顺序。

第二个概念：事件冒泡和事件捕获

事件冒泡是微软公司提出解决事件流问题的方案，而事件捕获则是网景公司提出的事件流解决方案，它们的原理如下图：

冒泡事件由div开始，其次是body，最后是document，事件捕获则是倒过来的先是document，其次是body，最后是目标元素div，相比之下，微软公司的方案更加人性化符合人们的操作习惯，网景的方案就很别扭了，这是浏览器大战的恶果，网景慢了一步就以牺牲用户习惯的代码解决事件流的问题。

微软公司结合冒泡事件设计了一套新的事件系统，业界习惯称为ie事件处理，ie事件处理方式如下面代码所示：

在ie下通过DOM元素的attachEvent方法添加事件，和DOM0事件处理相比，添加事件的方式由属性变成了方法，所以我们添加事件就需要往方法里传递参数，attachEvent方法接收两个参数，第一个参数是事件类型，事件类型的命名和DOM0事件处理里的事件命名一样，第二个参数是事件函数了，使用方法的好处就是如果我们在为同一个元素添加个点击事件，如下所示：

运行之，两个对话框都能正常弹出来，方法让我们可以为DOM元素添加多个不同的点击事件。如果我们不要某个事件呢？我们该怎么做了，ie为删除事件提供了detachEvent方法，参数列表和attachEvent一样，如果我们要删除某个点击事件，只要传递和添加事件一样的参数即可，如下代码所示：

运行之，后果很严重，我们很迷惑，第二个click居然没有被删除，这是怎么回事？前面我讲到删除事件要传入和添加事件一样的参数，但是在javascript的匿名函数里，两个匿名函数哪怕代码完全一样，javascript都会在内部使用不同变量存储，结果就是我们看到的现象无法删除点击事件的，因此我们的代码要这么写：

这样添加的方法和删除的方法就是指向了同一个对象，所以事件删除成功了。这里的场景告诉我们写事件要有个良好的习惯即操作函数要独立定义，不要用匿名函数用成了习惯。

接下来就是DOM2事件处理，它的原理如下图所示：

DOM2是标准化的事件，使用DOM2事件，事件传递首先从捕获方式开始即从document开始，再到body，div是一个中介点，事件到了中介点时候事件就处于目标阶段，事件进入目标阶段后事件就开始冒泡处理方式，最后事件在document上结束。（捕获事件的起点以及冒泡事件的终点，我本文都是指向document，实际情况是有些浏览器会从window开始捕获，window结束冒泡，不过我觉得开发时候不管浏览器本身怎么设定，我们关注document更具开发意义，所以我这里一律都是使用document）。人们习惯把目标阶段归为冒泡的一部分，这主要是因为开发里冒泡事件使用的更加广泛。

DOM2事件处理很折腾，每次事件促发时候都会把所有元素遍历两遍，这点和ie事件相比性能就差多了，ie只有冒泡，所以ie只需要遍历一次，不过遍历少了并不代表ie的事件体系效率更高，从开发设计角度同时支持两种事件系统会给我们开发带来更大的灵活度，从这个角度而言DOM2事件还是很有可取之处。DOM2事件的代码如下：

DOM2事件处理里添加事件使用的是addEventListener，它接收三个参数比ie事件处理多一个，前两个的意思和ie事件处理方法的两个参数一样，唯一的区别就是第一个参数里要去掉on这个前缀，第三个参数是个布尔值，如果它的取值是true，那么事件就按照捕获方式处理，取值为false，事件就是按照冒泡处理，有第三个参数我们可以理解为什么DOM2事件处理里要把事件元素跑个两遍，目的就是为了兼容两种事件模型，不过这里要请注意下，不管我们选择是捕获还是冒泡，两遍遍历是永远进行，如果我们选择一种事件处理方式，那么另外一个事件处理流程里就不会促发任何事件处理函数，这和汽车挂空挡空转的道理一样。通过DOM2事件方法的设计，我们知道DOM2事件在运行时候只能执行两种事件处理方式中的一种，不可能两个事件流体系同时促发，所以虽然元素遍历两遍，但是事件函数绝不可能被促发两遍，注意我这里指不促发两遍是指一个事件函数，其实我们可以模拟两个事件流模型同时执行的情况，例如下面代码：

但这种写法是多事件处理，相当于我们点击两次按钮。

DOM2也提供了删除事件的函数，这个函数就是removeEventListener，写法如下：

使用和ie事件的一样即参数要和定义事件的参数一致，不过removeEventListener使用时候，第三个参数不传，默认是删除冒泡事件，因为第三个参数不传默认都是false，例如：

运行之，发现事件没有被删除成功。

最后我要说的是DOM2事件处理在ie9包括ie9以上的版本都得到了很好的支持，ie8以下是不支持DOM2事件的。

下面我们对三种事件方式做个比较，比较如下：

比较一：方式一为一方和其他两种方式比较

方式一的写法是html和javascript结合在一起，你中有我我中有你，把这种方式深化一下就是html和javascript混合开发，用一个软件术语表达就是代码耦合，代码耦合不好，而且是非常不好，这是菜鸟程序员的级别，所以方式一完败，另外两种方式完胜。

比较二：方式二和方式三

它们两个写法差不多，有时真的很难说谁好谁坏，纵观上述内容我们发现方式二和方式三的最大区别就是：使用方式二一个DOM元素某个事件有且只有一次，而方式三则可以让DOM元素某个事件拥有多个事件处理函数，在DOM2事件处理里，方式三还能让我们精确控制事件流的方式，因此方式三的功能比方式二更加的强大，所以相比之下方式三略胜一筹。

下面就是本文的重点：事件系统的性能问题，解决性能问题必须找到一个着力点，这里我从两个着力点来思考事件系统的性能问题，它们分别是：减少遍历次数和内存消耗。

首先是遍历次数，不管是捕获事件流还是冒泡事件流，都会遍历元素，而是都是从最上层的window或document开始的遍历，假如页面DOM元素父子关系很深，那么遍历的元素越多，像DOM2事件处理这种，遍历危害程度就越大了，如何解决这个事件流遍历问题了？我的回答是没有，这里有些朋友也许会有疑问，怎么会没有了？事件系统里有个事件对象即event，这个对象有阻止冒泡或捕获事件的方法，我怎么说没有呢？这位朋友的疑问很有道理，但是如果我们要使用该方法减少遍历，那么我们代码就要处理父子元素的关系，爷孙元素关系，如果页面元素嵌套很多，这就是没法完成的任务，所以我的回答是没法改变遍历的问题，只能去适应它。

看来减少遍历是没法解决事件系统性能问题了，那么现在只有从内存消耗考虑了。我常听人说C#很好用，对于web前端开发它就更好用了，我们可以直接在C#的IDE拖一个按钮到页面，按钮到了页面之后javascript代码会自动为该按钮添加个事件，当然里面的事件函数是个空函数，于是我想我们可以按这种方式在页面放置100个按钮，一个代码都不行就有了100个按钮事件处理，超级方便，最后我们对其中一个按钮添加具体的按钮事件，让页面跑起来，请问大家这个页面效率会高吗？在javascript里，每个函数都是一个对象，每个对象都会耗费内存，所以这无用的99个事件函数代码肯定消耗了很多宝贵的浏览器内存。当然现实开发环境里我们不会这么干的，但是在当今ajax流行，单页面开发疯狂普及的时代，一个网页上的事件都是超级多的，这就意味我们每个事件都有一个事件函数，但是我们每次操作都只会促发一个事件，此时其他事件都是躺着睡觉，起不到任何作用同时还要消耗计算机的内存。

我们需要一种方案改变这种情况，现实中的确有这种方案。为了清晰描述这个方案，我要先补充一些背景知识，在讲述DOM2事件处理里我提到了目标对象这个概念，抛开DOM2事件处理方式，在捕获事件处理和冒泡事件处理里也有目标对象的概念，目标对象就是事件具体操作的DOM元素，例如点击按钮操作里按钮就是目标对象，不管哪个事件处理方式，事件函数都会包含一个event对象，event对象有个属性target，target是永远指向目标对象的，event对象还有个属性就是currentTarget，这个属性指向的是捕获或冒泡事件流动到的DOM元素。由上文描述我们知道，不管是捕获事件还是冒泡事件，事件流都会流动到document上，假如我们在document上添加点击事件，页面上的按钮不添加点击事件，这时候我们点击按钮，我们知道document上的点击事件会促发，这里有个细节就是促发document点击事件时候，event的target的指向是button而不是document，那么我们可以这样写代码：

运行之，我们发现效果和我们单独写按钮事件一样。但是它的好处是不言而喻的，一个函数搞定了整个页面的事件函数，而且没有事件函数被空闲，简直完美，这个方案还有个专业名称：事件委托。jQuery的delegate方法就是按这个原理做的。其实事件委托的效率不仅仅体现在事件函数的减少，它还能减少dom遍历操作，例如上面例子里我们在document上添加函数，document是页面里的顶层对象，读取它的效率是很高的，到了具体的对象事件我们也没有通过dom操作而是使用事件对象的target属性，所有这些只能用一句话概括：真是快，没理由的快。

事件委托还能给我们带来一个很棒副产品，使用过jQuery的朋友都应该用过live方法，live方法特点是你可以为页面元素添加事件操作，哪怕这个元素目前在页面还不存在，你也可以添加它的事件，理解了事件委托机制，live的原理就很好理解了，其实jQuery的live就是通过事件委托做的，同时live还是一种高效的事件添加方式。

理解了事件委托，我们会发现jQuery的bind方法是个低效的方法，因为它使用原始的事件定义方式，所以bind我们要慎用，其实jQuery的开发者也注意到这个问题，新版的jQuery里都有一个on方法，on方法包含了bind、live和delegate方法所有功能，所以我建议看了本文的朋友要摒弃以前使用添加事件的方式，多使用on函数添加事件。

事件委托还有个好处，上文里事件委托的例子我是在document上添加事件，这里我要做个比较，在jQuery里我们习惯把DOM元素事件的定义放在ready方法里，如下所示：

ready函数是在页面DOM文档加载完毕后执行，它比onload函数先执行，这种提前好处很多，好处之一也是带来性能提升，jQuery这种事件定义也算是个标准做法，我相信有些朋友一定又把某些事件绑定放在ready外面，最后发现按钮会无效，这种无效场景有时一刹那，过会儿就好了，所以我们常常忽视了该问题的原理，不在ready函数绑定事件，这个操作其实是在DOM加载完毕之前绑定事件，而这个时间段下，很有可能某些元素还没在页面构造好，所以事件绑定会出现无效情况，因此ready定义事件的道理就是保证页面所有元素加载完毕后在定义DOM元素的事件，但是使用事件委托时可以避免问题的发生，例如将事件绑定在document，document代表整个页面，所以它加载完毕的时间可谓最早，所以在document上实现事件委托，就很难发生事件无效的情况，也很难发生浏览器报出“XXX函数未定义”的问题了。总结一下这个特点：事件委托代码可以运行在页面加载的任何阶段，这点对提升网页性能还是增强网页效果上都会给开发人员提供更大自由度。