每天阅读一个 npm 模块（4）- throttle-debounce
发布于 6 年前 作者 elvinn 3659 次浏览 来自 分享

每天阅读一个 npm 模块（4）- throttle-debounce

系列文章：

  1. 每天阅读一个 npm 模块（1）- username
  2. 每天阅读一个 npm 模块（2）- mem
  3. 每天阅读一个 npm 模块（3）- mimic-fn

上一篇文章中介绍的属性描述符的知识太偏于理论，今天阅读的 throttle-debounce 模块会实用许多，在工作常常可以用到。

一句话介绍

今天阅读的 npm 模块是 throttle-debounce，它提供了 throttle 和 debounce 两个函数：throttle 的含义是节流，debounce 的含义是防抖动，通过它们可以限制函数的执行频率，避免短时间内函数多次执行造成性能问题，当前包版本为 2.0.1，周下载量为 6.3 万。

用法

首选需要介绍一下 throttle 和 debounce ，它们都可以用于 函数节流 从而提升性能，但它们还是存在一些不同：

  • debounce：将短时间内多次触发的事件合并成一次事件响应函数执行（往往是在第一次事件或者在最后一次事件触发时执行），即该段时间内仅一次真正执行事件响应函数。
  • throttle：假如在短时间内同一事件多次触发，那么每隔一段更小的时间间隔就会执行事件响应函数，即该段时间内可能多次执行事件响应函数。

虽然每天最烦等电梯要花上十几分钟，但还是可以用坐电梯来举例子：

  • debounce：假如我在电梯里面正准备关门，这时 A 想要坐电梯，那么出于礼貌我会按下开门键，然后等他走进电梯后再尝试关门；等 A 进电梯后，又发现 B 也想要坐电梯，那么同样出于礼貌我会按下开门键，然后等他走进电梯。那么假如一直有人想要坐电梯的话，我就会不断地延后按下关门键的时机，直至没有人想要坐电梯（现实生活中我这样做的话，估计每天除了坐电梯就可以什么都不做了）。
  • throttle：实际上我每天都有工作要完成，不可能在电梯里无限地等别人。那么这回我任性一点，规定我只等 30 秒，不管到时候有没有人想要坐电梯，我都会按下关门键走掉。

从上面两个例子中可以看出两者最大的区别在于只要有事件发生（有人想坐电梯），若使用了 throttle 方法，那么在一段时间内事件响应函数一定会执行（30秒内我按下关门键）；若使用了 debounce 方法，那么只有事件停止发生后（我发现没有人想坐电梯）才会执行。

大家可以尝试在 Code Pen -Demo 中滚动鼠标直观地感受到这两者的不同。

对于 throttle-debounce，它的简单用法如下：

import { throttle, debounce } from 'throttle-debounce';

function foo() { console.log('foo..'); }
function bar() { console.log('bar..'); }

const fooWrapper = throttle(200, foo);

for (let i = 1; i < 10; i++) {
  setTimeout(fooWrapper, i * 30);
}

// => foo 执行了三次
// => foo..
// => foo..
// => foo..

const barWrapper = debounce(200, bar);

for (let i = 1; i < 10; i++) {
  setTimeout(barWrapper, i * 30);
}

// => bar 执行了一次 
// => bar..

源码学习

throttle 实现

将源码简化后适当修改如下：

// 源码 4-1
function throttle(delay, callback) {
  let timeoutID;
  let lastExec = 0;

  function wrapper() {
    const self = this;
    const elapsed = Number(new Date()) - lastExec;
    const args = arguments;

    function exec() {
      lastExec = Number(new Date());
      callback.apply(self, args);
    }

    clearTimeout(timeoutID);

    if (elapsed > delay) {
      exec();
    } else {
      timeoutID = setTimeout(exec, delay - elapsed);
    }
  }

  return wrapper;
}

整个代码的逻辑十分清晰，一共只有三步：

  1. 计算距离最近一次函数执行后经过的时间 elapsed，并清除之前设置的计时器。
  2. 如果经过的时间大于设置的时间间隔 delay，那么立即执行函数，并更新最近一次函数的执行时间。
  3. 如果经过的时间小于设置的时间间隔 delay，那么通过 setTimeout 设置一个计数器，让函数在 delay - elapsed 时间后执行。

源码 4-1 并不难理解，不过需要关注一下 this 的使用：

function throttle(delay, callback) {
    // ...
    function wrapper() {
    	const self = this;
        const args = arguments;
        // ...
        
        function exec() {
            // ...
	      	callback.apply(self, args);
    	}
        
    }
}

在上面的代码中，通过 self 变量临时保存 this 的值，从而在 exec 函数中通过 callback.apply(self, args) 传入正确的 this 值，这种做法在闭包相关的函数调用中十分常用。正因为这里对 this 的处理，所以可以实现下面的能力：

function foo() { console.log(this.name);  }

const fooWithName = throttle(200, foo);

const obj = {name: 'elvin'};

fooWithName.call(obj, 'elvin');

// => 'elvin'

debounce 实现

由于 debouncen 只是往后推延函数的执行时间，并不具有 throttle 每隔一段时间一定会执行的能力，所以其实现起来更加简单：

function debounce(delay, callback) {
  let timeoutID;

  function wrapper() {
    const self = this;
    const args = arguments;

    function exec() {
      callback.apply(self, args);
    }

    clearTimeout(timeoutID);

    timeoutID = setTimeout(exec, delay);
  }

  return wrapper;
}

将上述代码与 throttle 实现的代码相比，可以发现其就是去除了 elapsed 相关逻辑后的代码，其余大部分代码一模一样，所以 debounce 函数可以借助 throttle 函数实现（throttle-debounce 源代码中也是这样做的），throttle 函数也可以借助 debounce 函数实现。

throttle 和 debounce 使用场景举例

throttle 和 debounce 适用于用户短时间内频繁执行某一相同操作的场景，例如：

  • 用户拖动浏览器窗口改变窗口大小，触发 resize 事件。
  • 用户移动鼠标，触发 mousemove 等事件。
  • 用户在输入框内进入输入，触发 keydown | keypress | keyinput | keyup 等事件。
  • 用户滚动屏幕，触发 scroll 事件。
  • 用户在点击按钮后，由于 API 请求耗时未立即看到响应，可能会不断点击按钮触发 click 事件。

在网上搜索了不少资料，发现对两个函数的使用场景有时彼此之间都互相矛盾，例如有的说在搜索框进行输入，应该使用 debounce 进行限流，从而减轻服务器压力；有的说使用 throttle 进行限流即可，可以更快地返回用户的搜索结果。

在我看来，并不存在一个场景，就一定是使用 throttle 和 debounce 中的一种方法并另外一种方法好，往往需要结合自身的情况进行考虑和选择：

  • 当事件响应函数对 CPU、GPU、流量、服务器等资源的占用在接受范围内时，可以使用 throttle 进行限流带来更好的用户体验。
  • 当事件响应函数对 CPU、GPU、流量、服务器等资源的占用较大时，可以使用 debounce 进行更强力的限流，从而减轻压力。

写在最后

throttle-debounce 源码和我前几天所看的 Sindre 所写的模块代码风格完全不同，它的代码中注释的行数约为代码行数的三倍，而且函数的参数均有详细的注释，这本应是一件好事，但是对于我阅读源码而言，并没有觉得更加轻松，而求由于对可选参数进行的如下处理，让我阅读起来更加费力：

// 源码 4-2

/**
 *
 * @param  {Number}    delay
 * @param  {Boolean}   [noTrailing]
 * @param  {Function}  callback
 * @param  {Boolean}   [debounceMode]
 *
 * @return {Function}  A new, throttled, function.
 */
export default function ( delay, noTrailing, callback, debounceMode ) {
    // `noTrailing` defaults to falsy.
	if ( typeof noTrailing !== 'boolean' ) {
		debounceMode = callback;
		callback = noTrailing;
		noTrailing = undefined;
	}
    
    // ...
}

在源码 4-2 中，从注释可以看出 noTrailing 和 debounceMode 是可选参数，delay 和 callback 为必选参数，然后它将可选参数 noTrailing 放在了必选参数 callback 之前，再在函数中的代码进行判断：假如 noTrailing 为函数的话，则此值应作为 callback，然后再将 noTrailing 设为默认值 undefined。

不禁感叹这真是一番骚操作，哪怕是为了兼容 ES5，也有更好的写法，这里说说我个人认为可用 ES6 语法时更好的写法：

export default function (dalay, noTrailing, options = {
    callback = false,
    debounceMode = false,
} = {}) {
    // ...
}

关于我：毕业于华科，工作在腾讯，elvin 的博客 欢迎来访 ^_^

6 回复

感觉这个比较适合前端 后端聊天室这种的不知道适不适用

@phper-chen 嗯啊，这个在响应用户动作时使用的多一点。 聊天室使用 websocket 的话不太需要，但是如果降级为轮询的话可以通过这种方式控制频率。

跟着楼主读一读

@yokingma 一起一起 😊

电梯比喻的好形象，这两个我之前也是一知半解，现在终于懂了，感谢分享

@DCbryant 我也是在其它地方看到了这个比喻，进行了一点修改用来说明 ^_^

回到顶部