如何能做出高效的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，这个对象有阻止冒泡或捕获事件的方法，我怎么说没有呢？这位朋友的疑问很有道理，但是如果我们要使用该方法减少遍历，那么我们代码就要处理父子元素的关系，爷孙元素关系，如果页面元素嵌套很多，这就是没法完成的任务，所以我的回答是没法改变遍历的问题，只能去适应它。