寫一個JavaScript框架：比setTimeout更棒的定時執(zhí)行
這是 JavaScript 框架系列的第二章。在這一章里，我打算講一下在瀏覽器里的異步代碼不同執(zhí)行方式。你將了解定時器和事件循環(huán)之間的不同差異，比如 setTimeout 和 Promises。
這個系列是關(guān)于一個開源的客戶端框架，叫做 NX。在這個系列里，我主要解釋一下寫該框架不得不克服的主要困難。如果你對 NX 感興趣可以參觀我們的 主頁。
這個系列包含以下幾個章節(jié)：
- 項目結(jié)構(gòu)
- 定時執(zhí)行 (當(dāng)前章節(jié))
- 沙箱代碼評估
- 數(shù)據(jù)綁定介紹
- 數(shù)據(jù)綁定與 ES6 代理
- 自定義元素
- 客戶端路由
異步代碼執(zhí)行
你可能比較熟悉 Promise、process.nextTick()、setTimeout()，或許還有 requestAnimationFrame() 這些異步執(zhí)行代碼的方式。它們內(nèi)部都使用了事件循環(huán)，但是它們在精確計時方面有一些不同。
在這一章里，我將解釋它們之間的不同，然后給大家演示怎樣在一個類似 NX 這樣的先進(jìn)框架里面實現(xiàn)一個定時系統(tǒng)。不用我們重新做一個，我們將使用原生的事件循環(huán)來達(dá)到我們的目的。
事件循環(huán)
事件循環(huán)甚至沒有在 ES6 規(guī)范里提到。JavaScript 自身只有任務(wù)(Job)和任務(wù)隊列(job queue)。更加復(fù)雜的事件循環(huán)是在 NodeJS 和 HTML5 規(guī)范里分別定義的，因為這篇是針對前端的，我會在詳細(xì)說明后者。
事件循環(huán)可以被看做某個條件的循環(huán)。它不停的尋找新的任務(wù)來運行。這個循環(huán)中的一次迭代叫做一個滴答(tick)。在一次滴答期間執(zhí)行的代碼稱為一次任務(wù)(task)。
- while (eventLoop.waitForTask()) {
- eventLoop.processNextTask()
- }
任務(wù)是同步代碼，它可以在循環(huán)中調(diào)度其它任務(wù)。一個簡單的調(diào)用新任務(wù)的方式是 setTimeout(taskFn)。不管怎樣， 任務(wù)可能有很多來源，比如用戶事件、網(wǎng)絡(luò)或者 DOM 操作。
任務(wù)隊列
更復(fù)雜一些的是，事件循環(huán)可以有多個任務(wù)隊列。這里有兩個約束條件，相同任務(wù)源的事件必須在相同的隊列，以及任務(wù)必須按插入的順序進(jìn)行處理。除此之外，瀏覽器可以做任何它想做的事情。例如，它可以決定接下來處理哪個任務(wù)隊列。
- while (eventLoop.waitForTask()) {
- const taskQueue = eventLoop.selectTaskQueue()
- if (taskQueue.hasNextTask()) {
- taskQueue.processNextTask()
- }
- }
用這個模型，我們不能精確的控制定時。如果用 setTimeout()瀏覽器可能決定先運行完其它幾個隊列才運行我們的隊列。
微任務(wù)隊列
幸運的是，事件循環(huán)還提供了一個叫做微任務(wù)(microtask)隊列的單一隊列。當(dāng)前任務(wù)結(jié)束的時候，微任務(wù)隊列會清空每個滴答里的任務(wù)。
- while (eventLoop.waitForTask()) {
- const taskQueue = eventLoop.selectTaskQueue()
- if (taskQueue.hasNextTask()) {
- taskQueue.processNextTask()
- }
- const microtaskQueue = eventLoop.microTaskQueue
- while (microtaskQueue.hasNextMicrotask()) {
- microtaskQueue.processNextMicrotask()
- }
- }
最簡單的調(diào)用微任務(wù)的方法是 Promise.resolve().then(microtaskFn)。微任務(wù)按照插入順序進(jìn)行處理，并且由于僅存在一個微任務(wù)隊列，瀏覽器不會把時間弄亂了。
此外，微任務(wù)可以調(diào)度新的微任務(wù)，它將插入到同一個隊列，并在同一個滴答內(nèi)處理。
繪制Rendering
***是繪制Rendering調(diào)度，不同于事件處理和分解，繪制并不是在單獨的后臺任務(wù)完成的。它是一個可以運行在每個循環(huán)滴答結(jié)束時的算法。
在這里瀏覽器又有了許多自由：它可能在每個任務(wù)以后繪制，但是它也可能在好幾百個任務(wù)都執(zhí)行了以后也不繪制。
幸運的是，我們有 requestAnimationFrame()，它在下一個繪制之前執(zhí)行傳遞的函數(shù)。我們最終的事件模型像這樣：
- while (eventLoop.waitForTask()) {
- const taskQueue = eventLoop.selectTaskQueue()
- if (taskQueue.hasNextTask()) {
- taskQueue.processNextTask()
- }
- const microtaskQueue = eventLoop.microTaskQueue
- while (microtaskQueue.hasNextMicrotask()) {
- microtaskQueue.processNextMicrotask()
- }
- if (shouldRender()) {
- applyScrollResizeAndCSS()
- runAnimationFrames()
- render()
- }
- }
現(xiàn)在用我們所知道知識來創(chuàng)建定時系統(tǒng)!
利用事件循環(huán)
和大多數(shù)現(xiàn)代框架一樣，NX 也是基于 DOM 操作和數(shù)據(jù)綁定的。批量操作和異步執(zhí)行以取得更好的性能表現(xiàn)?；谝陨侠碛晌覀冇?Promises、 MutationObservers 和 requestAnimationFrame()。
我們所期望的定時器是這樣的：
- 代碼來自于開發(fā)者
- 數(shù)據(jù)綁定和 DOM 操作由 NX 來執(zhí)行
- 開發(fā)者定義事件鉤子
- 瀏覽器進(jìn)行繪制
步驟 1
NX 寄存器對象基于 ES6 代理 以及 DOM 變動基于MutationObserver (變動觀測器)同步運行(下一節(jié)詳細(xì)介紹)。 它作為一個微任務(wù)延遲直到步驟 2 執(zhí)行以后才做出反應(yīng)。這個延遲已經(jīng)在Promise.resolve().then(reaction) 進(jìn)行了對象轉(zhuǎn)換，并且它將通過變動觀測器自動運行。
步驟 2
來自開發(fā)者的代碼(任務(wù))運行完成。微任務(wù)由 NX 開始執(zhí)行所注冊。 因為它們是微任務(wù)，所以按序執(zhí)行。注意，我們?nèi)匀辉谕粋€滴答循環(huán)中。
步驟 3
開發(fā)者通過 requestAnimationFrame(hook) 通知 NX 運行鉤子。這可能在滴答循環(huán)后發(fā)生。重要的是，鉤子運行在下一次繪制之前和所有數(shù)據(jù)操作之后，并且 DOM 和 CSS 改變都已經(jīng)完成。
步驟 4
瀏覽器繪制下一個視圖。這也有可能發(fā)生在滴答循環(huán)之后，但是絕對不會發(fā)生在一個滴答的步驟 3 之前。
牢記在心里的事情
我們在原生的事件循環(huán)之上實現(xiàn)了一個簡單而有效的定時系統(tǒng)。理論上講它運行的很好，但是還是很脆弱，一個輕微的錯誤可能會導(dǎo)致很嚴(yán)重的 BUG。
在一個復(fù)雜的系統(tǒng)當(dāng)中，最重要的就是建立一定的規(guī)則并在以后保持它們。在 NX 中有以下規(guī)則：
- 永遠(yuǎn)不用 setTimeout(fn, 0) 來進(jìn)行內(nèi)部操作
- 用相同的方法來注冊微任務(wù)
- 微任務(wù)僅供內(nèi)部操作
- 不要干預(yù)開發(fā)者鉤子運行時間
規(guī)則 1 和 2
數(shù)據(jù)反射和 DOM 操作將按照操作順序執(zhí)行。這樣只要不混合就可以很好的延遲它們的執(zhí)行?；旌蠄?zhí)行會出現(xiàn)莫名其妙的問題。
setTimeout(fn, 0) 的行為完全不可預(yù)測。使用不同的方法注冊微任務(wù)也會發(fā)生混亂。例如，下面的例子中 microtask2 不會正確地在 microtask1 之前運行。
- Promise.resolve().then().then(microtask1)
- Promise.resolve().then(microtask2)
規(guī)則 3 和 4
分離開發(fā)者的代碼執(zhí)行和內(nèi)部操作的時間窗口是非常重要的。混合這兩種行為會導(dǎo)致不可預(yù)測的事情發(fā)生，并且它會需要開發(fā)者了解框架內(nèi)部。我想很多前臺開發(fā)者已經(jīng)有過類似經(jīng)歷。
結(jié)論
如果你對 NX 框架感興趣，可以參觀我們的主頁。還可以在 GIT 上找到我們的源代碼。
在下一節(jié)我們再見，我們將討論 沙盒化代碼執(zhí)行!
你也可以給我們留言。
