高性能JS-DOM

用脚本进行DOM操做的代价是很昂贵的，它是富web应用中最多见的性能瓶颈。主要有如下三种问题：

1. 访问和修改DOM元素

2. 修改DOM元素的样式致使repaint和reflow

3. 经过DOM事件处理与用户进行交互

浏览器中的DOM

DOM是（Document Object Model）一个与语言无关的、用来操做XML和HTML文档的应用程序接口（Application Program Interface）。 尽管DOM与语言无关，可是在浏览器中的接口倒是用JavaScript来实现的。

一个前端小知识

浏览器一般会把js和DOM分开来分别独立实现。
举个栗子冷知识，在IE中，js的实现名为JScript，位于jscript.dll文件中；DOM的实现则存在另外一个库中，名为mshtml.dll（Trident）。
Chrome中的DOM实现为webkit中的webCore，但js引擎是Google本身研发的V8。
Firefox中的js引擎是SpiderMonkey，渲染引擎（DOM）则是Gecko。

DOM，天生就慢

前面的小知识中说过，浏览器把实现页面渲染的部分和解析js的部分分开来实现，既然是分开的，一旦二者须要产生链接，就要付出代价。
两个例子：

1. 小明和小红是两个不一样学校的学生，两我的家里经济条件都不太好，买不起手机（好尴尬的设定Orz...），因此只能经过写信来互相交流，这样的过程确定比他俩面对面交谈时所须要花费的代价大（额外的事件、写信的成本等）。

2. 官方例子：把DOM和js（ECMAScript）各自想象为一座岛屿，它们之间用收费桥进行链接。ECMAScript每次访问DOM，都要途径这座桥，并交纳“过桥费”。访问DOM的次数越多，费用也就越高。

所以，推荐的作法是：尽量的减小过桥的次数，努力待在ECMAScript岛上。

DOM的访问与修改

前面说到访问DOM须要交纳“过桥费”，而修改DOM元素则代价更为昂贵，由于它会致使浏览器从新计算页面的几何变化。 来看一段代码：

function innerHTMLLoop(){      for (var count = 0; count < 15000; count++){          document.getElementById('text').innerHTML += 'dom';      }   }

这段代码，每次循环会访问两次特定的元素：第一次读取这个元素的innerHTML属性，第二次重写它。
看清楚了这一点，不可贵到一个效率更高的版本：

function innerHTMLLoop2(){      var content = '';      for (var count = 0; count < 15000; count++){          content += 'dom';      }      document.getElementById('text').innerHTML += content;   }

用一个局部变量包层每次更新后的内容，等待循环结束后，一次性的写入页面（尽量的把更多的工做交给js的部分来作）。
根据统计，在全部的浏览器中，修改后的版本都运行的更快（优化幅度最明显的是IE8，使用后者比使用前者快273倍）。

HTML元素集合

HTML元素集合是包含了DOM节点引用的类数组对象。
能够用如下方法或属性获得一个HTML元素集合：

• document.getElementsByName()

• document.getElementsByTagName()

• document.getElementsByClassName()

• document.images 页面中全部img元素

• document.links 页面中全部a元素

• document.forms 页面中全部表单元素

• document.forms[0].elements 页面中第一个表单的全部字段

HTML元素集合处于一种“实时的状态”，这意味着当底层文档对象更新时，它也会自动更新，也就是说，HTML元素集合与底层的文档对象之间保持的链接。正因如此，每当你想从HTML元素集合中获取一些信息时，都会产生一次查询操做，这正是低效之源。

昂贵的集合

//这是一个死循环  //无论你信不信，反正我是信了  var alldivs = document.getElementsByTagName('div');  for (var i = 0; i < alldivs.length; i++){      document.body.appendChild(document.createElement('div'));   }

乍一看，这段代码只是单纯的把页面中的div数量翻倍：遍历全部的div，每次建立一个新的div并建立到添加到body中。
但事实上，这是一个死循环：由于循环的退出条件alldivs.length在每一次循环结束后都会增长，由于这个HTML元素集合反映的是底层文档元素的实时状态。
接下来，咱们经过这段代码，对一个HTML元素集合作一些处理：

function toArray(coll){      for (var i = 0, a = [], len = coll.lengthl i < len; i++){          a[i] = coll[i];      }      return a;   }    //将一个HTML元素集合拷贝到一个数组中  var coll = document.getElementsByTagName('div');  var arr = toArray(coll);

如今比较如下两个函数：

function loopCollection(){      for (var count = 0; count < coll.length; count++){          //processing...      }   }    function loopCopiedArray(){      for (var count = 0; count < arr.length; count++){          //processing...      }   }

在IE6中，后者比前者快114倍；IE7中119倍；IE8中79倍...
因此，在相同的内容和数量下，遍历一个数组的速度明显快于遍历一个HTML元素集合。
因为在每一次迭代循环中，读取元素集合的length属性会引起集合进行更新，这在全部的浏览器中都有明显的性能问题，因此你也能够这么干：

function loopCacheLengthCollection(){      var coll = document.getElementsByTagName('div'),          len = coll.length;      for (var count = 0; count < len; count++){          //processing...      }   }

这个函数和上面的loopCopiedArray()同样快。

访问集合元素时使用局部变量

通常来讲，对于任何类型的DOM访问，当同一个DOM属性或者方法须要被屡次访问时，最好使用一个局部变量缓存此成员。当遍历一个集合时，首要优化原则是把集合存储在局部变量中，并把length缓存在循环外部，而后使用局部变量访问这些须要屡次访问的元素。
一个栗子，在循环之中访问每一个元素的三个属性。

function collectionGlobal(){      var coll = document.getElementsByTagName('div'),          len = coll.length,          name = '';      for (var count = 0; count < len; count++){          name = document.getElementsByTagName('div')[count].nodeName;          name = document.getElementsByTagName('div')[count].nodeType;          name = document.getElementsByTagName('div')[count].tagName;          //个人天不会有人真的这么写吧...      }      return name;   }

上面这段代码，你们不要当真...正常人确定是写不出来的...这里是为了对比一下，因此把这种最慢的状况写给你们看。
接下来，是一个稍微优化了的版本：

function collectionLocal(){      var coll = document.getElementsByTagName('div'),          len = coll.length,          name = '';      for (var count = 0; count < length; count++){          name = coll[count].nodeName;          name = coll[count].nodeType;          name = coll[count].tagName;      }      return name;   }

此次就看起来正常不少了，最后是此次优化之旅的最终版本：

function collectionNodesLocal(){      var coll = document.getElementsByTagName('div'),          len = coll.length,          name = '',          ele = null;      for (var count = 0; count < len; count++){          ele = coll[count];          name = ele.nodeName;          name = ele.nodeType;          name = ele.tagName;      }      return name;   }

遍历DOM

在DOM中爬行

一般你须要从某一个DOM元素开始，操做周围的元素，或者递归查找全部的子节点。
考虑下面两个等价的栗子：

//1  function testNextSibling(){      var el = document.getElementById('mydiv'),          ch = el.firstChild,          name = '';      do {          name = ch.nodeName;      } while (ch = ch.nextSibling);      return name;   }    //2  function testChildNodes(){      var el = document.getElementById('mydiv'),          ch = el.childNodes,          len = ch.length,          //childNodes是一个元素集合，所以在循环中主席缓存length属性以免迭代更新          name = '';      for (var count = 0; count < len; count++){          name = ch[count].nodeName;      }      return name;   }

在不一样浏览器中，两种方法的运行时间几乎相等。但在老版本的IE浏览器中，nextSibling的性能比childNodes更好一些。

元素节点

咱们知道，DOM节点有如下五种分类：

• 整个文档是一个文档节点

• 每一个HTML元素是元素节点

• HTML元素内的文本是文本节点

• 每一个HTML属性是属性节点

• 注释是注释节点

诸如childNodes、firstChild、nextSibling这些DOM属性是不区分元素节点和其余类型的节点的，但每每咱们只须要访问元素节点，此时须要作一些过滤的工做。事实上，这些类型检查的过程都是没必要要的DOM操做。
许多现代浏览器提供的API只返回元素节点，若是可用的话推荐直接只用这些API，由于它们的执行效率比本身在js中过滤的效率要高。

0. 现代浏览器提供的API（被替换的API）

1. children(childNodes)

2. childElementCount (childNodes.length)

3. firstElementChild (firstChild)

4. lastElementChild (lastChild)

5. nextElementSibling (nextSibling)

6. previousElementSibling (previousSibling)

使用这些新的API，能够直接获取到元素节点，也正是所以，其速度也更快。

选择器API

有时候为了获得须要的元素列表，开发人员不得不组合调用getElementById、getElementsByTagName，并遍历返回的节点，但这种繁密的过程效率低下。
最新的浏览器提供了一个传递参数为CSS选择器的名为querySelectorAll()的原生DOM方法。这种方式天然比使用js和DOM来遍历查找元素要快的多。
好比，

var elements = document.querySelectorAll('#menu a');

这一段代码，返回的是一个NodeList————包含着匹配节点的类数组对象。与以前不一样的是，这个方法不会返回HTML元素集合，所以返回的节点不会对应实时的文档结构，也避免了以前因为HTML集合引发的性能（潜在逻辑）问题。
若是不使用querySelectorAll()，咱们须要这样写：

var elements = document.getElementById('menu').getElementsByTagName('a');

不只写起来更麻烦了，更要注意的是，此时的elements是一个HTML元素集合，因此还须要把它copy到数组中，才能获得一个与前者类似的静态列表。
还有一个querySelector()方法，用来获取第一个匹配的节点。

重绘与重排（Repaints & Reflows）

浏览器用来显示页面的全部“组件”，有：HTML标签、js、css、图片——以后会解析并生成两个内部的数据结构：

• DOM树（表示页面结构）

• 渲染树（表示DOM节点应该如何表示）

DOM树中的每个须要显示的节点在渲染树中至少存在一个对应的节点。
渲染树中的节点被称为“帧（frames）”或“盒（boxes）”，符合css盒模型的定义，理解页面元素为一个具备padding、margin、borders和position的盒子。
一旦渲染树构建完成，浏览器就开始显示页面元素，这个过程称为绘制（paint）。

当DOM的变化影响了元素的几何属性（宽、高）——好比改变改变了边框的宽度或者给一个段落增长一些文字致使其行数的增长——浏览器就须要从新计算元素的几何属性，一样，页面中其余元素的几何属性和位置也会所以受到影响。
浏览器会使渲染树中收到影响的部分消失，从新构建渲染树，这个过程称为“重排(reflow)”。重排完成以后，浏览器会从新将受到影响的部分绘制到浏览器中，这个过程称之为“重绘(repaint)”。

若是改变的不是元素的几何属性，如：改变元素的背景颜色，不会发生重排，只会发生一次重绘，由于元素的布局并无改变。
无论是重绘仍是重排，都是代价昂贵的操做，它们会致使web应用程序的UI反应迟钝，应当尽量的减小这类过程的发生。

重排什么时候发生？

• 添加或删除可见的DOM元素

• 元素位置的改变

• 元素尺寸的改变（padding、margin、border、height、width）

• 内容改变（文本改变或图片尺寸改变）

• 页面渲染器初始化

• 浏览器窗口尺寸改变

• 滚动条的出现（会触发整个页面的重排）

最小化重绘和重排

改变样式

一个栗子：

var el = document.getElementById('mydiv');   el.style.borderLeft = '1px';   el.style.borderRight = '2px';   el.style.padding = '5px';

示例中，元素的三个样式被改变，并且每个都会影响元素的几何结构。在最糟糕的状况下，这段代码会触发三次重排（大部分现代浏览器为此作了优化，只会触发一次重排）。从另外一个角度看，这段代码四次访问DOM，能够被优化。

var el = document.getElementById('mydiv');  //思路：合并全部改变而后一次性处理  //method_1:使用cssText属性  el.style.cssText = 'border-left: 1px; border-right: 2px; padding: 5px';    //method_2:修改类名  el.className = 'anotherClass';

批量修改DOM

当你须要对DOM元素进行一系列操做的时候，不妨按照以下步骤：

1. 使元素脱离文档流

2. 对其应用多重改变

3. 把元素带回文档中

上面的这一套组合拳中，第一步和第三部分别会触发一次重排。可是若是你忽略了这两个步骤，那么在第二步所产生的任何修改都会触发一次重排。

在此安利三种可使DOM元素脱离文档流的方法：

• 隐藏元素

• 使用文档片断（document fragment）在当前DOM以外构建一个子树，再把它拷贝回文档

• 将原始元素拷贝到一个脱离文档的节点中，修改副本，完成后再替换原始元素

让动画元素脱离文档流

通常状况下，重排只影响渲染树中的一小部分，但也可能影响很大的一部分，甚至是整个渲染树。
浏览器所需的重排次数越少，应用程序的响应速度也就越快。
想象这样一种状况，页面的底部有一个动画，会推移页面整个余下的部分，这将是一次代价昂贵的大规模重排！用户也势必会感受到页面一卡一卡的。
所以，使用如下步骤能够避免页面中的大部分重排：

1. 使用绝对定位让页面上的动画元素脱离文档流

2. 动画展现阶段

3. 动画结束时，将元素恢复定位。

IE的:hover

从IE7开始，IE容许在任何元素上使用:hover这个css选择器。
然而，若是你有大量元素使用了:hover，你会发现，贼喇慢！

事件委托（Event Delegation）

这一个优化手段也是在前端求职面试中的高频题目。
当页面中有大量的元素，而且这些元素都须要绑定事件处理器。
每绑定一个事件处理器都是有代价的，要么加剧了页面负担，要么增长了运行期的执行时间。再者，事件绑定会占用处理时间，并且浏览器须要跟踪每一个事件处理器，这也会占用更多的内存。还有一种状况就是，当这些工做结束时，这些事件处理器中的绝大多数都是再也不须要的（并非100%的按钮或连接都会被用户点击），所以有不少工做是没有必要的。
事件委托的原理很简单——事件逐层冒泡并能被父级元素捕获。
使用事件委托，只须要给外层元素绑定一个处理器，就能够处理在其子元素上触发的全部事件。
有如下几点须要注意：

• 访问事件对象，判断事件源

• 按需取消文档树中的冒泡

• 按需阻止默认动做

小结

访问和操做DOM须要穿越链接ECMAScript和DOM两个岛屿之间的桥梁，为了尽量的减小“过桥费”，有如下几点须要注意：

• 最小化DOM访问次数

• 对于须要屡次访问的DOM节点，使用局部变量存储其引用

• 若是要操做一个HTML元素集合，建议把它拷贝到一个数组中

• 使用速度更快的API：好比querySelectorAll

• 留意重排和重绘的次数

• 事件委托