在2011年,Twitter网站曾爆出一个问题:在主页往下滚动时,页面会变得缓慢以致没有响应。John Resig发表了一篇文章《 a blog post about the problem》指出直接在scroll事件上面绑定高消耗的事件是一个多么愚蠢的想法。现在项目中大家都会对类似的scroll或者resize事件都进行了节流控制,下述是我们经常用到,也是《JavaScript高级程序设计》- JavaScript高级技巧中提及的节流方式。
1 | /** |
之前一直觉得上述代码就是实现了真正的节流,也没去深入研究。直到最近在和之前的同事讨论图表的问题,说起了“throttle和debounce”,他说我们项目中使用的不是真正意义上的throttle,而是一个debounce的简单实现。这里先简单介绍一下“throttle和debounce”,二者都是随着时间推移控制执行函数的次数来达到较少资源消耗,特别在事件触发上,尤为重要。
debounce(func, wait, immediate):创建并返回函数的防反跳版本,将延迟函数的执行(真正的执行)在函数最后一次调用时刻的wait毫秒之后,对于必须在一些输入(多是一些用户操作)停止之后再执行的行为有帮助。将一个连续的调用归为一个!
throttle(func, wait, options):创建并返回一个像节流阀一样的函数,当重复调用函数的时候,最多每隔指定的wait毫秒调用一次该函数; 不允许方法在每wait ms间执行超过一次!
举个例子:页面存在一个按钮,通过throttle和debounce包括其监听函数,wait设置为1000ms。确保在每个1000ms内都多次触发click持续2000ms。
1 | // 执行1次(最后一次点击1000ms后) |
debounce使用场景:
第一次触发后,进行倒计wait毫秒,如果倒计时过程中有其他触发,则重置倒计时;否则执行fn。用它来丢弃一些重复的密集操作、活动,直到流量减慢。例如:
- 对用户输入的验证,不在输入过程中就处理,停止输入后进行验证足以;
- 提交ajax时,不希望1s中内大量的请求被重复发送。
throttle使用场景
第一次触发后先执行fn(当然可以通过{leading: false}来取消),然后wait ms后再次执行,在单位wait毫秒内的所有重复触发都被抛弃。即如果有连续不断的触发,每wait ms执行fn一次。与debounce相同的用例,但是你想保证在一定间隔必须执行的回调函数。例如:
- 对用户输入的验证,不想停止输入再进行验证,而是每n秒进行验证;
- 对于鼠标滚动、window.resize进行节流控制。
正真的业务场景:
一个相当常见的例子,用户在你无限滚动的页面上向下滚动鼠标加载页面,你需要判断现在距离页面底部多少。如果用户快接近底部时,我们应该发送请求来加载更多内容到页面。在此debounce没有用,因为它只会在用户停止滚动时触发,但我们需要用户快到达底部时去请求。通过throttle我们可以不间断的监测距离底部多远。
1 | $(document).ready(function(){ |
特别说明:
1 | // 错误 |