摘要：語句會使得局部變量位于作用域第二層，會使性能下降，所以應(yīng)避免使用。使用事件委托來減少事件處理器的數(shù)量。把最可能出現(xiàn)的條件放在首位。在進行優(yōu)化時，要弄清楚性能瓶頸，然后對癥優(yōu)化。新看到一篇很棒的文章前端性能優(yōu)化備忘錄如有不對，歡迎指正。

春節(jié)在家，把《高性能的JavaScript》刷了一遍，受益匪淺。本著每看完一本書都要做讀書筆記的習(xí)慣，將書中的知識點總結(jié)一下。

由于不同瀏覽器使用的JavaScript引擎不同，因此對JavaScript的優(yōu)化也不盡相同。也因此，有些方法在IE上可能性能相差很大，但在chrome上相差無幾，也甚至某些方法在IE上最快，但在chrome上卻并不是最優(yōu)的方案，所以，對性能有極致要求的應(yīng)用，應(yīng)考慮你的產(chǎn)品使用者最常用的瀏覽器。當(dāng)然，下面提到的優(yōu)化方法都是通用法則或者對大多數(shù)瀏覽器都友好的方法。

JavaScript的下載和執(zhí)行會阻塞用戶界面的繪制和其他資源的下載

1.阻塞式腳本：合并文件（減少http請求），將script標(biāo)簽放在body尾部（減少頁面css，html的下載阻塞，減少界面的空白時間（瀏覽器在解析到script標(biāo)簽之前，不會渲染頁面的任何部分））

目前流行的構(gòu)建工具，如webpack,gulp，都有打包、合并文件的功能。

2.無阻塞式腳本：延遲腳本和動態(tài)腳本均不阻塞，即下載過程不阻塞其他進程

延遲腳本：
defer和async屬性：都是并行下載，下載過程不阻塞，區(qū)別在于執(zhí)行時機，async是下載完成后立即執(zhí)行；defer是等頁面加載完成后再執(zhí)行。defer僅當(dāng)src屬性聲明時才生效（HTML5的規(guī)范）

動態(tài)腳本：
動態(tài)添加script標(biāo)簽，返回的代碼通常會立刻執(zhí)行，所以，為了確保腳本下載完成且準(zhǔn)備就緒后才執(zhí)行，須偵聽load事件。將script添加到head中比添加到body中更保險。

//動態(tài)添加腳本，當(dāng)腳本下載完成且準(zhǔn)備就緒后執(zhí)行回調(diào)函數(shù)。（這也是推薦的無阻塞的方法）
function loadScript(url,callback){
    var script=document.creatElement("script");
    script.type="text/javascript";
    if(script.readyState){ //IE
        script.onreadystatechange=function(){
            if(script.readyState == "loaded" || script.readyState == "complete"){
                script.onreadystatechange=null;
                callback();
            }
        }
    }else{  //非IE
        script.onload=function(){
            callback();
        }
    }

    script.src=url;
    document.getElementsByTagName("head")[0].appendChild(script);

}

將全局變量存儲到局部變量中：因為全局變量總是存在于執(zhí)行環(huán)境作用域鏈的最末端，所以，訪問全局變量是最慢的，訪問局部變量是最快的。尤其是對于未優(yōu)化過的JavaScript引擎。

在JavaScript中，只有2個語句可以在執(zhí)行時臨時改變作用域鏈：with語句和try-catch的catch子句。with語句會使得局部變量位于作用域第二層，會使性能下降，所以應(yīng)避免使用。try-catch權(quán)衡使用（因為可預(yù)測的錯誤說明代碼有問題，應(yīng)及早修復(fù)）。

盡量避免使用with，try-catch，eval等動態(tài)作用域語句，因為JavaScript引擎無法通過靜態(tài)分析的方法進行優(yōu)化。

閉包會影響性能（作用域鏈加深）和可能導(dǎo)致內(nèi)存泄漏（IE中）

使用對象字面量代替對象

使用局部變量存儲全局變量和對象成員

盡量不用with，eval語句，try-catch的catch子句要謹慎使用

嵌套越深，性能越差，盡量少用。

DOM和JavaScript是2個獨立的功能，只通過API連接，用JavaScript操作DOM天生就慢，所以應(yīng)盡量減少用JavaScript操作DOM。

1.減少訪問DOM的次數(shù)，把運算盡量留在ECMAScript這一端處理。
2.innerHTML在絕大多數(shù)瀏覽器中比原生DOM方法要快（最新版的chrome除外），推薦使用。
3.用element.cloneNode()代替document.createElement()，稍快一些。
4.緩存HTML集合的length.

//這會是一個死循環(huán)，因為取HTML集合的length會重復(fù)執(zhí)行查詢的過程。
    var addDivs=document.getElementsByTagName("div");
    for(var i=0,len=addDivs.length;i
5.使用children代替childNodes，因為childNodes會包含文本節(jié)點（空格）和注釋節(jié)點，還需要自己額外過濾這些節(jié)點，children已經(jīng)幫我們過濾掉這些節(jié)點了，而且使用的過濾方法效率很高。
6.原生選擇器API：querySelectorAll()和querySelector()  ，IE8及以上支持
querySelectorAll()返回的是個nodelist（也是類數(shù)組），不是HTML集合（與getElenmentsByTagName等不同）。
7.減少重繪和重排：
在修改樣式的過程中，最好避免使用下面的屬性,因為它們會刷新渲染隊列，盡量少查詢下列屬性，可以用局部變量緩存結(jié)果。
offsetTop，offsetLeft，offsetWidth，offsetHeight,
scrollTop，scrollLeft，scrollWidth，scrollHeight
clientTop，clientLeft，clientWidth，clientHeight
getComputedStyle()  (currentStyle in IE)
8.合并多次對DOM和樣式的修改：
el.style.cssText+=";border-left:2px;";
JavaScript改變class
9.批量修改DOM時，使用document fragment：文檔片段是一個輕量級的document對象，它本身就是為了更新和移動節(jié)點設(shè)計的。
var fragement=document.createDocumentFragment();
var li=document.createElement("li");
fragement.appendChild(li);
document.body.appendChild(fragement);
10.動畫中使用絕對定位，使用拖放代理。
11.使用事件委托來減少事件處理器的數(shù)量。
ps:個人覺得，原生方法和庫封裝的方法并不沖突，應(yīng)根據(jù)實際情況和個人的技能掌握情況選擇最合適的方法。
算法和流程控制

for...in的循環(huán)性能最差（因為它需要搜索實例和原型上的所有屬性），除非，你需要遍歷一個屬性數(shù)量未知的對象，否則不要使用它。
更不要用它遍歷數(shù)組成員。其余的循環(huán)性能都差不多。

倒序循環(huán)，把減法操作放到控制條件中，例如：k--，這樣只是比較“它是true嗎？”速度更快。

forEach()比數(shù)組循環(huán)慢，如果對性能有極致要求，還是用數(shù)組循環(huán)好。

當(dāng)判斷值多于2個時，使用switch，否則用if-else  （數(shù)量少時，性能差別不大，可根據(jù)個人喜好使用）。若判斷值很多，且沒有什么復(fù)雜的操作，可以用數(shù)組代替switch。
在JavaScript中，switch使用全等操作符，不會發(fā)生類型轉(zhuǎn)換的損耗。

把最可能出現(xiàn)的條件放在首位。

調(diào)用棧溢出錯誤基本都是由遞歸導(dǎo)致的：不正確的終止條件；包含了太多遞歸，超過了瀏覽器的調(diào)用棧限制。把遞歸算法改用迭代算法實現(xiàn)是避免調(diào)用棧溢出錯誤的解決方法之一。

緩存：避免重復(fù)性工作，手動實現(xiàn)緩存（Vue源碼中就有很多緩存）


function memfactorial(n){
    if(!memfactorial.cache){
        memfactorial.cache={
            "0":1,
            "1":1
        }
    }

    if(!memfactorial.cache.hasOwnProperty(n)){
        memfactorial.cache[n]=n* memfactorial(n-1);
    }

    return memfactorial.cache[n];
  }
字符串和正則表達式
字符串拼接推薦用+ +=，推薦寫法：str=str+"one"+"two";(將str寫在左側(cè))
書上說：在大多數(shù)瀏覽器中，Array.prototype.join()比其他字符串連接方法更慢，但在IE7及早期的瀏覽器中，在合并大量字符串時是最高效的途徑。
每個瀏覽器都有它自己的正則表達式引擎，它們有著各自的優(yōu)勢。
提高正則表達式效率的方法

關(guān)注如何讓匹配更快失敗

正則表達式以簡單，必需的字元開始：例如：起始標(biāo)記是^，特定字符串，[a-z]或者d等，避免以分組或選擇字元開頭，避免/one|two/頂層分支。

減少分支數(shù)量，縮小分支范圍：例如：將cat|bat 替換為：[cb]at  ;將red|read 替換為：rea?d   將red|raw 替換為：r(?:ed|aw)  將（.|r|n）替換為：[sS]。

當(dāng)分支必不可少時，將常用分支放到前面。

使用非捕獲組

合理使用捕獲：如果需要引用匹配的一部分，應(yīng)用捕獲，然后引用那部分

暴露必須的字元：用/^(ab|cd)/代替/(^ab|^cd)/

使用合適的量詞：貪婪和惰性量詞的匹配過程不一樣，視情況選擇使用。

將正則表達式賦值給變量（以避免對正則重新編譯）并重用它們。

將復(fù)雜的正則拆分為簡單的片段：如果太復(fù)雜，可以先用條件判斷分割


//去除字符串首尾空格的方法，推薦寫法
if(!String.prototype.trim){    //防止覆蓋原生方法
        String.prototype.trim=function(){
            return this.replace(/^s+/,"").replace(/s+$/,"");
        }
   }
盡管正則很強大，但也不是任何時候都要用正則。對于字面量字符串的操作，字符串原生的方法就很快，例如：indexOf，slice，substring等。
其他

建議定時器最小延遲時間是25ms.小于10ms時，各瀏覽器表現(xiàn)不一致。

多個定時器時，用setInterval()代替多個setTimeout()

使用動態(tài)腳本注入（json-p），要小心第三方域代碼的安全性。不要把敏感信息編碼在json-p中。即便是帶有隨機URL或做了cookie判斷。


圖片信標(biāo)：只是用來發(fā)送簡單數(shù)據(jù)
  //只是創(chuàng)建一個Image對象，并不把img插入DOM中。
（new Image()）.src=url+params.join("&");


盡可能使用JOSN.parse()解析json字符串，該方法可以捕獲json字符串中的詞法錯誤，并允許傳入一個函數(shù)用來過濾或轉(zhuǎn)換解析結(jié)果。

ajax類庫的局限：ajax類庫為了兼容瀏覽器，所以不能訪問XMLHttpRequests的完整功能。例如不能直接訪問readystatechange事件，所以要了解原生的寫法。
所以，要知道何時使用成熟的類庫，何時編寫自己的底層代碼。

縮短頁面的加載時間，頁面主要內(nèi)容加載完成后，再用ajax獲取那些次要的文件。（首頁優(yōu)化）

通過正確設(shè)置響應(yīng)頭來緩存JavaScript文件。

使用位操作，速度快。


    i%2   
    //可以改寫成位運算 &1 ：
    if(i&1){ 
        //奇數(shù)
    }else{ 
        //偶數(shù)
    }
    //位掩碼：后臺常用的按位打標(biāo)，
    var ops=op_a | op_b | op_c;  
    if(ops & op_a){ 
        //op_a存在
    }
個人感想
性能提升有多方面：客戶端性能，網(wǎng)絡(luò)情況，服務(wù)器性能，在具體解決及分析問題時，要從各個方面考慮，JavaScript代碼質(zhì)量，http請求數(shù)也只是其中一部分而已，要全面考慮。在進行優(yōu)化時，要弄清楚性能瓶頸，然后對癥優(yōu)化。
新看到一篇很棒的文章：
前端性能優(yōu)化備忘錄：https://www.w3ctech.com/topic...  
ps:如有不對，歡迎指正。