上一節我們一起通過監聽滾動事件，實現了各大網站喜聞樂見的懶加載效果。但我們提到，scroll 事件是一個非常容易被反復觸發的事件。其實不止 scroll 事件，resize 事件、鼠標事件（比如 mousemove、mouseover 等）、鍵盤事件（keyup、keydown 等）都存在被頻繁觸發的風險。 頻繁觸發回調導致的大量計算會引發頁面的抖動甚至卡頓。為了規避這種情況，我們需要一些手段來控制事件被觸發的頻率。就是在這樣的背景下，throttle（事件節流）和 debounce（事件防抖）出現了。 ## “節流”與“防抖”的本質 這兩個東西都以**閉包**的形式存在。 它們通過對事件對應的回調函數進行包裹、以自由變量的形式緩存時間信息，最后用 setTimeout 來控制事件的觸發頻率。 ## Throttle： 第一個人說了算 throttle 的中心思想在于：在某段時間內，不管你觸發了多少次回調，我都只認第一次，并在計時結束時給予響應。 先給大家講個小故事：現在有一個旅客剛下了飛機，需要用車，于是打電話叫了該機場唯一的一輛機場大巴來接。司機開到機場，心想來都來了，多接幾個人一起走吧，這樣這趟才跑得值——我等個十分鐘看看。于是司機一邊打開了計時器，一邊招呼后面的客人陸陸續續上車。在這十分鐘內，后面下飛機的乘客都只能乘這一輛大巴，十分鐘過去后，不管后面還有多少沒擠上車的乘客，這班車都必須發走。 在這個故事里，“司機” 就是我們的節流閥，他控制發車的時機；“乘客”就是因為我們頻繁操作事件而不斷涌入的回調任務，它需要接受“司機”的安排；而“計時器”，就是我們上文提到的以自由變量形式存在的時間信息，它是“司機”決定發車的依據；最后“發車”這個動作，就對應到回調函數的執行。 總結下來，所謂的“節流”，是通過在一段時間內**無視后來產生的回調請求**來實現的。只要一位客人叫了車，司機就會為他開啟計時器，一定的時間內，后面需要乘車的客人都得排隊上這一輛車，誰也無法叫到更多的車。 對應到實際的交互上是一樣一樣的：每當用戶觸發了一次 scroll 事件，我們就為這個觸發操作開啟計時器。一段時間內，后續所有的 scroll 事件都會被當作“一輛車的乘客”——它們無法觸發新的 scroll 回調。直到“一段時間”到了，第一次觸發的 scroll 事件對應的回調才會執行，而“一段時間內”觸發的后續的 scroll 回調都會被節流閥無視掉。 理解了大致的思路，我們現在一起實現一個 throttle： ``` // fn是我們需要包裝的事件回調, interval是時間間隔的閾值 function throttle(fn, interval) { // last為上一次觸發回調的時間 let last = 0 // 將throttle處理結果當作函數返回 return function () { // 保留調用時的this上下文 let context = this // 保留調用時傳入的參數 let args = arguments // 記錄本次觸發回調的時間 let now = +new Date() // 判斷上次觸發的時間和本次觸發的時間差是否小于時間間隔的閾值 if (now - last >= interval) { // 如果時間間隔大于我們設定的時間間隔閾值，則執行回調 last = now; fn.apply(context, args); } } } // 用throttle來包裝scroll的回調 const better_scroll = throttle(() => console.log('觸發了滾動事件'), 1000) document.addEventListener('scroll', better_scroll) ``` ## Debounce： 最后一個人說了算 防抖的中心思想在于：我會等你到底。在某段時間內，不管你觸發了多少次回調，我都只認最后一次。 繼續講司機開車的故事。這次的司機比較有耐心。第一個乘客上車后，司機開始計時（比如說十分鐘）。十分鐘之內，如果又上來了一個乘客，司機會把計時器清零，重新開始等另一個十分鐘（延遲了等待）。直到有這么一位乘客，從他上車開始，后續十分鐘都沒有新乘客上車，司機會認為確實沒有人需要搭這趟車了，才會把車開走。 我們對比 throttle 來理解 debounce：在throttle的邏輯里，“第一個人說了算”，它只為第一個乘客計時，時間到了就執行回調。而 debounce 認為，“最后一個人說了算”，debounce 會為每一個新乘客設定新的定時器。 我們基于上面的理解，一起來寫一個 debounce： ``` // fn是我們需要包裝的事件回調, delay是每次推遲執行的等待時間 function debounce(fn, delay) { // 定時器 let timer = null // 將debounce處理結果當作函數返回 return function () { // 保留調用時的this上下文 let context = this // 保留調用時傳入的參數 let args = arguments // 每次事件被觸發時，都去清除之前的舊定時器 if(timer) { clearTimeout(timer) } // 設立新定時器 timer = setTimeout(function () { fn.apply(context, args) }, delay) } } // 用debounce來包裝scroll的回調 const better_scroll = debounce(() => console.log('觸發了滾動事件'), 1000) document.addEventListener('scroll', better_scroll) ``` ## 用 Throttle 來優化 Debounce debounce 的問題在于它“太有耐心了”。試想，如果用戶的操作十分頻繁——他每次都不等 debounce 設置的 delay 時間結束就進行下一次操作，于是每次 debounce 都為該用戶重新生成定時器，回調函數被延遲了不計其數次。頻繁的延遲會導致用戶遲遲得不到響應，用戶同樣會產生“這個頁面卡死了”的觀感。 為了避免弄巧成拙，我們需要借力 throttle 的思想，打造一個“有底線”的 debounce——等你可以，但我有我的原則：delay 時間內，我可以為你重新生成定時器；但只要delay的時間到了，我必須要給用戶一個響應。這個 throttle 與 debounce “合體”思路，已經被很多成熟的前端庫應用到了它們的加強版 throttle 函數的實現中： ``` // fn是我們需要包裝的事件回調, delay是時間間隔的閾值 function throttle(fn, delay) { // last為上一次觸發回調的時間, timer是定時器 let last = 0, timer = null // 將throttle處理結果當作函數返回 return function () { // 保留調用時的this上下文 let context = this // 保留調用時傳入的參數 let args = arguments // 記錄本次觸發回調的時間 let now = +new Date() // 判斷上次觸發的時間和本次觸發的時間差是否小于時間間隔的閾值 if (now - last < delay) { // 如果時間間隔小于我們設定的時間間隔閾值，則為本次觸發操作設立一個新的定時器 clearTimeout(timer) timer = setTimeout(function () { last = now fn.apply(context, args) }, delay) } else { // 如果時間間隔超出了我們設定的時間間隔閾值，那就不等了，無論如何要反饋給用戶一次響應 last = now fn.apply(context, args) } } } // 用新的throttle包裝scroll的回調 const better_scroll = throttle(() => console.log('觸發了滾動事件'), 1000) document.addEventListener('scroll', better_scroll) ``` ## 小結 throttle 和 debounce 不僅是我們日常開發中的常用優質代碼片段，更是前端面試中不可不知的高頻考點。“看懂了代碼”、“理解了過程”在本節都是不夠的，重要的是把它寫到自己的項目里去，親自體驗一把節流和防抖帶來的性能提升。