聊聊lodash的debounce实现

本文同步自个人Blog

前段时间团队内部搞了一个代码训练营，你们组织在一块儿实现 lodash 的 throttle 和 debounce，实现起来以为并不麻烦，可是最后和官方的一对比，发现功能的实现上仍是有差距的，为了寻找个人问题，把官方源码阅读了一遍，本文是我阅读完成后的一篇总结。

注：本文只会列出比较核心部分的代码和注释，若是对所有的源码有兴趣的欢迎直接看个人repo：

什么是throttle和debounce

throttle(又称节流)和debounce(又称防抖)其实都是函数调用频率的控制器，这里只作简单的介绍，若是想了解更多关于这两个定义的细节能够看下后文给出的一张图片，或者阅读一下lodash的文档。

throttle：将一个函数的调用频率限制在必定阈值内，例如 1s 内一个函数不能被调用两次。

debounce：当调用函数n秒后，才会执行该动做，若在这n秒内又调用该函数则将取消前一次并从新计算执行时间，举个简单的例子，咱们要根据用户输入作suggest，每当用户按下键盘的时候均可以取消前一次，而且只关心最后一次输入的时间就好了。

lodash 对这两个函数又增长了一些参数，主要是如下三个：

• leading，函数在每一个等待时延的开始被调用
• trailing，函数在每一个等待时延的结束被调用
• maxwait(debounce才有的配置)，最大的等待时间，由于若是 debounce 的函数调用时间不知足条件，可能永远都没法触发，所以增长了这个配置，保证大于一段时间后必定能执行一次函数

这里直接剧透一下，其实 throttle 就是设置了 maxwait 的 debounce，因此我这里也只会介绍 debounce 的代码，聪明的读者们能够本身思考一下为何。

个人实现与lodash的区别

我本身的代码实现放在个人repo里，你们有兴趣的能够看下。以前说过个人实现和 lodash 有些区别，下面就用两张图来展现一下。

这是个人实现

这是lodash的实现

这里看到，个人代码主要有两个问题：

1. throttle 的最后一次函数会执行两次，并且并不是稳定复现。
2. throttle 里函数执行的顺序不对，虽然个人功能实现了，可是对于每一次 wait 来讲，我都是执行的 leading 那一次

lodash 的实现解读

下面，我就会带着这几个问题去看看 lodasah 的代码。

官方代码的实现也不是很复杂，这里我贴出一些核心部分代码和我阅读后的注释，后面会讲一下 lodash 的大概流程：

function debounce(func, wait, options) {
    let lastArgs,
        lastThis,
        maxWait,
        result,
        timerId,
        lastCallTime

    // 参数初始化
    let lastInvokeTime = 0 // func 上一次执行的时间
    let leading = false
    let maxing = false
    let trailing = true

    // 基本的类型判断和处理
    if (typeof func != 'function') {
        throw new TypeError('Expected a function')
    }
    wait = +wait || 0
    if (isObject(options)) {
        // 对配置的一些初始化
    }

    function invokeFunc(time) {
        const args = lastArgs
        const thisArg = lastThis

        lastArgs = lastThis = undefined
        lastInvokeTime = time
        result = func.apply(thisArg, args)
        return result
    }

    function leadingEdge(time) {
        // Reset any `maxWait` timer.
        lastInvokeTime = time
        // 为 trailing edge 触发函数调用设定定时器
        timerId = setTimeout(timerExpired, wait)
        // leading = true 执行函数
        return leading ? invokeFunc(time) : result
    }

   function remainingWait(time) {
        const timeSinceLastCall = time - lastCallTime // 距离上次debounced函数被调用的时间
        const timeSinceLastInvoke = time - lastInvokeTime // 距离上次函数被执行的时间
        const timeWaiting = wait - timeSinceLastCall // 用 wait 减去 timeSinceLastCall 计算出下一次trailing的位置

        // 两种状况
        // 有maxing:比较出下一次maxing和下一次trailing的最小值，做为下一次函数要执行的时间
        // 无maxing：在下一次trailing时执行 timerExpired
        return maxing
            ? Math.min(timeWaiting, maxWait - timeSinceLastInvoke)
            : timeWaiting
    }

    // 根据时间判断 func 可否被执行
    function shouldInvoke(time) {
        const timeSinceLastCall = time - lastCallTime
        const timeSinceLastInvoke = time - lastInvokeTime

        // 几种知足条件的状况
        return (lastCallTime === undefined //首次
            || (timeSinceLastCall >= wait) // 距离上次被调用已经超过 wait
            || (timeSinceLastCall < 0) //系统时间倒退
            || (maxing && timeSinceLastInvoke >= maxWait)) //超过最大等待时间
    }

    function timerExpired() {
        const time = Date.now()
        // 在 trailing edge 且时间符合条件时，调用 trailingEdge函数，不然重启定时器
        if (shouldInvoke(time)) {
            return trailingEdge(time)
        }
        // 重启定时器，保证下一次时延的末尾触发
        timerId = setTimeout(timerExpired, remainingWait(time))
    }

    function trailingEdge(time) {
        timerId = undefined

        // 有lastArgs才执行，意味着只有 func 已经被 debounced 过一次之后才会在 trailing edge 执行
        if (trailing && lastArgs) {
            return invokeFunc(time)
        }
        // 每次 trailingEdge 都会清除 lastArgs 和 lastThis，目的是避免最后一次函数被执行了两次
        // 举个例子：最后一次函数执行的时候，可能恰巧是前一次的 trailing edge，函数被调用，而这个函数又须要在本身时延的 trailing edge 触发，致使触发屡次
        lastArgs = lastThis = undefined
        return result
    }

    function cancel() {}

    function flush() {}

    function pending() {}

    function debounced(...args) {
        const time = Date.now()
        const isInvoking = shouldInvoke(time) //是否知足时间条件

        lastArgs = args
        lastThis = this
        lastCallTime = time  //函数被调用的时间

        if (isInvoking) {
            if (timerId === undefined) { // 无timerId的状况有两种：1.首次调用 2.trailingEdge执行过函数
                return leadingEdge(lastCallTime)
            }
            if (maxing) {
                // Handle invocations in a tight loop.
                timerId = setTimeout(timerExpired, wait)
                return invokeFunc(lastCallTime)
            }
        }
        // 负责一种case：trailing 为 true 的状况下，在前一个 wait 的 trailingEdge 已经执行了函数；
        // 而此次函数被调用时 shouldInvoke 不知足条件，所以要设置定时器，在本次的 trailingEdge 保证函数被执行
        if (timerId === undefined) {
            timerId = setTimeout(timerExpired, wait)
        }
        return result
    }
    debounced.cancel = cancel
    debounced.flush = flush
    debounced.pending = pending
    return debounced
}复制代码

这里我用文字来简单描述一下流程：

首次进入函数时由于 lastCallTime === undefined 而且 timerId === undefined，因此会执行 leadingEdge，若是此时 leading 为 true 的话，就会执行 func。同时，这里会设置一个定时器，在等待 wait(s) 后会执行 timerExpired，timerExpired 的主要做用就是触发 trailing。

若是在还未到 wait 的时候就再次调用了函数的话,会更新 lastCallTime，而且由于此时 isInvoking 不知足条件，因此此次什么也不会执行。

时间到达 wait 时，就会执行咱们一开始设定的定时器timerExpired，此时由于time-lastCallTime < wait，因此不会执行 trailingEdge。

这时又会新增一个定时器，下一次执行的时间是 remainingWait，这里会根据是否有 maxwait 来做区分：

• 若是没有 maxwait，定时器的时间是 wait - timeSinceLastCall，保证下一次 trailing 的执行。
• 若是有 maxing，会比较出下一次 maxing 和下一次 trailing 的最小值，做为下一次函数要执行的时间。

最后，若是再也不有函数调用，就会在定时器结束时执行 trailingEdge。

个人问题出在哪？

那么，回到上面的两个问题，个人代码到底是哪里出了问题呢？

为何顺序图不对

研究了一下，lodash是比较稳定的在trailing时触发前一次函数调用的，而个人则是每次在 maxWait 时触发的下一次调用。问题就出在对于定时器的控制上。

由于在编码时考虑到定时器和 maxwait 会冲突的问题，在函数每次被调用的时候都会 clearTimeout(timer)，所以个人 trailing 判断其实只对整个执行流的最后一次有效，而非 lodash 所说的 trailing 控制的是函数在每一个 wait 的最后执行。

而 lodash 并不会清除定时器，只是每次生成新的定时器的时候都会根据 lastCallTime 来计算下一次该执行的时间，不只保证了定时器的准确性，也保证了对每次 trailing 的控制。

为何最后会触发两次

经过打 log 我发现这种触发两次的状况很是凑巧，最后一次函数执行的时候，正好知足前一个时延的 trailing，而后本身这个 wait 的定时器也触发了，因此最后又触发了一次本次时延的 trailing，因此触发了两次。

理论上 lodash 也会出现这种状况，可是它在每次函数执行的时候都会删除 lastArgs 和 lastThis，而下次函数执行的时候都会判断这两个参数是否存在，所以避免了这种状况。

总结

其实以前就知道 debounce 和 throttle 的用途和含义，可是每次用起来都得去看一眼文档，经过此次本身实现以及对源码的阅读，终于作到了了熟于心，也发现本身的代码设计能力仍是有缺陷，一开始并无想的很到位。

写代码的，仍是要多写，多看；慢慢作到会写，会看；与你们共勉。