问题的引出
在一些场景往往由于事件频繁被触发,因而频繁地进行DOM操作、资源加载,导致UI停顿甚至浏览器崩溃。
在这样的情况下,我们实际上的需求大多为停止改变大小n毫秒后执行后续处理;而其他事件大多的需求是以一定的频率执行后续处理。针对这两种需求就出现了debounce和throttle两种解决办法。
前缘
我首次看到 debounce 的 JavaScript 实现是在 2009 年的 John Hann 的博文 。
不久后,Ben Alman 做了个 jQuery 插件 (不再维护),一年后 Jeremy Ashkenas 把它 加入了 underscore.js 。而后加入了 Lodash 。
Lodash 给 _.debounce
和 _.throttle
添加了 不少特性 。之前的 immediate
( underscore.js
中用) 被 leading
(最前面) 和 trailing
(最后面) 选项取代。你可以选一种,或者都选,默认只有 trailing
启用。
新的 maxWait
选项(仅 Lodash 有)本文未提及,但是也很有用。事实上,throttle 方法是用 _.debounce
加 maxWait
实现的,你可以看 lodash 源码
See the Pen New example by Corbacho ( @dcorb ) on CodePen .
防抖( Debounce )和节流( throttle )都是用来控制某个函数在一定时间内执行多少次的技巧,两者相似而又
throttle(节流)
有一个调用周期,在一个很长的时间里分为多段,每一段执行一次。例如onscroll,resize,500ms执行一次
调整大小的例子
调整桌面浏览器窗口大小的时候,会触发很多次 resize
事件。
看下面 demo:
See the Pen Debounce Resize Event Example by Corbacho ( @dcorb ) on CodePen .
如你所见,我们为 resize 事件使用了默认的 trailing
选项,因为我们只关心用户停止调整大小后的最终值。
基于 AJAX 请求的自动完成功能,通过 keypress 触发
为什么用户还在输入的时候,每隔50ms就向服务器发送一次 AJAX 请求? _.debounce
可以帮忙,当用户停止输入的时候,再发送请求。
此处也不需要 leading
标记,我们想等最后一个字符输完。
See the Pen Debouncing keystrokes Example by Corbacho ( @dcorb ) on CodePen .
相似的使用场景还有,直到用户输完,才验证输入的正确性,显示错误信息。
debounce(防抖)
在一定时间内不调用,只调用一次。例如input事件,停止输入500ms之后再执行。
无限滚动
用户向下滚动无限滚动页面,需要检查滚动位置距底部多远,如果邻近底部了,我们可以发 AJAX 请求获取更多的数据插入到页面中。
我们心爱的 _.debounce
就不适用了,只有当用户停止滚动的时候它才会触发。只要用户滚动至邻近底部时,我们就想获取内容。
使用 _.throttle
可以保证我们不断检查距离底部有多远。
See the Pen Infinite scrolling throttled by Corbacho ( @dcorb ) on CodePen .
如何使用 debounce 和 throttle 以及常见的坑
自己造一个 debounce / throttle
的轮子看起来多么诱人,或者随便找个博文复制过来。 我是建议直接使用 underscore 或 Lodash 。如果仅需要 _.debounce
和 _.throttle
方法,可以使用 Lodash
的自定义构建工具,生成一个 2KB 的压缩库。使用以下的简单命令即可:
npm i --save lodash
const { debounce, throttle } = require('lodash');
常见的坑是,不止一次地调用 _.debounce 方法:
// 错误
$(window).on('scroll', function() {
_.debounce(doSomething, 300);
});
// 正确
$(window).on('scroll', _.debounce(doSomething, 200));
debounce
方法保存到一个变量以后,就可以用它的私有方法debounced_version.cancel()
,lodash
和underscore.js
都有效。
var debounced_version = _.debounce(doSomething, 200);
$(window).on('scroll', debounced_version);
// 如果需要的话
debounced_version.cancel();
requestAnimationFrame(rAF)
requestAnimationFrame
是另一种限速执行的方式。跟 _.throttle(dosomething, 16)
等价。它是高保真的,如果追求更好的精确度的话,可以用浏览器原生的 API 。
可以使用 rAF API 替换 throttle 方法,考虑一下优缺点:
优点
- 动画保持 60fps(每一帧 16 ms),浏览器内部决定渲染的最佳时机
- 简洁标准的 API,后期维护成本低
缺点
- 动画的开始/取消需要开发者自己控制,不像 ‘.debounce’ 或 ‘.throttle’由函数内部处理。
- 浏览器标签未激活时,一切都不会执行。
- 尽管所有的现代浏览器 都支持 rAF ,IE9,Opera Mini 和 老的 Android 还是 需要打补丁 。
- Node.js 不支持,无法在服务器端用于文件系统事件。
根据经验,如果 JavaScript 方法需要绘制或者直接改变属性,我会选择 requestAnimationFrame
,只要涉及到重新计算元素位置,就可以使用它。
涉及到 AJAX 请求,添加/移除 class (可以触发 CSS 动画),我会选择 _.debounce
或者 _.throttle
,可以设置更低的执行频率(例子中的200ms 换成16ms)。
rAF 实例
灵感来自于 Paul Lewis 的文章 ,我将用 requestAnimationFrame 控制 scroll 。
16ms 的 _.throttle
拿来做对比,性能相仿,用于更复杂的场景时,rAF 可能效果更佳。
See the Pen Scroll comparison requestAnimationFrame vs throttle by Corbacho ( @dcorb ) on CodePen .
headroom.js 是个更 高级的例子 。
结论
使用 debounce,throttle 和 requestAnimationFrame 都可以优化事件处理,三者各不相同,又相辅相成。
总之:
- debounce :把触发非常频繁的事件(比如按键)合并成一次执行。
- throttle :保证每 X 毫秒恒定的执行次数,比如每200ms检查下滚动位置,并触发 CSS 动画。
- requestAnimationFrame :可替代 throttle ,函数需要重新计算和渲染屏幕上的元素时,想保证动画或变化的平滑性,可以用它。注意:IE9 不支持。