得物技術時間切片的實踐與應用

0x1：前言

每一個擁有【高階資深】title的前端工程師，必定會對專案的整體效能優化有自己的獨到見解。這是往前端業務架構方向轉變的必須要具備的能力之一。

本文就給大家介紹一個效能優化的手段之一：時間切片（Time Slicing）

根據W3C效能小組的介紹，超過50ms的任務就是長任務。

表格內容摘抄自使用 RAIL 模型評估效能

根據上面的表格描述我們可以知道，當延遲超過100ms，使用者就會察覺到輕微的延遲。所以為了解決這個問題，每個任務不能超過50ms。

為了避免當延遲超過100ms，使用者就會察覺到輕微的延遲這種情況，我們可以使用兩種方案，一種是Web Worker，另一種是時間 切片 （Time Slicing） 。

0x2：web worker

測試Demo程式碼在此

眾所周知，JavaScript 語言採用的是單執行緒模型，也就是說，所有任務只能在一個執行緒上完成，一次只能做一件事。前面的任務沒做完，後面的任務只能等著。

針對我們業務上來講，一旦我們執行了過多的長任務，執行過程很容易就被阻塞，出現頁面假死的現象。雖然我們可以將任務放在任務佇列中，通過非同步的方式執行，但這並不能改變JS的本質。

所以為了改變這種現狀，whatwg推出了Web Workers。

關於web worker，不需要深入，想了解的同學可以檢視MDN - web worker

1. Web Worker為Web內容在後臺執行緒中執行指令碼提供了一種簡單的方法。
2. 執行緒可以執行任務而不干擾使用者介面。

<!---->

3. 可以使用XMLHttpRequest執行 I/O (儘管responseXML和channel屬性總是為空)。一旦建立， 一個worker 可以將訊息傳送到建立它的JavaScript程式碼, 通過將訊息釋出到該程式碼指定的事件處理程式（反之亦然）。

Worker 執行緒一旦新建成功，就會始終執行，不會被主執行緒上的活動（比如使用者點選按鈕、提交表單）打斷。這樣有利於隨時響應主執行緒的通訊。但是，這也造成了 Worker 比較耗費資源，不應該過度使用，而且一旦使用完畢，就應該關閉。

Web Worker 有以下幾個使用注意點。

1. 同源限制： 分配給 Worker 執行緒執行的指令碼檔案，必須與主執行緒的指令碼檔案同源。
2. DOM 限制： Worker 執行緒所在的全域性物件，與主執行緒不一樣，無法讀取主執行緒所在網頁的 DOM 物件，也無法使用document、window、parent這些物件。但是，Worker 執行緒可以navigator物件和location物件。

<!---->

3. 通訊聯絡： Worker 執行緒和主執行緒不在同一個上下文環境，它們不能直接通訊，必須通過訊息完成。
4. 指令碼限制： Worker 執行緒不能執行alert()方法和confirm()方法，但可以 XMLHttpRequest 物件發出 AJAX 請求。

<!---->

5. 檔案限制： Worker 執行緒無法讀取本地檔案，即不能開啟本機的檔案系統（file://），它所載入的指令碼，必須來自網路。

我們可以看看使用了Web Worker之後的優化效果：

worker.js

self.onmessage = function () {
  const start = performance.now()
  while (performance.now() - start < 1000) {}
  postMessage('done!')
}

myWorker.js

const myWorker = new Worker('./worker.js')
setTimeout(_ => {
  myWorker.postMessage({})
  myWorker.onmessage = function (ev) {
    console.log(ev.data)
  }
}, 5000)

測試Demo程式碼在此 , 有興趣的小夥伴可以down下來學習 。

0x3：什麼是時間切片

時間切片的核心思想是：當一群任務在一個通道內執行，如果當前的任務不能在50毫秒內執行完，那麼為了不阻塞主執行緒，這個任務應該讓出主執行緒的控制權，使瀏覽器可以處理其他任務。讓出控制權意味著停止執行當前任務，讓瀏覽器去執行其他任務，隨後再回來繼續執行沒有執行完的任務。

所以時間切片的目的是不阻塞主執行緒，而實現目的的技術手段是將一個長任務拆分成很多個不超過50ms的小任務分散在巨集任務佇列中執行。

上圖可以看到主執行緒中有一個長任務，這個任務會阻塞主執行緒。使用時間切片將它切割成很多個小任務後，如下圖所示。

可以看到現在的主執行緒有很多密密麻麻的小任務，我們將它放大後如下圖所示。

可以看到每個小任務中間是有空隙的，代表著任務執行了一小段時間後，將讓出主執行緒的控制權，讓瀏覽器執行其他的任務。

使用時間切片的缺點是，任務執行的總時間變長了，這是因為它每處理完一個小任務後，主執行緒會空閒出來，並且在下一個小任務開始處理之前有一小段延遲。

但是為了避免卡死瀏覽器，這種取捨是很有必要的。

0x4：如何實踐時間切片

時間切片充分利用了“非同步”，在早期，可以使用定時器來實現，我們稱之為“手動切片”，例如：

btn.onclick = function () {
  someThing(); // 執行了50毫秒
  setTimeout(function () {
    otherThing(); // 執行了50毫秒
  });
};

上面程式碼當按鈕被點選時，本應執行100毫秒的任務現在被拆分成了兩個50毫秒的任務。

在實際應用中，我們可以進行一些封裝，封裝後的使用效果類似下面這樣：

btn.onclick = timeSlicing([someThing, otherThing], function () {
  console.log('done~');
});

當然，關於timeSlicing這個函式的API的設計並不是本文的重點，這裡想說明的是，在早期可以利用定時器來實現手動方式的“時間切片”；

如果切片的粒度不大，那麼手動自己改造函式其實也能接受，但是如果需要切割成粒度非常小的邏輯，那麼使用generator函式特性，會更加方便。

ES6帶來了迭代器的概念，並提供了生成器Generator函式用來生成迭代器物件，雖然Generator函式最正統的用法是生成迭代器物件，但這不妨我們利用它的特性做一些其他的事情。

Generator函式提供了yield關鍵字，這個關鍵字可以讓函式暫停執行。然後通過迭代器物件的next方法讓函式繼續執行

利用這個特性，我們可以設計出更方便使用的時間切片，例如：

btn.onclick = timeSlicing(function* () {
  someThing(); // 執行了50毫秒
  yield;
  otherThing(); // 執行了50毫秒
});

可以看到，我們只需要使用yield這個關鍵字就可以將本應執行100毫秒的任務拆分成了兩個50毫秒的任務。

我們甚至可以將yield關鍵字放在迴圈裡：

btn.onclick = timeSlicing(function* () {
  while (true) {
    someThing(); // 執行了50毫秒
    yield;
  }
});

上面程式碼我們寫了一個死迴圈，但依然不會阻塞主執行緒，瀏覽器也不會卡死。

下面我們正式利用Generator開始封裝一個時間切片執行器。利用generator的特性把每一次yield都放在requestIdleCallback裡執行，直到全部執行完畢，就可以輕鬆達到時間切片的效果了。

//首先我們封裝一個時間切片執行器
function timeSlicing(gen) {
 if (typeof gen !== "function")
 throw new Error("TypeError: the param expect a generator function");
 var g = gen();
 if (!g || typeof g.next !== "function")
 return;
 return function next() {
 var start = performance.now();
 var res = null;
 do {
 res = g.next();
 } while (res.done !== true && performance.now() - start < 25);
 if (res.done)
 return;
 window.requestIdleCallback(next);
 };
}
//然後把長任務變成generator函式，交由時間切片執行器來控制執行
const add = function(i){
 let item = document.createElement("li");
 item.innerText = 第${i++}條;
 listDom.appendChild(item);
 }
function* gen(){
 let i=0;
 while(i<100000){
 yield add(i);
 i++
 }
}
//使用時間切片來插入10W條資料
function bigInsert(){
 timeSlice(gen)()
}

0x5：時間切片實現斐波那契數列

每學習一門新程式語言，便就會被要求自己重新實現一遍斐波那契數列演算法。那時，常用的方法即遞迴法和遞推法。那時只對結果感興趣，只要結果出來了，其他的彷彿就無所謂了。

在瞭解了generator生成器的方法後，便開始可以嘗試使用generator方法去切片長任務執行。

首先介紹下斐波那契序 0，1，1，2，3，5，8，... 就每一項的值都是前兩項相加得到的。

遞迴方法：

首先，先把之前的遞迴方法再再再實現一遍。

const fibonacci = (n) => {
    if(n === 0 || n === 1)
        return n;
    return fibonacci(n-1) + fibonacci(n-2);
}

// 呼叫
console.log(fibonacci(40))

遞迴的思路很簡單，即不斷呼叫自身方法，直到n為1或0之後，開始一層層返回資料。

使用遞迴計算大數字時，效能會特別低，原因有以下2點：

1. 在遞迴過程中，每建立一個新函式，直譯器都會建立一個新的函式棧幀，並且壓在當前函式的棧幀上，這就形成了呼叫棧。因而，當遞迴層數過大之後，就可能造成呼叫棧佔用記憶體過大或者溢位。
2. 分析可以發現，遞迴造成了大量的重複計算。

generator生成器：

Generator是ES2015的新特性，得益於該特性，我們可以使用生成器方法，製作一個斐波那契數列生成器。

function *fibonacci(n, current = 0, next = 1) {
    if (n === 0) {
        return current;
    }
    yield current;
    yield *fibonacci(n-1, next, current + next);
}

// 呼叫
const [...data] = fibonacci(num)
console.log(data);

測試Demo程式碼在此

0x6：總結

時間切片不是什麼高階的api，而是一種根據瀏覽器渲染特性衍生出的優化方案，是一種優化思想，把計算量過大，容易阻塞渲染的邏輯切割成一個個小的任務來執行，留給瀏覽器渲染的時間來達到肉眼可見的流暢，本質上並沒有優化什麼js的計算效能，所以，有些演算法的邏輯該優化還是需要從演算法的思想上去優化。

文/Davis

關注得物技術，做最潮技術人！