JS進階篇3---函數「節流」 VS 「防抖」

「函數節流」和「函數防抖」的對比分析

1、前言

前端開發中，「函數節流（throttle）」 和 「函數防抖（debounce）」 做爲經常使用的性能優化方法，二者都是用於優化高頻率執行 js 代碼的手段，那具體它們有什麼異同點呢？有對這兩個概念不太瞭解的小夥伴，能夠移步本人以前所寫的 JS進階篇1---函數節流（throttle） 和 JS進階篇2---函數防抖（debounce）。

2、背景介紹

你們都知道，液晶顯示器的屏幕刷新率一般爲 60Hz ，即每秒屏幕內容刷新 60 次，那爲何是 60 次，而不是 30 次，或者 90 次呢？這是由於，當液晶顯示器的屏幕刷新率爲 60Hz 的時候（這裏只討論液晶顯示器），人肉眼不再能察覺出屏幕的閃爍現象，低於這個刷新頻率畫面會有卡頓現象，而高於這個頻率的話，又會形成額外的資源和能源浪費，所以，液晶顯示器的默認屏幕刷新率爲 60Hz。

同理，在前端開發過程當中，有一些會被高頻觸發的事件，例如 resize、scroll、mousemove 等，但有些時候咱們並不但願在事件持續觸發的過程當中那麼頻繁地去執行函數，達到必定頻率就足夠了，由於超過這個頻率以後，不管代碼執行多少次，帶來的效果也是同樣，因此倒不如把 js 代碼的執行次數控制在合理的範圍。這樣既能夠節省計算機資源，又能夠保證瀏覽的流暢性，這就是 「函數節流」 和 「函數防抖」 要解決的問題。

3、異同分析

相同點

---

• 實現：均可以經過使用 setTimeout 實現。
• 目的：都是爲了下降回調函數執行頻率，節省計算機資源，優化性能，提高用戶體驗。
• 本質：都是經過減小實際邏輯處理過程的執行來提升事件處理函數運行性能的手段，實質上並未減小事件觸發次數。

不一樣點

---

一、概念不一樣

• 函數節流：必定時間內，控制 js 方法只執行一次。（例如：一般每隔一段時間，如 3s，人就會眨一次眼睛）。
• 函數防抖：事件頻繁觸發的狀況下，只有通過足夠的空閒時間，才執行代碼一次。（舉個栗子：乘坐電梯時，電梯只有檢測到沒有人進入，並通過一段時間以後（例如 10s），纔會關閉電梯入口運行）。

---

二、實現方式不一樣

• 函數節流：聲明一個變量當標誌位，記錄當前代碼是否在執行。若是空閒，則能夠正常觸發方法執行。若是代碼正在執行，則取消此次方法執行，直接 return。
• 函數防抖：須要一個 setTimeout 來輔助實現，延遲執行須要執行的代碼。若是方法屢次觸發，則把上次記錄的延遲執行代碼用 clearTimeout 清掉，從新開始計時。若是在計時期間事件沒有被從新觸發，才執行代碼一次。

---

三、要點不一樣

• 函數節流：函數節流的要點是，聲明一個變量當標誌位，記錄當前代碼是否在執行。
• 函數防抖：用 setTimeout 函數作緩存池，並且能夠輕易地清除待執行的代碼。

---

四、使用場景不一樣

• 「函數節流」 使用場景

  • 百度搜索框的輸入聯想功能
  • 防止高頻點擊提交，防止表單重複提交
  • 懶加載、加載更多、圖片瀑布流或監聽滾動條位置

• 「函數防抖」 使用場景

  • 用戶名、手機號、郵箱輸入驗證
  • 搜索框輸入關鍵字後，只需用戶最後一次輸入完，再發送請求
  • 改變瀏覽器窗口大小時，只需窗口調整完成後，再執行 resize 事件中的函數，計算窗口大小，從新排布元素，防止重複渲染。

心得總結

　　不論是 「函數節流」 仍是 「函數防抖」，都是用來進行性能優化的方式，也都是在項目開發過程當中，爲了解決開發中的實際問題而慢慢發展而來的，必定要在合適的場合才用正確的方法使用它們，切忌濫用，否則不只不會發揮它們該有的做用，還會影響代碼執行的正確性。有疑問或者建議，記得在評論區提出哦，歡迎留言！