我所經曆的JS效能最佳化

標籤：

轉自http://www.cnblogs.com/koking/archive/2011/10/17/2215665.html

　　 折騰了好幾天，糾結了好幾天，鬱悶了好幾天，終於在今天可以釋懷了，留下其中的苦樂辛酸來和大家分享。

　　 事情是這樣子的，上周接到一個需求，其中涉及到一個好友選擇的組件，就是單機左側某個群組下的好友後該好友移動到右側，視為選擇了它，另外每個群組還有全選，摺疊和展開等功能。組件在開發過程中,遇到了在2000條資料的時候，搜尋會變的很卡，IE8下為2s左右，IE6更長，我在最初的最佳化過程中我使用事件代理，文檔片段，字串數組，少建立對象，緩衝一切可以緩衝的，用hash超找代替數組尋找等方式，但是一直沒有找到效能的瓶頸所在，所以效果不大，後來採用了setTimeout的方式，就是限制js的執行時間，當它超過規定的時間後記錄當前的執行狀態，然後setTimeout延遲一段時間再執行，而把延時的這段時間交給UI線程，這樣做後確實不卡了，但是因為出現延時調用，搜尋的總體時間變長了，試想讓使用者等十多秒來看搜尋的結果這樣做也太不合理，問題一直沒有得到根本的解決。

       後來，在johnnie和youkun的協助和提示下，我找到了最佳化的入口就是找效能瓶頸，就是如果一個段代碼很耗時的話你可以注釋掉一部分你認為是很耗時的，或者乾脆全部注釋掉，然後再一點一點的解開，按照這個思路，我發現在我的迴圈搜尋中頻繁進行了dom操作，就比如搜尋使用者提交的一個queryString，我的方法是在資料中遍曆所有的item，如果匹配，就通過這條資料找到這個item對應的dom，然後顯示它，不匹配就隱藏它，然後每個組搜尋完還要更新該組搜尋的結果數，這裡面涉及到選擇dom，然後顯示或者隱藏它等，正是這些dom操作在大資料量的時候使得搜尋操作變得很慢，當時我實驗了下，就算在迴圈中只執行一個document.getElementById也很耗時，找到了問題的根源所在，接下來的最佳化就有了方向，於是在v3版本中我改變了搜尋的策略，迴圈遍曆的時候只拼接dom，在迴圈結束後一次性的放到文檔中，經過測速，迴圈遍曆拼接dom只用了不超過60ms，而把這一大段html放到文檔中這一個操作在IE下耗時250ms左右，雖然離大師們推薦的100ms還有差距，但是相對v2的2s提升了很多，我也終於鬆了一口氣了。
     小結：其實js最佳化一定要掌握方法，沒有正確的方法可能做了很多工作都是偏離主題的，按照正確的最佳化方法來最佳化就會定位效能瓶頸，然後對其採取進行有效 最佳化措施，而js最佳化中最主要的還是對dom操作的最佳化，單純的js執行時間是很短的，而js和dom之間的互動是通過介面來完成，通過介面來完成的都會 有延時，所以要盡量減少dom操作，尤其是在大迴圈中。
     最後，總結下常見的dom操作的最佳化方法（節選自高效能JavaScript）

     1  最小化dom訪問次數，儘可能在js端執行；
     2  如果需要多次訪問某個dom節點，請使用局部變數儲存對它的引用；
     3  小心處理html集合，因為它即時連繫著底層的文檔，把集合的長度緩衝到一個變數中，並在迭代中使用它，如果需要經常操作集合，建議把它拷貝到一個數組中；
     4  如果可能的話，使用速度更快的API，比如querySelectorAll和firstElementChild；
     5  要留意重繪和重排；批量修改樣式時，“離線”操作dom樹；使用緩衝，並減少訪問布局的次數；
     6  動畫中使用絕對位置，使用拖放代理
     7  使用事件委託來減少事件處理器的數量

     總結下js中對資料訪問的最佳化（節選自高效能JavaScript）

     1  函數中讀寫局部變數總是最快的，而全域變數的讀取則是最慢的；
     2  儘可能地少用with 語句，因為它會增加with 語句以外的資料的訪問代價；
     3  閉包儘管強大，但不可濫用，否則會影響到執行速度以及記憶體；
     4  嵌套的對象成員會明顯影響效能，盡量少用；
     5  避免多次訪問對象成員或函數中的全域變數，盡量將它們賦值給局部變數以緩衝。

 

  

我所經曆的JS效能最佳化