摘要：自己嘗試一下年在的文章中第一次看到的實(shí)現(xiàn)方法。這三種實(shí)現(xiàn)方法內(nèi)部不同，但是接口幾乎一致。如你所見，我們使用了參數(shù)，因?yàn)槲覀冎粚?duì)用戶停止改變?yōu)g覽器大小時(shí)最后一次事件感興趣。

前幾天看到一篇文章，我的公眾號(hào)里也分享了《一次發(fā)現(xiàn)underscore源碼bug的經(jīng)歷以及對(duì)學(xué)術(shù)界拿來主義的思考》具體文章詳見，微信公眾號(hào)：

文中講了大家對(duì)throttle和debounce存在誤解，同時(shí)提到了《高程3》中實(shí)現(xiàn)節(jié)流方法存在一些問題，為了更好的理解這兩個(gè)概念，搜了很多相關(guān)文章，詳見文章底部。

throttle與debounce是兩個(gè)類似的概念，目的都是隨著時(shí)間的推移控制執(zhí)行函數(shù)的次數(shù)，但是有些細(xì)微的差別。

當(dāng)我們?yōu)镈OM事件關(guān)聯(lián)方法時(shí)，若我們有一個(gè)debounced和throttled函數(shù)將會(huì)很方便，為何？因?yàn)檫@樣我們可以在事件和執(zhí)行函數(shù)之間添加一層控制，注意我們并沒有去控制DOM事件觸發(fā)的次數(shù)。

例如，我們談一下scroll事件，看下面的例子：

See the Pen Scroll events counter by ghostcode (@ghostcode) on CodePen.

當(dāng)你在觸控板或者鼠標(biāo)滾動(dòng)時(shí)，每次最少會(huì)達(dá)到30次，在手機(jī)上更多。可是你的滾動(dòng)事件處理函數(shù)對(duì)這個(gè)頻率是否應(yīng)付的過來？

在2011年，Twitter網(wǎng)站曾爆出一個(gè)問題：當(dāng)你在主頁往下滾動(dòng)時(shí)，頁面會(huì)變得緩慢以致沒有響應(yīng)。John Resig發(fā)表了一篇文章《 a blog post about the problem》指出直接在scroll事件上面綁定高消耗的事件是一個(gè)多么愚蠢的想法。

在那個(gè)時(shí)候John建議使用一個(gè)獨(dú)立于scroll事件且每250ms執(zhí)行的輪詢方法。這樣的話處理方法就不會(huì)耦合于事件。通過這個(gè)簡(jiǎn)單的技術(shù)，我們可以提高用戶體驗(yàn)。

現(xiàn)在有一些更先進(jìn)的事件處理方法，讓我來給你介紹：__Debounce，Throttle和requestAnimationFrame__，同時(shí)會(huì)介紹一些適用的場(chǎng)景。

Debounce

Debounce技術(shù)使我們可以將一個(gè)連續(xù)的調(diào)用歸為一個(gè)。

想象你在電梯的場(chǎng)景，當(dāng)電梯門開始要關(guān)閉的時(shí)候，突然一個(gè)人進(jìn)來，此時(shí)電梯并不會(huì)關(guān)閉并且也不會(huì)執(zhí)行改變樓層的方法，如果還有人進(jìn)來同樣的事情會(huì)發(fā)生：電梯延遲執(zhí)行它的方法（改變樓層），優(yōu)化了它的資源。

自己嘗試一下，在按鈕上點(diǎn)擊或者移動(dòng)鼠標(biāo)：

See the Pen Debounce. Trailing by ghostcode (@ghostcode) on CodePen.

你可以看到快速連續(xù)的事件是如何通過一個(gè)debounce事件來表示的。

Leading edge (or "immediate")

你可以發(fā)現(xiàn)事件結(jié)束的時(shí)候，debounce的事件并沒有立即執(zhí)行而是等待了一些時(shí)間才觸發(fā)。為何不立即觸發(fā)，就像開始沒有使用debounce事件處理？直到在連續(xù)執(zhí)行的事件中有一個(gè)暫停，才會(huì)再次觸發(fā)。

你可以通過一個(gè)__leading__的參數(shù)做到：

在underscore.js中，這個(gè)參數(shù)叫immediate。

自己嘗試一下：

See the Pen Debounce. Leading by ghostcode (@ghostcode) on CodePen.

Debounce Implementations

2009年在John Hann的文章中第一次看到debounce的實(shí)現(xiàn)方法。

在那之后不久，Ben Alman寫了一個(gè)jQuery插件(現(xiàn)在不在維護(hù))，一年以后Jeremy Ashkenas把此方法添加到underscore.js中，不久又被添加到lodash中。

See the Pen debounce-click by ghostcode (@ghostcode) on CodePen.

這三種實(shí)現(xiàn)方法內(nèi)部不同，但是接口幾乎一致。

有段時(shí)間underscore采用了Lodash的實(shí)現(xiàn)方法，但是在我發(fā)現(xiàn)了一個(gè)bug之后，自此兩個(gè)庫的實(shí)現(xiàn)開始分道揚(yáng)鑣。

Lodash在_.debounce和_.throttle中添加了許多特性。immediate標(biāo)示替代了leading和trailing。你可以二選一或者都選，默認(rèn)情況下，只有trailing是開啟的。

Debounce Examples

當(dāng)改變?yōu)g覽器窗口時(shí)，resize事件會(huì)觸發(fā)多次。

See the Pen Debounce Resize Event Example by ghostcode (@ghostcode) on CodePen.

如你所見，我們使用了__trailing__參數(shù)，因?yàn)槲覀冎粚?duì)用戶停止改變?yōu)g覽器大小時(shí)最后一次事件感興趣。

AutoComplete中的Ajax請(qǐng)求使用的keypress

當(dāng)用戶仍舊在輸入的時(shí)候，為何每隔50ms發(fā)送Ajax請(qǐng)求？__ _.debounce __可以幫助我們避免額外的工作，只在用戶停止輸入的時(shí)候發(fā)送請(qǐng)求。

See the Pen Debouncing keystrokes Example by ghostcode (@ghostcode) on CodePen.

另一個(gè)使用場(chǎng)景是在進(jìn)行input校驗(yàn)的時(shí)候，“你的密碼太短”等類似的信息。

如何使用debounce和throttle以及常見的陷阱？

可以自己實(shí)現(xiàn)這兩個(gè)方法或者隨便復(fù)制別人blog中的實(shí)現(xiàn)方法，我的建議是直接使用underscore和lodash中的方法。如果你只需要這兩個(gè)方法，可以定制輸出lodash方法：

npm i -g lodash-cli
lodash-cli include=debounce,throttle

一個(gè)常見的陷阱：

// WRONG
$(window).on("scroll", function() {
   _.debounce(doSomething, 300); 
});

// RIGHT
$(window).on("scroll", _.debounce(doSomething, 200));

debounce方法賦值給一個(gè)變量之后允許我們調(diào)用一個(gè)私有方法：__debounced_version.cancel()__：

var debounced_version = _.debounce(doSomething, 200);
$(window).on("scroll", debounced_version);

// If you need it
debounced_version.cancel();

Throttle

使用__ _.throttle __，我們不允許方法在每Xms間執(zhí)行超過一次。

和debounce的主要區(qū)別是throttle保證方法每Xms有規(guī)律的執(zhí)行。

Throttling Examples

一個(gè)相當(dāng)常見的例子，用戶在你無限滾動(dòng)的頁面上向下拖動(dòng)，你需要判斷現(xiàn)在距離頁面底部多少。如果用戶快接近底部時(shí)，我們應(yīng)該發(fā)送請(qǐng)求來加載更多內(nèi)容到頁面。

在此__ _.debounce 沒有用，因?yàn)樗粫?huì)在用戶停止?jié)L動(dòng)時(shí)觸發(fā)，但我們需要用戶快到達(dá)底部時(shí)去請(qǐng)求。通過 _.throttle __我們可以不間斷的監(jiān)測(cè)距離底部多遠(yuǎn)。

See the Pen Infinite scrolling throttled by ghostcode (@ghostcode) on CodePen.

requestAnimationFrame (rAF)

requestAnimationFrame是另一個(gè)頻率限制的方法。

它可以通過__ _.throttle(dosomething, 16)__實(shí)現(xiàn)，但為了更加精準(zhǔn)瀏覽器提供了內(nèi)置API。

我們可以使用rAF API作為throttle方法的替代，考慮一下利弊：

利：

目標(biāo)60fps（16ms每貞），但是內(nèi)部使用最優(yōu)的時(shí)間間隔來渲染

使用簡(jiǎn)單并且是標(biāo)準(zhǔn)API，以后不會(huì)變動(dòng)，不需要維護(hù)

弊：

rAF的開始或者取消需要我們自己處理，不像.debounce和.throttle內(nèi)部實(shí)現(xiàn)

瀏覽器Tag沒有激活，它就不會(huì)執(zhí)行

即使多數(shù)現(xiàn)代瀏覽器支持，但是IE9，Opera Mini以及老版本Android依舊不支持。A polyfill到現(xiàn)在依舊需要

rAF在node.js中不支持

根據(jù)經(jīng)驗(yàn)，我建議在JS執(zhí)行"painting"或"animating"中直接操作屬性和重新計(jì)算元素位置時(shí)使用rAF。

發(fā)送Ajax請(qǐng)求或者是否添加／刪除class（觸發(fā)一個(gè)CSS動(dòng)畫）時(shí)，我會(huì)考慮debounce和throttle，此時(shí)你可以降低執(zhí)行頻率（200ms而不是16ms）。

rAF的例子

在Paul Lewis的文章激發(fā)下，我只在scroll事件中提供例子。

我一步步的調(diào)throttle到16ms，希望給一個(gè)類似的體驗(yàn)，但是rAF在復(fù)雜場(chǎng)景下或許會(huì)提供更好的結(jié)果。

See the Pen Scroll comparison requestAnimationFrame vs throttle by ghostcode (@ghostcode) on CodePen.

一個(gè)更好的例子我是在headroom.js中看到的，這里通過一個(gè)對(duì)象封裝，進(jìn)行了邏輯解藕。

總結(jié)：
使用debounce，throttle和requestAnimationFrame優(yōu)化你的事件處理函數(shù)。每一個(gè)方法有一些細(xì)微的差別，三個(gè)都很有用而且互相彌補(bǔ)。

__debounce:__把突然涌進(jìn)的事件（鍵盤事件）歸位一個(gè)

__throttle:__保證持續(xù)執(zhí)行方法分隔為每Xms執(zhí)行一次。就像每200ms監(jiān)測(cè)滾動(dòng)位置來觸發(fā)css動(dòng)畫。

__requestAnimationFrame:__throttle的替代方案，當(dāng)你的方法需要重新計(jì)算和渲染元素同時(shí)你需要更平滑的變動(dòng)或動(dòng)畫。注意：IE9- 不支持。

https://blog.coding.net/blog/...

https://css-tricks.com/the-di...

http://stackoverflow.com/ques...

http://demo.nimius.net/deboun...