提升 web 應用性能之 JavaScript 性能調優
簡介： JavaScript 是一個比較完善的前端開發語言，在現今的 web 開發中應用很是普遍，尤爲是對 Web 2.0 的應用。隨着 Web 2.0 愈來愈流行的今天，咱們會發現：在咱們的 web 應用項目中，會有大量的 JavaScript 代碼，而且之後會愈來愈多。JavaScript 做爲一個解釋執行的語言，以及它的單線程機制，決定了性能問題是 JavaScript 的軟肋，也是 web 軟件工程師們在寫 JavaScript 須要高度重視的一個問題，尤爲是針對 Web 2.0 的應用。絕大多數 web 軟件工程師都或多或少的遇到過所開發的 Web 2.0 應用的性能欠佳的問題，其主要緣由就是 JavaScript 性能不足，瀏覽器負荷太重。可是，解決這種解釋執行而且單線程運做語言的性能問題也並不是易事。這篇文章會着重介紹一些關於開發中 JavaScript 性能調優的技巧和最佳實踐，一樣也會涉及到關於 JavaScript 操做 DOM 節點的性能調優的一些方法 .javascript
本文的標籤： javascript, 優化, 性能, 性能調優css
簡介html
Web 開發中常常會遇到性能的問題，尤爲是針對當今的 Web2.0 應用。JavaScript 是當今使用最爲普遍的 Web 開發語言，Web 應用的性能問題很大一部分都是由程序員寫的 JavaScript 腳本性能不佳所形成的，裏面包括了 JavaScript 語言自己的性能問題，以及其與 DOM 交互時的性能問題。本文主要來探討一下如何儘量多的避免這類問題，從而最大限度的提升 Web 應用的性能。前端
回頁首html5
JavaScript 性能調優java
JavaScript 語言因爲它的單線程和解釋執行的兩個特色，決定了它自己有不少地方有性能問題，因此可改進的地方有很多。程序員
eval 的問題：web
比較下述代碼：ajax
清單 1. eval 的問題
正則表達式
var reference = {}, props = 「p1」;
eval(「reference.」 + props + 「=5」)
var reference = {}, props = 「p1」;
reference[props] = 5 |
有「eval」的代碼比沒有「eval」的代碼要慢上 100 倍以上。
主要緣由是：JavaScript 代碼在執行前會進行相似「預編譯」的操做：首先會建立一個當前執行環境下的活動對象，並將那些用 var 申明的變量設置爲活動對象的屬性，可是此時這些變量的賦值都是 undefined，並將那些以 function 定義的函數也添加爲活動對象的屬性，並且它們的值正是函數的定義。可是，若是你使用了「eval」，則「eval」中的代碼（實際上爲字符串）沒法預先識別其上下文，沒法被提早解析和優化，即沒法進行預編譯的操做。因此，其性能也會大幅度下降。
比較下述代碼：
var func1 = new Function(「return arguments[0] + arguments[1]」);
func1(10, 20);
var func2 = function(){ return arguments[0] + arguments[1] };
func2(10, 20); |
這裏相似以前提到的「eval」方法，這裏「func1」的效率會比「func2」的效率差不少，因此推薦使用第二種方式。
JavaScript 代碼解釋執行，在進入函數內部時，它會預先分析當前的變量，並將這些變量納入不一樣的層級（level），通常狀況下：
局部變量放入層級 1（淺），全局變量放入層級 2（深）。若是進入「with」或「try – catch」代碼塊，則會增長新的層級，即將「with」或「catch」裏的變量放入最淺層（層 1），並將以前的層級依次加深。
參考以下代碼：
var myObj = … ..
… ..
function process(){
var images = document.getElementsByTagName("img"),
widget = document.getElementsByTagName("input"),
combination = [];
for(var i = 0; i < images.length; i++){
combination.push(combine(images[i], widget[2*i]));
}
myObj.container.property1 = combination[0];
myObj.container.property2 = combination[combination.length-1];
} |
這裏咱們能夠看到，「images」，「widget」，「combination」屬於局部變量，在層 1。「document」，「myObj」屬於全局變量，在層 2。
變量所在的層越淺，訪問（讀取或修改）速度越快，層越深，訪問速度越慢。因此這裏對「images」，「widget」，「combination」的訪問速度比「document」，「myObj」要快一些。因此推薦儘可能使用局部變量，可見以下代碼：
var myObj = … ..
… ..
function process(){
var doc = document;
var images = doc.getElementsByTagName("img"),
widget = doc.getElementsByTagName("input"),
combination = [];
for(var i = 0; i < images.length; i++){
combination.push(combine(images[i], widget[2*i]));
}
myObj.container.property1 = combination[0];
myObj.container.property2 = combination[combination.length-1];
} |
咱們用局部變量「doc」取代全局變量「document」，這樣能夠改進性能，尤爲是對於大量使用全局變量的函數裏面。
再看以下代碼：
var myObj = … ..
… ..
function process(){
var doc = document;
var images = doc.getElementsByTagName("img"),
widget = doc.getElementsByTagName("input"),
combination = [];
for(var i = 0; i < images.length; i++){
combination.push(combine(images[i], widget[2*i]));
}
with (myObj.container) {
property1 = combination[0];
property2 = combination[combination.length-1];
}
} |
加上「with」關鍵字，咱們讓代碼更加簡潔清晰了，可是這樣作性能會受影響。正如以前說的，當咱們進入「with」代碼塊時，「combination」便從原來的層 1 變到了層 2，這樣，效率會大打折扣。因此比較一下，仍是使用原來的代碼：
var myObj = … ..
… ..
function process(){
var doc = document;
var images = doc.getElementsByTagName("img"),
widget = doc.getElementsByTagName("input"),
combination = [];
for(var i = 0; i < images.length; i++){
combination.push(combine(images[i], widget[2*i]));
}
myObj.container.property1 = combination[0];
myObj.container.property2 = combination[combination.length-1];
} |
可是這樣並非最好的方式，JavaScript 有個特色，對於 object 對象來講，其屬性訪問層級越深，效率越低，好比這裏的「myObj」已經訪問到了第 3 層，咱們能夠這樣改進一下：
var myObj = … ..
… ..
function process(){
var doc = document;
var images = doc.getElementsByTagName("img"),
widget = doc.getElementsByTagName("input"),
combination = [];
for(var i = 0; i < images.length; i++){
combination.push(combine(images[i], widget[2*i]));
}
var ctn = myObj.container;
ctn.property1 = combination[0];
ctn.property2 = combination[combination.length-1];
} |
咱們用局部變量來代替「myObj」的第 2 層的「container」對象。若是有大量的這種對對象深層屬性的訪問，能夠參照以上方式提升性能。
字符串拼接
常常看到這樣的代碼：
str += 「str1」 + 「str2」 |
這是咱們拼接字符串經常使用的方式，可是這種方式會有一些臨時變量的建立和銷燬，影響性能，因此推薦使用以下方式拼接：
var str_array = []; str_array.push(「str1」); str_array.push(「str2」); str = str_array.join(「」); |
這裏咱們利用數組（array）的「join」方法實現字符串的拼接，尤爲是程序的老版本的 Internet Explore（IE6）上運行時，會有很是明顯的性能上的改進。
固然，最新的瀏覽器（如火狐 Firefox3+，IE8+ 等等）對字符串的拼接作了優化，咱們也能夠這樣寫：
str +=「str1」 str +=「str2」 |
新的瀏覽器對「+=」作了優化，性能略快於數組的「join」方法。在不久的未來更新版本瀏覽器可能對「+」也會作優化，因此那時咱們能夠直接寫：str += 「str1」 + 「str2」。
隱式類型轉換
參考以下代碼：
var str = 「12345678」, arr = [];
for(var i = 0; i <= s.length; i++){
arr.push( str.charAt(i));
} |
這裏咱們在每一個循環時都會調用字符串的「charAt」方法，可是因爲咱們是將常量「12345678」賦值給「str」，因此「str」這裏事實上並非一個字符串對象，當它每次調用「charAt」函數時，都會臨時構造值爲「12345678」的字符串對象，而後調用「charAt」方法，最後再釋放這個字符串臨時對象。咱們能夠作一些改進：
var str = new Stirng(「12345678」), arr = [];
for(var i = 0; i <= s.length; i++){
arr.push( str.charAt(i));
} |
這樣一來，變量「str」做爲一個字符串對象，就不會有這種隱式類型轉換的過程了，這樣一來，效率會顯著提升。
字符串匹配
JavaScript 有 RegExp 對象，支持對字符串的正則表達式匹配。是一個很好的工具，可是它的性能並非很是理想。相反，字符串對象（String）自己的一些基本方法的效率是很是高的，好比「substring」，「indexOf」，「charAt」等等，在咱們須要用正則表達式匹配字符串時，能夠考慮一下：
- 是否可以經過字符串對象自己支持的基本方法解決問題。
- 是否能夠經過「substring」來縮小須要用正則表達式的範圍。
這些方式都可以有效的提升程序的效率。
關於正則表達式對象，還有一點須要注意，參考以下代碼：
for(var i = 0; i <= str_array.length; i++){
if(str_array[i].match(/^s*extra\s/)){
……………………
}
} |
這裏，咱們往「match」方法傳入「/^s*extra\s/」是會影響效率的，它會構建臨時值爲「/^s*extra\s/」的正則表達式對象，執行「match」方法，而後銷燬臨時的正則表達式對象。咱們能夠這樣作：
var sExpr = /^s*extra\s/;
for(var i = 0; i <= str_array.length; i++){
if(str_array[i].match(sExpr)){
……………………
}
} |
這樣就不會有臨時對象了。
setTimeout 和 setInterval
「setTimeout」和「setInterval」這兩個函數能夠接受字符串變量，可是會帶來和以前談到的「eval」相似的性能問題，因此建議仍是直接傳入函數對象自己。
利用提早退出
參考以下兩段代碼：
// 代碼 1
var name = … .;
var source = …… ;
if(source.match(/ …… /)){
……………………………
}
// 代碼 2
var name = … .;
var source = …… ;
if(name.indexOf( … ) &&source.match(/ …… /)){
……………………………
} |
代碼 2 多了一個對「name.indexOf( … )」的判斷，這使得程序每次走到這一段時會先執行「indexOf」的判斷，再執行後面的「match」，在「indexOf」比「match」效率高不少的前提下，這樣作會減小「match」的執行次數，從而必定程度的提升效率。
JavaScript 的開發離不開 DOM 的操做，因此對 DOM 操做的性能調優在 Web 開發中也是很是重要的。
Repaint 也叫 Redraw，它指的是一種不會影響當前 DOM 的結構和佈局的一種重繪動做。以下動做會產生 Repaint 動做：
- 不可見到可見（visibility 樣式屬性）
- 顏色或圖片變化（background, border-color, color 樣式屬性）
- 不改變頁面元素大小，形狀和位置，但改變其外觀的變化
Reflow 比起 Repaint 來說就是一種更加顯著的變化了。它主要發生在 DOM 樹被操做的時候，任何改變 DOM 的結構和佈局都會產生 Reflow。但一個元素的 Reflow 操做發生時，它的全部父元素和子元素都會放生 Reflow，最後 Reflow 必然會致使 Repaint 的產生。舉例說明，以下動做會產生 Repaint 動做：
- 瀏覽器窗口的變化
- DOM 節點的添加刪除操做
- 一些改變頁面元素大小，形狀和位置的操做的觸發
經過 Reflow 和 Repaint 的介紹可知，每次 Reflow 比其 Repaint 會帶來更多的資源消耗，咱們應該儘可能減小 Reflow 的發生，或者將其轉化爲只會觸發 Repaint 操做的代碼。
參考以下代碼：
var pDiv = document.createElement(「div」); document.body.appendChild(pDiv);----- reflow var cDiv1 = document.createElement(「div」); var cDiv2 = document.createElement(「div」); pDiv.appendChild(cDiv1);----- reflow pDiv.appendChild(cDiv2);----- reflow |
這是咱們常常接觸的代碼了，可是這段代碼會產生 3 次 reflow。再看以下代碼：
var pDiv = document.createElement(「div」); var cDiv1 = document.createElement(「div」); var cDiv2 = document.createElement(「div」); pDiv.appendChild(cDiv1); pDiv.appendChild(cDiv2); document.body.appendChild(pDiv);----- reflow |
這裏便只有一次 reflow，因此咱們推薦這種 DOM 節點操做的方式。
關於上述較少 Reflow 操做的解決方案，還有一種能夠參考的模式：
var pDiv = document.getElementById(「parent」); pDiv.style.display = 「none」----- reflow pDiv.appendChild(cDiv1); pDiv.appendChild(cDiv2); pDiv.appendChild(cDiv3); pDiv.appendChild(cDiv4); pDiv.appendChild(cDiv5); pDiv.style.width = 「100px」; pDiv.style.height = 「100px」; pDiv.style.display = 「block」----- reflow |
先隱藏 pDiv，再顯示，這樣，隱藏和顯示之間的操做便不會產生任何的 Reflow，提升了效率。
DOM 元素裏面有一些特殊的測量屬性的訪問和方法的調用，也會觸發 Reflow，比較典型的就是「offsetWidth」屬性和「getComputedStyle」方法。
這些測量屬性和方法大體有這些：
- offsetLeft
- offsetTop
- offsetHeight
- offsetWidth
- scrollTop/Left/Width/Height
- clientTop/Left/Width/Height
- getComputedStyle()
- currentStyle(in IE))
這些屬性和方法的訪問和調用，都會觸發 Reflow 的產生，咱們應該儘可能減小對這些屬性和方法的訪問和調用，參考以下代碼：
var pe = document.getElementById(「pos_element」); var result = document.getElementById(「result_element」); var pOffsetWidth = pe.offsetWidth; result.children[0].style.width = pOffsetWidth; result.children[1].style.width = pOffsetWidth; result.children[2].style.width = pOffsetWidth; …………其餘修改………… |
這裏咱們能夠用臨時變量將「offsetWidth」的值緩存起來，這樣就不用每次訪問「offsetWidth」屬性。這種方式在循環裏面很是適用，能夠極大地提升性能。
咱們確定常常見到以下的代碼：
var sElement = document.getElementById(「pos_element」); sElement.style.border = ‘ 1px solid red ’ sElement.style.backgroundColor = ‘ silver ’ sElement.style.padding = ‘ 2px 3px ’ sElement.style.marginLeft = ‘ 5px ’ |
可是能夠看到，這裏的每個樣式的改變，都會產生 Reflow。須要減小這種狀況的發生，咱們能夠這樣作：
解決方案 1：
.class1 {
border: ‘ 1px solid red ’
background-color: ‘ silver ’
padding: ‘ 2px 3px ’
margin-left: ‘ 5px ’
}
document.getElementById(「pos_element」).className = ‘class1’ ; |
用 class 替代 style，能夠將原有的全部 Reflow 或 Repaint 的次數都縮減到一個。
解決方案 2：
var sElement = document.getElementById(「pos_element」);
var newStyle = ‘ border: 1px solid red; ’ + ‘ background-color: silver; ’ +
‘ padding: 2px 3px; ’ + 「margin-left: 5px;」
sElement.style.cssText += newStyle; |
一次性設置全部樣式，也是減小 Reflow 提升性能的方法。
一個頁面上每每包含 1000 多頁面元素，在定位具體元素的時候，每每須要必定的時間。若是用 id 或 name 定位可能效率不會太慢，若是用元素的一些其餘屬性（好比 className 等等）定位，可能效率有不理想了。有的可能只能經過遍歷全部元素（getElementsByTagName）而後過濾才能找到相應元素，這就更加低效了，這裏咱們推薦使用 XPath 查找元素，這是不少瀏覽器自己支持的功能。
if(document.evaluate){
var tblHeaders = document.evaluate(「//body/div/table//th」);
var result = tblHeaders.iterateNext();
while(result) {
result.style.border = 「1px dotted blue」;
result ………………
result = xpathResult.iterateNext();
}
} else{ //getElementsByTagName() ……
// 處理瀏覽器不支持 XPath 的狀況
………………………………
} |
瀏覽器 XPath 的搜索引擎會優化搜索效率，大大縮短結果返回時間。
這是一類特殊的對象，它們有點像數組，但不徹底是數組。下述方法的返回值通常都是 HTMLCollection 對象：
- document.images, document.forms
- getElementsByTagName()
- getElementsByClassName()
這些 HTMLCollection 對象並非一個固定的值，而是一個動態的結果。它們是一些比較特殊的查詢的返回值，在以下狀況下，它們會從新執行以前的查詢而獲得新的返回值（查詢結果），雖然多數狀況下會和前一次或幾回的返回值都同樣：
- Length 屬性
- 具體的某個成員
因此，HTMLCollection 對象對這些屬性和成員的訪問，比起數組來要慢不少。固然也有例外，Opera 和 Safari 對這種狀況就處理的很好，不會有太大性能問題。
參考以下代碼：
var items = [「test1」, 「test2」, 「test3」, ……………… ];
for(var i = 0; i < items.length; i++){
………………………………
}
var items = document.getElementsByTagName(「div」);
for(var i = 0; i < items.length; i++){
…………………………………… .
} |
上述兩端代碼，下面的效率比起上面一段要慢不少，由於每個循環都會有「items.length」的觸發，也就會致使「document.getElementsByTagName(..)」方法的再次調用，這即是效率便會大幅度降低的緣由。咱們能夠這樣解決：
var items = document.getElementsByTagName(「div」);
var len = items.length
for(var i = 0; i < len; i++){
…………………………………… .
} |
這樣一來，效率基本與普通數組同樣。
加載並執行一段 JavaScript 腳本是須要必定時間的，在咱們的程序中，有時候有些 JavaScript 腳本被加載後基本沒有被使用過 （好比：腳本里的函數歷來沒有被調用等等）。加載這些腳本只會佔用 CPU 時間和增長內存消耗，下降 Web 應用的性能。因此推薦動態的加載 JavaScript 腳本文件，尤爲是那些內容較多，消耗資源較大的腳本文件。
if(needXHR){
document.write(「<script type= ’ test\/JavaScript ’ src= 'dojo_xhr.js' >」);
}
if(dojo.isIE){
document.write(「<script type= ’ test\/JavaScript ’ src= 'vml.js' >」);
} |
這篇文章介紹了 Web 開發中關於性能方面須要注意的一些小細節，從 JavaScript 自己着手，介紹了 JavaScript 中須要避免的一些函數的使用和編程規則，好比 eval 的弊端，function scope chain 以及 String 的用法等等，也分享了一些比較推薦的作法，並擴展到 JavaScript 對 DOM 操做的性能調優，好比利用 Repaint 和 Reflow 的機制，如何使用特殊測量屬性，樣式相關的性能調優以及 HTMLCollection 對象的原理和使用小技巧。這些小細節咱們能夠在開發過程當中儘可能注意一下，以儘量多的提升咱們 Web 應用的性能。
學習
- JavaScript wiki：一個共享 JavaScript 開發知識的網站，提供不少 JavaScript 的實例和解釋。
- JavsScript 資源網站：提供了不少 JavaScript 的開發相關資源，許多不錯的文章以及一些經典實例。
- 「JavaScript 開發工具包」（developerWorks，2010 年 3 月）：JavaScript 開發工具包
- 「編寫更加通用的 JavaScript」（developerWorks，2011 年 2 月）：做者以網頁中常見的下拉列表的實現爲例，介紹了一種讓 JavaScript 變得更加通用的方法：編寫 JavaScript 組件。
- 「使用 JSLint 保證 JavaScript 代碼質量」（developerWorks，2011 年 5 月）：隨着富 Web 前端應用的出現，開發人員不得不從新審視並重視 JavaScript 語言的能力和使用，拋棄過去那種只靠「複製 / 粘貼」經常使用腳本完成簡單前端任務的模式。JavaScript 語言自己是一種弱類型腳本語言，具備相對於 C++ 或 Java 語言更爲鬆散的限制，一切以函數爲中心的函數式編程思想也爲開發人員提供了更加靈活的語法實現。然而，這種靈活性在帶來高效的同時，也成爲初學或者經驗不足的 JavaScript 開發人員的噩夢。形式各異的代碼風格、隱含錯誤的代碼行爲，嚴重影響了總體代碼的可讀性和穩定性，成爲 Web 項目中最爲常見問題之一。
- 「JavaScript 工做線程實現方式」（developerWorks，2011 年 5 月）：隨着 Ajax 應用的流行，瀏覽器所承擔的職責也愈來愈多。一些原來由服務器端執行的計算操做也被遷移到瀏覽器端來執行。經過 JavaScript 工做線程，能夠在不影響頁面自己運行的狀況下，在後臺運行耗時的任務。本文詳細了 JavaScript 工做線程的三種實現方式：使用 setTimeout()、Google Gears 和 Web Worker。
- developerWorks Web development 專區：經過專門關於 Web 技術的文章和教程，擴展您在網站開發方面的技能。
- developerWorks Ajax 資源中心：這是有關 Ajax 編程模型信息的一站式中心，包括不少文檔、教程、論壇、blog、wiki 和新聞。任何 Ajax 的新信息都能在這裏找到。
- developerWorks Web 2.0 資源中心，這是有關 Web 2.0 相關信息的一站式中心，包括大量 Web 2.0 技術文章、教程、下載和相關技術資源。您還能夠經過 Web 2.0 新手入門 欄目，迅速瞭解 Web 2.0 的相關概念。
- 查看 HTML5 專題，瞭解更多和 HTML5 相關的知識和動向。
討論
- 加入 developerWorks 中文社區。查看開發人員推進的博客、論壇、組和維基，並與其餘 developerWorks 用戶交流。