[[394615]]

最近一個粉絲去面字節，被面試官問到了這個問題來問我，一聽感覺有點意思，于是對它進行了一番研究，可能研究的過程以及結果不一定是最好的，但是還是記錄一下，為各位提供一些幫助。

拿到這個問題，假設有這樣的場景，我們需要用 setTimeout 做一個動畫，并且需要控制他的頻率，50ms 運行一次，首先我們先上圖，來看看 setTimeout 的表現。

運行代碼如下，通過一個計數器來記錄每一次 setTimeout 的調用，而設定的間隔 * 計數次數，就等于理想狀態下的延遲，通過以下例子來查看我們計時器的準確性。

function timer() { 
   var speed = 50, // 設定間隔 
   counter = 1,  // 計數 
   start = new Date().getTime(); 
    
   function instance() 
   { 
    var ideal = (counter * speed), 
    real = (new Date().getTime() - start); 
     
    counter++; 
    form.ideal.value = ideal; // 記錄理想值 
    form.real.value = real;   // 記錄真實值 
 
    var diff = (real - ideal); 
    form.diff.value = diff;  // 差值 
 
    window.setTimeout(function() { instance(); }, speed); 
   }; 
    
   window.setTimeout(function() { instance(); }, speed); 
} 
timer(); 

而我們如果在 setTimeout 還未執行期間加入一些額外的代碼邏輯，再來看看這個差值。

... 
window.setTimeout(function() { instance(); }, speed); 
for(var x=1, i=0; i<10000000; i++) { x *= (i + 1); } 
} 
... 

可以看出，這大大加劇了誤差。

可以看到隨著時間的推移， setTimeout 實際執行的時間和理想的時間差值會越來越大，這就不是我們預期的樣子。類比真實的場景，對于一些倒計時以及動畫來說都會造成時間的偏差都是不理想的。

那么，從這個現象來看一下，為什么 setTimeout 會不準時呢?

因為我們的代碼往往并不是只有一個 setTimeout，大多數會遇到以下情況。

詳細要從瀏覽器的事件循環講起，但是講事件循環的文章太多了，文本就不再累贅地詳細展開講解。

視頻

• https://www.youtube.com/watch?v=8aGhZQkoFbQ

(國內視頻 https://www.bilibili.com/video/av456657611/)

建議看國外的中英對照字幕，國內的翻譯準確度一般

相關文章

• https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

總結來說，因為瀏覽器頁面是有消息隊列和事件循環來驅動的，創建一個 setTimeout 的時候是將它推進了一個隊列，并沒有立即執行，只有本輪宏任務執行完，才會去檢查當前的消息隊列是否有有到期的任務。

接下來我會用 4 這種方式來探索。

while

想得到準確的，我們第一反應就是如果我們能夠主動去觸發，獲取到最開始的時間，以及不斷去輪詢當前時間，如果差值是預期的時間，那么這個定時器肯定是準確的，那么用 while 可以實現這個功能。

理解起來也很簡單：

代碼如下：

function timer(time) { 
    const startTime = Date.now(); 
    while(true) { 
        const now = Date.now(); 
        if(now - startTime >= time) { 
            console.log('誤差', now - startTime - time); 
            return; 
        } 
    } 
} 
timer(5000); 

打印：誤差 0

顯然這樣的方式很精確，但是我們知道 js 是單線程運行，使用這樣的方式強行霸占線程會使得頁面進入卡死狀態，這樣的結果顯然是不合適的。

Web Worker

那么既然無法在當前主線程避免這個誤差，我們能否另開一個線程去處理呢?當然可以，JavaScript 也提供給我們這樣一個能力，通過 Web Worker 我們就可以在另一個線程來運行我們的代碼。

Web Worker為Web內容在后臺線程中運行腳本提供了一種簡單的方法。線程可以執行任務而不干擾用戶界面。 -- 摘自MDN

一個 worker 的簡單的示例

// main.js 
var myWorker = new Worker('worker.js'); 
 
// 監聽 worker 
myWorker.onmessage = function(e) { 
  result.textContent = e.data; 
  console.log('Message received from worker'); 
} 
first.onchange = function() { 
  // 向 worker 發送數據 
  myWorker.postMessage([first.value,second.value]); 
  console.log('Message posted to worker'); 
} 

// worker.js 
onmessage = function(e) { 
  // 接受主線程的數據 
  console.log('Message received from main script'); 
  var workerResult = 'Result: ' + (e.data[0] * e.data[1]); 
  console.log('Posting message back to main script'); 
  // 向主線程發送數據 
  postMessage(workerResult); 
} 

那么接下來我們就要加 worker 和 while 相結合，以下為創建 worker 部分

// worker生成器 
const createWorker = (fn, options) => { 
    const blob = new Blob(['(' + fn.toString() + ')()']); 
    const url = URL.createObjectURL(blob); 
    if (options) { 
        return new Worker(url, options); 
    } 
    return new Worker(url); 
}  
// worker 部分 
const worker = createWorker(function () { 
    onmessage = function (e) { 
        const date = Date.now(); 
        while (true) { 
            const now = Date.now(); 
            if(now - date >= e.data) { 
                postMessage(1); 
                return; 
            } 
        } 
    } 
}) 

我們通過在 worker 中寫入一個 while 循環，當達到我們的預取時間的時候，再向主線程發送一個完成事件，就不會因為主線程的其他代碼的干擾而造成數據不準的情況。

let isStart = false; 
function timer() { 
    worker.onmessage = function (e) { 
       cb() 
        if (isStart) { 
            worker.postMessage(speed); 
        }  
    } 
    worker.postMessage(speed); 
} 

我們來看一下實際的效果。

我們可以看到執行的時間和理想的時間非常相近，而那細微的差異應該就是線程通訊耗時。

我們再來看看加入額外的代碼邏輯的情況。

... 
if (isStart) { 
   worker.postMessage(speed); 
} 
for (var x = 1, i = 0; i < 10000000; i++) { x *= (i + 1); } 
... 


時間明顯增加了一些，但是增加速度非常緩慢。

雖然我們用 Web Worker 修復時間看似被解決了。但是一方面， worker 線程會被 while 給占用，導致無法接受到信息，多個定時器無法同時執行，另一方面，由于 onmessage 還是屬于事件循環內，如果主線程有大量阻塞還是會讓時間越差越大，因此這并不是個完美的方案。

requestAnimationFrame

先來看看他的定義

window.requestAnimationFrame() 告訴瀏覽器——你希望執行一個動畫，并且要求瀏覽器在下次重繪之前調用指定的回調函數更新動畫。該方法需要傳入一個回調函數作為參數，該回調函數會在瀏覽器下一次重繪之前執行，回調函數執行次數通常是每秒60次，也就是每16.7ms 執行一次，但是并不一定保證為 16.7 ms。

我們也可以嘗試一下將它來模擬 setTimeout。

// 模擬代碼 
function setTimeout2 (cb, delay) { 
    let startTime = Date.now() 
    loop() 
   
    function loop () { 
      const now = Date.now() 
      if (now - startTime >= delay) { 
        cb(); 
        return; 
      } 
      requestAnimationFrame(loop) 
    } 
} 

發現由于 16.7 ms 間隔執行，在使用間隔很小的定時器，很容易導致時間的不準確。

再看看額外代碼的引入效果。

... 
 window.setInterval2(function () { instance(); }, speed); 
} 
for (var x = 1, i = 0; i < 10000000; i++) { x *= (i + 1); } 
... 

略微加劇了誤差的增加，因此這種方案仍然不是一種好的方案。

setTimeout 系統時間補償

這個方案是在 stackoverflow 看到的一個方案，我們來看看此方案和原方案的區別

原方案

setTimeout系統時間補償

當每一次定時器執行時后，都去獲取系統的時間來進行修正，雖然每次運行可能會有誤差，但是通過系統時間對每次運行的修復，能夠讓后面每一次時間都得到一個補償。

function timer() { 
   var speed = 500, 
   counter = 1,  
   start = new Date().getTime(); 
    
   function instance() 
   { 
    var real = (counter * speed), 
    ideal = (new Date().getTime() - start); 
     
    counter++; 
 
    var diff = (ideal - real); 
    form.diff.value = diff; 
 
    window.setTimeout(function() { instance(); }, (speed - diff)); // 通過系統時間進行修復 
 
   }; 
    
   window.setTimeout(function() { instance(); }, speed); 
} 

再來看看加入額外的代碼邏輯的情況。

依舊非常的穩定，因此通過系統的時間補償，能夠讓我們的 setTimeout 變得更加準時，至此我們完成了如何讓 setTimeout 準時的探索。

好了我們最后來總結一下4種方案的優缺點

while Web Worker requestAnimationFrame setTimeout 系統時間補償

我們下期再見~

參考

https://segmentfault.com/q/1010000013909430

https://stackoverflow.com/questions/196027/is-there-a-more-accurate-way-to-create-a-javascript-timer-than-settimeout