Ede's Blog

Home About Github

throttle细节小记

说起来也惭愧，我一个工作三年有余的人，竟然hold不住只有二三十行的throttle函数。自从工程用了我写的throttle后，遇到的几个坑或bug，自挂东南，自以警示世人。

先说定义，throttle，译节流，基本用法 :

let throttleFunc = throttle(func, 60);

无论调用多少次throttleFunc，func在规定的时间（60ms）内只执行一次。常见的用法有，前端页面动效等变更，一般情况下，保证60FPS即可，即let throttleRender = throttle(render, 1000 / 60)。

废话不多讲，看坑。

Round 1：throttle是立即返回

此标题有两层含义

  1. 假如函数有返回值，throttle修饰后的函数也应有返回值
  2. throttle修饰后的函数，假如满足了调用间隔，应立即执行此函数

为啥？因为throttle自带缓存功能！有些人我有时会忘记利用throttle有缓存的能力，而直接在函数内赋值给全局变量，再读取全局变量，这样函数就不是纯函数，不优雅。

let foo = 0;
function longTimeToCalc() {
  ++foo;
  return foo;
}
let throttleCalc = throttle(longTimeToCalc, 100);

let a = throttleCalc(); // a = 1
setTimeout(function() {
  let b = throttleCalc(); // b = 1; 即第一次执行的缓存结果
}, 50);

至于立即执行，则容易理解，最基础，我们总是希望得到较新值嘛。

let foo = 0;
function longTimeToCalc() {
  ++foo;
  return foo;
}
let throttleCalc = throttle(longTimeToCalc, 100);

let a = throttleCalc(); // a = 1
setTimeout(function() {
  // b = 2; 满足100ms间隔后，应立即执行并返回较新值
  let b = throttleCalc();
}, 110);

Round 2： trailing用法

某些人我不知道，throttle可以设置运行细节，其中一个参数是trailing，默认值为true，其作用是：最小时间间隔Xms内假如发生多次调用，是否在最后一次主动调用后，再执行一次该方法。看例子：

let i = 0；
let func = function() { ++i }
let throttleFunc = throttle(func, 100);

throttleFunc();
throttleFunc();

// 在第一次调用后，未满足100ms间隔再次调用时，会在第一次调用后，再调用一次
console.log(i); // 1
setTimeout(function() {
    console.log(i); // 1
}, 50);
setTimeout(function() {
    console.log(i); // 2
}, 110);

值得注意，假如没有发生多次调用，不会“多”执行的。

let i = 0；
let func = function() { ++i }
let throttleFunc = throttle(func, 100);

throttleFunc();

console.log(i); // 1
setTimeout(function() {
    console.log(i); // 1，因为没有多次调用
}, 110);

假如值为false，结果如下：

let i = 0；
let func = function() { ++i }
let throttleFunc = throttle(func, 100, {trailing: false});

throttleFunc();
throttleFunc();

console.log(i); // 1
setTimeout(function() {
    console.log(i); // 1
}, 50);
setTimeout(function() {
    console.log(i); // 1，最后一次调用被取消了
}, 110);

非常简单，我明白了。

为什么traling要默认为true，因为最后一次调用得到的值，往往是我们最想要的(参考Round 1)。但某些场景下，traling不能为true。比如鼠标区选文字时（按照常规逻辑，应在鼠标按下时进入选区模式，拖拽时选择字符，鼠标松开时结束）：

function onStart() { console.log('start') }
function onMove() { console.log('move') }
function onEnd() { console.log('end') }

// move触发非常频繁，加个限流
const onThrottleMove = throttle(onMove, 1000 / 60);

window.addEventlistener('mousedown', onStart);
window.addEventListener('mousemove', onThrottleMove);
window.addEventListener('mouseup', onEnd);

看起来木有什么问题，但是，因为throttle触发频繁时往往不是立即调用，会有一定的延后性。所以你可能会看到这样的输出：

start
move
move
move
end // 松开鼠标，且不再移动
move // 多了一个move

移动选词时鼠标都松开了，还会多执行一次move选词，不符合常理。因此，那些需要保证严格执行顺序的方法，最好trailing设置为false。即：

// ...
const onThrottleMove = throttle(onMove, 1000 / 60, { trailing: false });

Round 3： throttle不能绑定多个同源函数

假如使用throttle不优雅，也会产生bug，参考代码：

// 统一的事件入口
function onEvent() {
  switch(event.type) {
    case 'mousemove': {
      // 这里触发一个自定义的‘MOVE’事件
      const selEvent = docuemnt.createEvent('MOVE');
      selEvent.initCustomEvent(type);
      window.dispatchEvent(selEvent);
      break;
    }
    case 'MOVE': {
      console.log('MOVE');
      break;
    }
  }
}

const onThrottleEvent = throttle(onEvent, 30);

window.addEventListener('mousemove', onThrottleEvent);
window.addEventListener('MOVE', onThrottleEvent);

初步理解，频繁移动鼠标时，只要保证调用时间间隔满足30ms，便会不断输出MOVE。

然而并没有！！MOVE触发的次数少得可怜，甚至几秒也不会触发一次。

为什么？因为throttle绑定的是onEvent，以上写法只保证onEvent触发时间间隔满足30ms。当频繁移动鼠标时，事件可能进入了case 'mousemove'这个逻辑分支，从而霸占了case 'MOVE'的生存空间了。所以说，同源函数最好绑定多个函数。

// ...onEvent

const onThrottleEvent = throttle(onEvent, 30);
window.addEventListener('mousemove', onThrottleEvent);

// 不要那么小气，多绑定一次又不会怀孕
const onThrottleMouseMove = throttle(onEvent, 30);
window.addEventListener('MOVE', onThrottleMouseMove);

Round4: Lodash以及Underscore的细小差异

某次发现，lodash的单元测试用例，underscore是有一定概率不满足的：

// 以下是lodash的测试用例
it('subsequent calls should return the result of the first call', (done) => {
    const identity = function(value) {
        return value;
    };
    let throttled = throttle(identity, 32);
    let results = [throttled('a'), throttled('b')];
  
    expect(results).to.eql(['a', 'a']);
    setTimeout(function() {
        let results = [throttled('c'), throttled('d')];
        // underscore: 有一定概率是["b", "b"]
        expect(results).to.eql(['c', 'c']); 
        done();
    }, 64);
});

这是不是说underscore不稳定？并不是，经过一番折腾，我发现以下测试用例，underscore符合，lodash则不满足的：

it('[自定义]: 即使阻塞，两次调用间隔也大于最小调用间隔', () => {
    let callCount = 0;
    let timeout = false;
    let throttled = throttle(function () {
        callCount++;
    }, 100);
    throttled();
    throttled();
    setTimeout(function () {
        throttled();
        // lodash此时会是3，underscore是2
        expect(callCount).to.be.equal(2);
    }, 220);
      
    // 通过循环300毫秒来阻塞js（浏览器将推迟调用↑setTimeout）
    let execTime = 300;
    let startTime = Date.now();
    for (let i = 0; timeout !== true; i++) {
        if (Date.now() - startTime > execTime) {
            timeout = true;
        }
    }
});

结论：Lodash以调用时作为基准，调用即重置计时器；而underscore会以调用完成作为基准，方法调用成功后才重置。

不懂？但我也不是很懂懒得说了，大伙看源码去吧。这个差异会导致一个问题。

function longTimeToExec() {
  // 假设这里的代码耗时200毫秒
}

let lodashThrottleExec = lodash.throttle(longTimeToExec, 100);
let underscoreThrottleExec = _.throttle(longTimeToExec, 100);

lodashThrottleExec();
underscoreThrottleExec();

setTimeout(function() {
  lodashThrottleExec();
  underscoreThrottleExec();
}, 110);

在这种场景下，假如使用lodashThrottleExec，会有问题。110ms时，即使第一次执行未完成，但间隔已满足大于100ms，再次调用longTimeToExec会触发执行。当然，所有的throttle都采用了requestAnimate，并不会出现卡死现象，但可能浏览器将疲于执行LongTimeToExec，使其它方法响应不够及时。

这种差异其实是一种取舍，lodash更保守，调用更频繁，得到的数据也更准确，所以我选择underscore选择在完成时重置计时器，毕竟性能使我头大。

结论

也许还有更多的坑没有发现。但经此一役，那些看起来简单的方法，也可能蕴含众多细节。程序猿嘛，就要对代码保持敬畏之心。

滑动优化填坑记