《高性能Javascript》 Summary（二）

 

第四章、算法和流程控制 Algorithms And Flow Control

緣由：代碼總體結構是執行速度的決定因素之一。代碼量少不必定運行速度快，代碼量多不必定運行速度慢。性能損失與組織代碼和具體問題解決辦法直接相關。

解決：

1. 與其餘編程語言同樣，代碼的寫法和算法選用影響JavaScript的運行時間。與其餘編程語言不一樣是，JavaScript可用的資源有限，因此優化的技術更爲重要。
2. For, While, Do while循環特性類似，誰也沒必要誰更快或更慢。
3. 除非迭代遍歷一個未知的屬性, 不然不用for in 循環(效率低)。
4. 通常來講，switch 比if else 效率高，但判斷條件少時用if else結構更好。
5. 當判斷條件多時，查表法比if else或者switch速度更快。
6. 瀏覽器調用棧尺寸限制了遞歸算法在JavaScript中的應用，棧溢出錯誤致使其餘代碼也不能正常執行。
7. 若是遇到棧溢出錯誤，將方法修改成一個迭代算法或者使用製表法能夠避免重複工做。
8. 運行的代碼總量越大，使用這些策略帶來的性能提高越明顯。

 

 

第五章、字符串和正則表達式 String and Regular Expressions

問題： 密集的字符串操做和粗劣的編寫正則表達式多是主要的性能障礙。

解決：

1. 當鏈接數量巨大或者尺寸巨大的字符串時，數組聯合是IE7和它早期版本上惟一具備合理性能的方法。
2. 若是不關心IE7和早期版本，數組聯合則是最慢的方法之一。使用簡單的+和+=取而代之，能夠避免產生沒必要要的中間字符串。
3. 回溯既是正則表達式匹配功能的基本組成之一，又是正則表達式影響效率的常見緣由。
4. 避免回溯失控：使用鄰字元互斥，避免嵌套量詞對一個字符串的相同部分屢次匹配，經過重複利用前瞻操做的原子特性除去沒必要要的回溯。
5. 正則表達式不老是完成工做的最佳選擇，好比當你搜索一個字符串的時候。

 

第六章、響應接口 Responsive Interfaces

問題： 網頁應用程序響應的速度是一個重要的性能關注點。

建議：

1. Javascript運行時間不能超過100毫秒，過長的運行時間可能致使UI更新出現可觀察的延遲，從而對總體用戶體驗產生負面影響。
2. Javascript運行期間，瀏覽器響應用戶交互的行爲存在差別。不管無何，Javascript長時間運行將致使用戶混亂和脫節。
3. 定時器可用於安排代碼推遲執行，它使得你能夠將長運行腳本分解成一系列較小的任務。
4. 網頁工人線程（worker）是新式瀏覽器才支持的特性，他容許你在UI進程以外運行Javascript代碼和避免鎖定了UI。
5. 網頁程序越複雜，積極主動的管理UI線程就越顯得重要。沒有什麼Javascript代碼能夠重要到容許影響用戶體驗的程度。

 

第七章、Ajax --異步的Javascript 和 xml

問題： Ajax是高性能Javascript的基石。他能夠經過延遲下載和異步下載，是頁面加載更快。

建議：

1. 做爲數據格式，純文本和HTML是高度限制的，但他們能夠節省客戶端CPU週期。XML被普遍應用廣泛支持，但它很是冗長且解析緩慢。JSON是輕量級的，解析迅速，交互性與XML至關。字符分隔的自定義格式很是輕量，在大量數據解析時速度最快，但須要編寫額外的程序在服務器端構造格式，並在客戶端解析。
2. 當從頁面域請求數據時，XML提供最完善的控制和靈活性，儘管它將全部傳入的數據視爲一個字符串，這有可能下降解析速度。另外一方面，動態腳本標籤插入技術容許跨域請求和本地運行Javascript和Json，雖然它的接口不夠安全，並且不能讀取信息頭或響應報文代碼。多部分的XHR能夠減小請求的數量，能夠在單次響應中處理不一樣的文件類型，儘管它不能緩存到響應報文中。當發送數據時，圖像燈標（使用image標籤發送請求）是最簡單和最有效的方法。XHR也能夠用POST發送大量數據。
3. 減小請求數量，可經過Javascript和CSS文件打包，或者使用XHR。
4. 縮短頁面的加載時間，在頁面其餘內容加載以後，使用Ajax獲取少許重要文件。
5. 確保錯誤代碼不要直接顯示給用戶，並在服務器端處理錯誤。
6. 學會什麼時候使用一個健壯的Ajax庫，什麼時候編寫本身的底層Ajax代碼。

 

 

《高性能Javascript》 Summary（三）