全局的 setTimeout()  方法設置一個定時器，一旦定時器到期，就會執(zhí)行一個函數(shù)或指定的代碼片段，但是需要注意的是，setTimeout 并不是 ECMAScript 標準的一部分，不過幾乎每一個 JS 運行時都支持了這個函數(shù)。定時器的使用比較簡單，這里不再闡述，我們這篇文章主要聊下關于 setTimeout 有最小時延的相關知識。

一、為什么定時器有最小時延

其實 setTimeout 是有最小時延的，這是為什么呢？有很多因素會導致 setTimeout 的回調(diào)函數(shù)執(zhí)行比設定的預期值更久，這里列舉一些導致定時器出現(xiàn)時延的原因：

1. 函數(shù)過度嵌套

MDN 文檔：在瀏覽器中，每調(diào)用一次定時器的最小間隔是 4ms，這通常是由于函數(shù)嵌套導致（嵌套層級達到一定深度），5 層以上的定時器嵌套會導致至少 4ms 的延遲。

let a = performance.now();
setTimeout(() => {
  let b = performance.now();
  console.log(b - a);
  setTimeout(() => {
    let c = performance.now();
    console.log(c - b);
    setTimeout(() => {
      let d = performance.now();
      console.log(d - c);
      setTimeout(() => {
        let e = performance.now();
        console.log(e - d);
        setTimeout(() => {
          let f = performance.now();
          console.log(f - e);
          setTimeout(() => {
            let g = performance.now();
            console.log(g - f);
          }, 0);
        }, 0);
      }, 0);
    }, 0);
  }, 0);
}, 0);

在瀏覽器中的打印結(jié)果大概是這樣的，和規(guī)范一致，第五次執(zhí)行的時候延遲來到了 4ms 以上：

2. 非活動標簽的超時

為了優(yōu)化后臺標簽的加載損耗（以及降低耗電量），瀏覽器會在非活動標簽中強制執(zhí)行一個最小的超時延遲，如果一個頁面正在使用網(wǎng)絡音頻 API 播放聲音，也可以不執(zhí)行該延遲。

這方面的具體情況與瀏覽器有關：

• Firefox 桌面版和 Chrome 針對不活動標簽都有一個 1 秒的最小超時值
• 安卓版 Firefox 瀏覽器對不活動的標簽有一個至少 15 分鐘的超時，并可能完全卸載它們

3. 追蹤型腳本的節(jié)流

Firefox 對它識別為追蹤型腳本的腳本實施額外的節(jié)流，當在前臺運行時，節(jié)流的最小延遲仍然是 4ms，然而，在后臺標簽中，節(jié)流的最小延遲是 10000 毫秒，即 10 秒，在文檔首次加載后 30 秒開始生效。

4. 超時延遲

如果頁面（或操作系統(tǒng)/瀏覽器）正忙于其他任務，超時也可能比預期的晚，需要注意的一個重要情況是，在調(diào)用 setTimeout() 的線程結(jié)束之前，函數(shù)或代碼片段不能被執(zhí)行。例如：

function foo() {
  console.log("foo 被調(diào)用");
}
setTimeout(foo, 0);
console.log("setTimeout 之后");
 
// 控制臺輸出：
// setTimeout 之后
// foo 被調(diào)用

出現(xiàn)這個結(jié)果的原因是，盡管 setTimeout 以 0ms 的延遲來調(diào)用函數(shù)，但這個任務已經(jīng)被放入了隊列中并且等待下一次執(zhí)行，并不是立即執(zhí)行；隊列中的等待函數(shù)被調(diào)用之前，當前代碼必須全部運行完畢，因此這里運行結(jié)果并非預想的那樣。

5. 在加載頁面時推遲超時

當前標簽頁正在加載時，F(xiàn)irefox 將推遲觸發(fā) setTimeout() 計時器，直到主線程被認為是空閑的，類似于 window.requestIdleCallback()，或者直到加載事件觸發(fā)完畢，才開始觸發(fā)。

二、為什么定時器最小時延是4ms

我們首先要知道是不是存在具體的規(guī)范來指定了 4ms, 還是只是業(yè)界實踐的既定事實？

1. HTML standard

在 HTML standard 8.6 Timers-2020/6/23 中對于 setTimeout() 有詳細的描述，我們只看其中的 10-13 行：

If timeout is less than 0, then set timeout to 0.
If nesting level is greater than 5, and timeout is less than 4, then set timeout to 4.
Increment nesting level by one.
Let task's timer nesting level be nesting level.

從上面的規(guī)范可以看出來：

• 如果設置的 timeout 小于 0，則設置為 0
• 如果嵌套的層級超過了 5 層，并且 timeout 小于 4ms，則設置 timeout 為 4ms

到這里，我們似乎已經(jīng)找到了 4ms 的出處，并且對于 setTimeout 的最小延遲有了更加精確的定義 - 需要同時滿足嵌套層級超過 5 層，timeout 小于 4ms，才會設置 4ms

2. 瀏覽器源碼

除了尋找規(guī)范的出處之外，還可以去瀏覽器的源碼中尋找答案，我們進入到谷歌瀏覽器源碼中來查找用來設置計時器延時的地方：

static const int maxIntervalForUserGestureForwarding = 1000; // One second matches Gecko.
static const int maxTimerNestingLevel = 5;
static const double oneMillisecond = 0.001;
// Chromium uses a minimum timer interval of 4ms. We'd like to go
// lower; however, there are poorly coded websites out there which do
// create CPU-spinning loops.  Using 4ms prevents the CPU from
// spinning too busily and provides a balance between CPU spinning and
// the smallest possible interval timer.
static const double minimumInterval = 0.004;

double intervalMilliseconds = std::max(oneMillisecond, interval * oneMillisecond);
if (intervalMilliseconds < minimumInterval && m_nestingLevel >= maxTimerNestingLevel)
    intervalMilliseconds = minimumInterval;

代碼邏輯很清晰，設置了幾個常量：

• maxTimerNestingLevel = 5，也就是 HTML standard 當中提到的嵌套層級
• minimumInterval = 0.004，也就是 HTML standard 當中說的最小延遲

在第二段代碼中我們會看到，首先會在 延遲時間 和 1ms 之間取一個最大值，換句話說，在不滿足嵌套層級的情況下，最小延遲時間設置為 1ms，這也解釋了為什么在 chrome 中測試 setTimeout 是上面的結(jié)果。

在 chromium 的注釋中，解釋了為什么要設置 minimumInterval = 4ms。簡單來講，本身 chromium 團隊想要設置更低的延遲時間（其實他們期望達到亞毫秒級別），但是由于某些網(wǎng)站對 setTimeout 這種計時器不良的使用，設置延遲過低會導致 CPU-spinning，因此 chromium 做了些測試，選定了 4ms 作為其 minimumInterval。

到這里為止，從瀏覽器廠商角度和 HTML standard 規(guī)范角度都解釋了 4ms 的來源和其更加精確的定義。

三、如何實現(xiàn)立刻執(zhí)行的定時器

假設我們就需要一個「立刻執(zhí)行」的定時器呢？有什么辦法繞過這個 4ms 的延遲嗎，其實可以采用 postMessage 來實現(xiàn)真正 0 延遲的定時器：

(function () {
  var timeouts = [];
  var messageName = 'message-zeroTimeout';
 
  // 保持 setTimeout 的形態(tài)，只接受單個函數(shù)的參數(shù)，延遲始終為 0。
  function setZeroTimeout(fn) {
    timeouts.push(fn);
    window.postMessage(messageName, '*');
  }
 
  function handleMessage(event) {
    if (event.source == window && event.data == messageName) {
      event.stopPropagation();
      if (timeouts.length > 0) {
        var fn = timeouts.shift();
        fn();
      }
    }
  }
 
  window.addEventListener('message', handleMessage, true);
 
  // 把 API 添加到 window 對象上
  window.setZeroTimeout = setZeroTimeout;
})();

由于 postMessage 的回調(diào)函數(shù)的執(zhí)行時機和 setTimeout 類似，都屬于宏任務，所以可以簡單利用 postMessage 和 addEventListener('message') 的消息通知組合，來實現(xiàn)模擬定時器的功能，再利用上面的嵌套定時器的例子來跑一下測試：

全部在 0.1 ~ 0.3 毫秒級別，而且不會隨著嵌套層數(shù)的增多而增加延遲

1. 測試驗證

從理論上來說，由于 postMessage 的實現(xiàn)沒有被瀏覽器引擎限制速度，一定是比 setTimeout 要快的，這里用數(shù)據(jù)進行驗證：分別用 postMessage 版定時器和傳統(tǒng)定時器做一個遞歸執(zhí)行計數(shù)函數(shù)的操作，看看同樣計數(shù)到 100 分別需要花多少時間

function runtest() {
  let output = document.getElementById('output');
  let outputText = document.createTextNode('');
  output.appendChild(outputText);
  function printOutput(line) {
    outputText.data += line + '\n';
  }
 
  let i = 0;
  let startTime = Date.now();
  // 通過遞歸 setZeroTimeout 達到 100 計數(shù)
  // 達到 100 后切換成 setTimeout 來實驗
  function test1() {
    if (++i == 100) {
      let endTime = Date.now();
      printOutput(
        '100 iterations of setZeroTimeout took ' +
          (endTime - startTime) +
          ' milliseconds.'
      );
      i = 0;
      startTime = Date.now();
      setTimeout(test2, 0);
    } else {
      setZeroTimeout(test1);
    }
  }
 
  setZeroTimeout(test1);
 
  // 通過遞歸 setTimeout 達到 100 計數(shù)
  function test2() {
    if (++i == 100) {
      let endTime = Date.now();
      printOutput(
        '100 iterations of setTimeout(0) took ' +
          (endTime - startTime) +
          ' milliseconds.'
      );
    } else {
      setTimeout(test2, 0);
    }
  }
}

結(jié)論如下：

2. Performance 面板分析

我們打開 Performance 面板，看看更直觀的可視化界面中，兩個版本的定時器是如何分布的：

左邊的 postMessage 版本的定時器分布非常密集，大概在 5ms 以內(nèi)就執(zhí)行完了所有的計數(shù)任務

而右邊的 setTimeout 版本相比較下分布的就很稀疏了，而且通過上方的時間軸可以看出，前四次的執(zhí)行間隔大概在 1ms 左右，到了第五次就拉開到 4ms 以上

3. 無延遲的定時器的作用

你可能會有疑問，什么應用場景下需要用到無延遲的定時器？其實在 React 的源碼中，做時間切片的部分就用到了：

const channel = new MessageChannel();
const port = channel.port2;
 
// 每次 port.postMessage() 調(diào)用就會添加一個宏任務
// 該宏任務為調(diào)用 scheduler.scheduleTask 方法
channel.port1.onmessage = scheduler.scheduleTask;
 
const scheduler = {
  scheduleTask() {
    // 挑選一個任務并執(zhí)行
    const task = pickTask();
    const continuousTask = task();
 
    // 如果當前任務未完成，則在下個宏任務繼續(xù)執(zhí)行
    if (continuousTask) {
      port.postMessage(null);
    }
  },
};

React 把任務切分成很多片段，這樣就可以通過把任務交給 postMessage 的回調(diào)函數(shù)，來讓瀏覽器主線程拿回控制權，進行一些更優(yōu)先的渲染任務。

以上就是淺析JavaScript定時器setTimeout的時延問題的詳細內(nèi)容，更多關于JavaScript setTimeout時延的資料請關注腳本之家其它相關文章！