Javascript函数节流（throttle）和函数去抖（debounce）

函数节流（throttle）和去抖（debounce）的应用场景，一般伴随着客户端DOM事件监听。举个例子，实现一个原生的拖拽功能（不用H5 Drag&Drop API），需要一路监听mousemove事件，在回调中获取元素当前位置，然后重置dom的位置（样式改变）。如果我们不加以控制，每移动一定像素而出发的回调数量是会非常惊人的，回调中又伴随着DOM操作，然而引发浏览器重排和重绘，性能差的浏览器可能就会直接假死，这样的用户体验是非常糟糕的。** 我们需要做的是降低出发回调的频率 ， 比如让它500ms出发一次，或者200ms，甚至100ms，这个阈值不能太大，太大了拖拽就会失真，也不能太小，太小了低版本浏览器可能就会假死，这样的解决方案就是 函数节流 **，英文名字叫做[throttle]。函数节流的核心： **让一个函数不要执行得太频繁，减少一些过快的调用来节流 ** ，可以理解为间隔时间段触发。

说完函数节流，再看它的好基友函数去抖（debounce）。思考这样一个场景，对于浏览器窗口，每做一次resize操作，发送一个请求，很显然，我们需要监听resize事件，但是和mousemove一样，每缩小（或者放大）一次浏览器，实际上会出发N多次的resize事件，用节流？节流只能保证定时触发，我们一次就好，这就要用去抖。简单的说，函数去抖就是对于一定时间段的连续的函数调用，只让其执行一次。

throttle的应用场景

函数节流有哪些应用场景？哪些时候我们需要间隔一定时间出发回调来控制函数调用频率？

• DOM元素的拖拽功能实现（mousemove）
• 射击游戏的mousedown/keydown事件（单位时间只能发射一颗子弹）
• 计算鼠标移动的距离（mousemove）
• Canvas模拟画板功能（mousemove）
• 搜索联想（keyup）
• 监听滚动事件判断是否到页面底部自动加载更多：给scroll加了debounce后，只有用户停止滚动后，才会判断是否到了页面底部；如果是throttle的花，只要页面滚动就会间隔一段时间判断一次

debounce应用场景

函数去抖有哪些应用场景？哪些时候对于连续的事件响应我们只需要进行一次回调？

• 每次resize/scroll触发统计事件
• 文本输入的验证（连续输入文字后发送AJAX请求进行验证，验证一次就好）

下面贴上throttle和debounce的demo:

throttle:

function throttle(fn, delta, context) {
  var safe = true;
  
  return function() {
    var args = arguments;
    
    if(safe) {
      fn.call(context, args)
      
      safe = false
      
      setTimeout(function() {
        safe = true
      }, delta)
    }
  }
}

function T() {
  document.body.innerHTML += 'T
'
}

window.addEventListener('mousemove', throttle(T, 1000));

debounce:

function debounce(fn, delta, context) {
  var timeoutID = null;
  
  return function() {
    if(timeoutID) {
      clearTimeout(timeoutID);
    }
    
    var args = arguments;
    
    timeoutID = setTimeout(function() {
      fn.apply(context, args);
    }, delta);
    
  }
}

function D() {
  document.body.innerHTML += 'D
'
}

window.addEventListener('mousemove', debounce(D, 1000));

小结

函数节流和函数去抖的核心其实就是限制某一个方法被频发触发，而一个方法之所以会被频发触发，大多数情况下因为DOM事件的监听回调，而这也是函数节流以及去抖多数情况下的应用场景。

文章转自https://github.com/hanzichi/underscore-analysis/issues/20