我一度以爲自己很懂Promise,直到前段時間嘗試去實現Promise/A+規範時,才發現自己對Promise的理解還過於淺薄。在我按照Promise/A+規範去寫具體代碼實現的過程中,我經歷了從“很懂”到“陌生”,再到“領會”的過山車式的認知轉變,對Promise有了更深刻的認識!
TL;DR:鑑於很多人不想看長文,這裏直接給出我寫的Promise/A+規範的Javascript實現。
-
github倉庫:promises-aplus-robin [1](順手點個star就更好了) -
源碼 [2] -
源碼註釋版 [3]
promises-tests測試用例是全部通過的。
Promise源於現實世界
Promise直譯過來就是承諾,最新的紅寶書已經將其翻譯爲期約。當然,這都不重要,程序員之間只要一個眼神就懂了。
許下承諾
作爲打工人,我們不可避免地會接到各種餅,比如口頭吹捧的餅、升值加薪的餅、股權激勵的餅......
有些餅馬上就兌現了,比如口頭褒獎,因爲它本身沒有給企業帶來什麼成本;有些餅卻關乎企業實際利益,它們可能未來可期,也可能猴年馬月,或是無疾而終,又或者直接宣告畫餅失敗。
畫餅這個動作,於Javascript而言,就是創建一個Promise實例:
const bing = new Promise((resolve, reject) => {
// 祝各位的餅都能圓滿成功
if ('畫餅成功') {
resolve('大家happy')
} else {
reject('有難同當')
}
})
Promise跟這些餅很像,分爲三種狀態:
-
pending: 餅已畫好,坐等實現。 -
fulfilled: 餅真的實現了,走上人生巔峯。 -
rejected: 不好意思,畫餅失敗,emmm...
訂閱承諾
有人畫餅,自然有人接餅。所謂“接餅”,就是對於這張餅的可能性做下設想。如果餅真的實現了,鄙人將別墅靠海;如果餅失敗了,本打工仔以淚洗面。
轉換成Promise中的概念,這是一種訂閱的模式,成功和失敗的情況我們都要訂閱,並作出反應。訂閱是通過then
,catch
等方法實現的。
// 通過then方法進行訂閱
bing.then(
// 對畫餅成功的情況作出反應
success => {
console.log('別墅靠海')
},
// 對畫餅失敗的情況作出反應
fail => {
console.log('以淚洗面...')
}
)
鏈式傳播
衆所周知,老闆可以給高層或領導們畫餅,而領導們拿着老闆畫的餅,也必須給底下員工繼續畫餅,讓打工人們雞血不停,這樣大家的餅才都有可能兌現。
這種自上而下發餅的行爲與Promise的鏈式調用在思路上不謀而合。
bossBing.then(
success => {
// leader接過boss的餅,繼續往下面發餅
return leaderBing
}
).then(
success => {
console.log('leader畫的餅真的實現了,別墅靠海')
},
fail => {
console.log('leader畫的餅炸了,以淚洗面...')
}
)
總體來說,Promise與現實世界的承諾還是挺相似的。
而Promise在具體實現上還有很多細節,比如異步處理的細節,Resolution算法,等等,這些在後面都會講到。下面我會從自己對Promise的第一印象講起,繼而過渡到對宏任務與微任務的認識,最終揭開Promise/A+規範的神祕面紗。
初識Promise
還記得最早接觸Promise的時候,我感覺能把ajax過程封裝起來就挺“厲害”了。那個時候對Promise的印象大概就是:優雅的異步封裝,不再需要寫高耦合的callback。
這裏臨時手擼一個簡單的ajax封裝作爲示例說明:
function isObject(val) {
return Object.prototype.toString.call(val) === '[object Object]';
}
function serialize(params) {
let result = '';
if (isObject(params)) {
Object.keys(params).forEach((key) => {
let val = encodeURIComponent(params[key]);
result += `${key}=${val}&`;
});
}
return result;
}
const defaultHeaders = {
"Content-Type": "application/x-www-form-urlencoded"
}
// ajax簡單封裝
function request(options) {
return new Promise((resolve, reject) => {
const { method, url, params, headers } = options
const xhr = new XMLHttpRequest();
if (method === 'GET' || method === 'DELETE') {
// GET和DELETE一般用querystring傳參
const requestURL = url + '?' + serialize(params)
xhr.open(method, requestURL, true);
} else {
xhr.open(method, url, true);
}
// 設置請求頭
const mergedHeaders = Object.assign({}, defaultHeaders, headers)
Object.keys(mergedHeaders).forEach(key => {
xhr.setRequestHeader(key, mergedHeaders[key]);
})
// 狀態監聽
xhr.onreadystatechange = function () {
if (xhr.readyState === 4) {
if (xhr.status === 200) {
resolve(xhr.response)
} else {
reject(xhr.status)
}
}
}
xhr.onerror = function(e) {
reject(e)
}
// 處理body數據,發送請求
const data = method === 'POST' || method === 'PUT' ? serialize(params) : null
xhr.send(data);
})
}
const options = {
method: 'GET',
url: '/user/page',
params: {
pageNo: 1,
pageSize: 10
}
}
// 通過Promise的形式調用接口
request(options).then(res => {
// 請求成功
}, fail => {
// 請求失敗
})
以上代碼封裝了ajax的主要過程,而其他很多細節和各種場景覆蓋就不是幾十行代碼能說完的。不過我們可以看到,Promise封裝的核心就是:
-
封裝一個函數,將包含異步過程的代碼包裹在構造Promise的executor中,所封裝的函數最後需要return這個Promise實例。 -
Promise有三種狀態,Pending, Fulfilled, Rejected。而 resolve()
,reject()
是狀態轉移的觸發器。 -
確定狀態轉移的條件,在本例中,我們認爲ajax響應且狀態碼爲200時,請求成功(執行 resolve()
),否則請求失敗(執行reject()
)。
ps: 實際業務中,除了判斷HTTP狀態碼,我們還會另外判斷內部錯誤碼(業務系統中前後端約定的狀態code)。
實際上現在有了axios這類的解決方案,我們也不會輕易選擇自行封裝ajax,不鼓勵重複造這種基礎且重要的輪子,更別說有些場景我們往往難以考慮周全。當然,在時間允許的情況下,可以學習其源碼實現。
宏任務與微任務
要理解Promise/A+規範,必須先溯本求源,Promise與微任務息息相關,所以我們有必要先對宏任務和微任務有個基本認識。
在很長一段時間裏,我都沒有太多去關注宏任務(Task)與微任務(Microtask)。甚至有一段時間,我覺得setTimeout(fn, 0)
在操作動態生成的DOM元素時非常好用,然而並不知道其背後的原理,實質上這跟Task聯繫緊密。
var button = document.createElement('button');
button.innerText = '新增輸入框'
document.body.append(button)
button.onmousedown = function() {
var input = document.createElement('input');
document.body.appendChild(input);
setTimeout(function() {
input.focus();
}, 0)
}
如果不使用setTimeout 0
,focus()
會沒有效果。
那麼,什麼是宏任務和微任務呢?我們慢慢來揭開答案。
現代瀏覽器採用多進程架構,這一點可以參考Inside look at modern web browser[4]。而和我們前端關係最緊密的就是其中的Renderer Process,Javascript便是運行在Renderer Process的Main Thread中。
Renderer: Controls anything inside of the tab where a website is displayed.
渲染進程控制了展示在Tab頁中的網頁的一切事情。可以理解爲渲染進程就是專門爲具體的某個網頁服務的。
我們知道,Javascript可以直接與界面交互。假想一下,如果Javascript採用多線程策略,各個線程都能操作DOM,那最終的界面呈現到底以誰爲準呢?這顯然是存在矛盾的。因此,Javascript選擇使用單線程模型的一個重要原因就是:爲了保證用戶界面的強一致性。
爲了保證界面交互的連貫性和平滑度,Main Thread中,Javascript的執行和頁面的渲染會交替執行(出於性能考慮,某些情況下,瀏覽器判斷不需要執行界面渲染,會略過渲染的步驟)。目前大多數設備的屏幕刷新率爲60次/秒,1幀大約是16.67ms,在這1幀的週期內,既要完成Javascript的執行,還要完成界面的渲染(if necessary),利用人眼的殘影效應,讓用戶覺得界面交互是非常流暢的。
用一張圖看看1幀的基本過程,引用自https://aerotwist.com/blog/the-anatomy-of-a-frame/
PS:requestIdleCallback是空閒回調,在1幀的末尾,如果還有時間富餘,就會調用requestIdleCallback。注意不要在requestIdleCallback中修改DOM,或者讀取佈局信息導致觸發Forced Synchronized Layout,否則會引發性能和體驗問題。具體見Using requestIdleCallback[5]。
我們知道,一個網頁中的Render Process只有一個Main Thread,本質上來說,Javascript的任務在執行階段都是按順序執行,但是JS引擎在解析Javascript代碼時,會把代碼分爲同步任務和異步任務。同步任務直接進入Main Thread執行;異步任務進入任務隊列,並關聯着一個異步回調。
在一個web app中,我們會寫一些Javascript代碼或者引用一些腳本,用作應用的初始化工作。在這些初始代碼中,會按照順序執行其中的同步代碼。而在這些同步代碼執行的過程中,會陸陸續續監聽一些事件或者註冊一些異步API(網絡相關,IO相關,等等...)的回調,這些事件處理程序和回調就是異步任務,異步任務會進入任務隊列,並且在接下來的Event Loop中被處理。
異步任務又分爲Task和Microtask,各自有單獨的數據結構和內存來維護。
用一個簡單的例子來感受下:
var a = 1;
console.log('a:', a)
var b = 2;
console.log('b:', b)
setTimeout(function task1(){
console.log('task1:', 5)
Promise.resolve(6).then(function microtask2(res){
console.log('microtask2:', res)
})
}, 0)
Promise.resolve(4).then(function microtask1(res){
console.log('microtask1:', res)
})
var b = 3;
console.log('c:', c)
以上代碼執行後,依次在控制檯輸出:
a: 1
b: 2
c: 3
microtask1: 4
task1: 5
microtask2: 6
仔細一看也沒什麼難的,但是這背後發生的細節,還是有必要探究下。我們不妨先問自己幾個問題,一起來看下吧。
Task和Microtask都有哪些?
-
Tasks: -
setTimeout
-
setInterval
-
MessageChannel
-
I/0(文件,網絡)相關API -
DOM事件監聽:瀏覽器環境 -
setImmediate
:Node環境,IE好像也支持(見caniuse數據) -
Microtasks: -
requestAnimationFrame
:瀏覽器環境 -
MutationObserver
:瀏覽器環境 -
Promise.prototype.then
,Promise.prototype.catch
,Promise.prototype.finally
-
process.nextTick
:Node環境 -
queueMicrotask
requestAnimationFrame是不是微任務?
requestAnimationFrame
簡稱rAF
,經常被我們用來做動畫效果,因爲其回調函數執行頻率與瀏覽器屏幕刷新頻率保持一致,也就是我們通常說的它能實現60FPS的效果。在rAF
被大範圍應用前,我們經常使用setTimeout
來處理動畫。但是setTimeout
在主線程繁忙時,不一定能及時地被調度,從而出現卡頓現象。
那麼rAF
屬於宏任務或者微任務嗎?其實很多網站都沒有給出定義,包括MDN上也描述得非常簡單。
我們不妨自己問問自己,rAF
是宏任務嗎?我想了一下,顯然不是,rAF
可以用來代替定時器動畫,怎麼能和定時器任務一樣被Event Loop調度呢?
我又問了問自己,rAF
是微任務嗎?rAF
的調用時機是在下一次瀏覽器重繪之前,這看起來和微任務的調用時機差不多,曾讓我一度認爲rAF
是微任務,而實際上rAF
也不是微任務。爲什麼這麼說呢?請運行下這段代碼。
function recursionRaf() {
requestAnimationFrame(() => {
console.log('raf回調')
recursionRaf()
})
}
recursionRaf();
你會發現,在無限遞歸的情況下,rAF
回調正常執行,瀏覽器也可正常交互,沒有出現阻塞的現象。
而如果rAF
是微任務的話,則不會有這種待遇。不信你可以翻到後面一節內容「如果Microtask執行時又創建了Microtask,怎麼處理?」。
所以,rAF
的任務級別是很高的,擁有單獨的隊列維護。在瀏覽器1幀的週期內,rAF
與Javascript執行,瀏覽器重繪是同一個Level的。(其實,大家在前面那張「解剖1幀」的圖中也能看出來了。)
Task和Microtask各有1個隊列?
最初,我認爲既然瀏覽器區分了Task和Microtask,那就只要各自安排一個隊列存儲任務即可。事實上,Task根據task source的不同,安排了獨立的隊列。比如Dom事件屬於Task,但是Dom事件有很多種類型,爲了方便user agent細分Task並精細化地安排各種不同類型Task的處理優先級,甚至做一些優化工作,必須有一個task source來區分。同理,Microtask也有自己的microtask task source。
具體解釋見HTML標準中的一段話:
Essentially, task sources are used within standards to separate logically-different types of tasks, which a user agent might wish to distinguish between. Task queues *are used by user agents to coalesce task sources within a given event loop。
Task和Microtask的消費機制是怎樣的?
An event loop has one or more task queues. A task queue is a set of tasks.
javascript是事件驅動的,所以Event Loop是異步任務調度的核心。雖然我們一直說任務隊列,但是Tasks在數據結構上不是隊列(Queue),而是集合(Set)。在每一輪Event Loop中,會取出第一個runnable的Task(第一個可執行的Task,並不一定是順序上的第一個Task)進入Main Thread執行,然後再檢查Microtask隊列並執行隊列中所有Microtask。
說再多,都不如一張圖直觀,請看!
Task和Microtask什麼時候進入相應隊列?
回過頭來看,我們一直在提這個概念“異步任務進入隊列”,那麼就有個疑問,Task和Microtask到底是什麼時候進入相應的隊列?我們重新來捋捋。異步任務有註冊,進隊列,回調被執行這三個關鍵行爲。註冊很好理解,代表這個任務被創建了;而回調被執行則代表着這個任務已經被主線程撈起並執行了。但是,在進隊列這一行爲上,宏任務和微任務的表現是不一樣的。
宏任務進隊列
對於Task而言,任務註冊時就會進入隊列,只是任務的狀態還不是runnable,不具備被Event Loop撈起的條件。
我們先用Dom事件爲例舉個例子。
document.body.addEventListener('click', function(e) {
console.log('被點擊了', e)
})
當addEventListener
這行代碼被執行時,任務就註冊了,代表有一個用戶點擊事件相關的Task進入任務隊列。那麼這個宏任務什麼時候才變成runnable呢?當然是用戶點擊發生並且信號傳遞到瀏覽器Render Process的Main Thread後,此時宏任務變成runnable狀態,纔可以被Event Loop撈起,進入Main Thread執行。
這裏再舉個例子,順便解釋下爲什麼setTimeout 0
會有延遲。
setTimeout(function() {
console.log('我是setTimeout註冊的宏任務')
}, 0)
執行setTimeout
這行代碼時,相應的宏任務就被註冊了,並且Main Thread會告知定時器線程,“你定時0毫秒後給我一個消息”。定時器線程收到消息,發現只要等待0毫秒,立馬就給Main Thread一個消息,“我這邊已經過了0毫秒了”。Main Thread收到這個回覆消息後,就把相應宏任務的狀態置爲runnable,這個宏任務就可以被Event Loop撈起了。
可以看到,經過這樣一個線程間通信的過程,即便是延時0毫秒的定時器,其回調也並不是在真正意義上的0毫秒之後執行,因爲通信過程就需要耗費時間。網上有個觀點說setTimeout 0
的響應時間最少是4ms,其實也是有依據的,不過也是有條件的。
HTML Living Standard: If nesting level is greater than 5, and timeout is less than 4, then set timeout to 4.
對於這種說法,我覺得自己有個概念就行,不同瀏覽器在實現規範的細節上肯定不一樣,具體通信過程也不詳,是不是4ms也不好說,關鍵是你有沒有搞清楚這背後經歷了什麼。
微任務進隊列
前面我們提到一個觀點,執行完一個Task後,如果Microtask隊列不爲空,會把Microtask隊列中所有的Microtask都取出來執行。我認爲,Microtask不是在註冊時就進入Microtask隊列,因爲Event Loop處理Microtask隊列時,並不會判斷Microtask的狀態。反過來想,如果Microtask在註冊時就進入Microtask隊列,就會存在Microtask還未變爲runnable狀態就被執行的情況,這顯然是不合理的。我的觀點是,Microtask在變爲runnable狀態時才進入Microtask隊列。
那麼我們來分析下Microtask什麼時候變成runnable狀態,首先來看看Promise。
var promise1 = new Promise((resolve, reject) => {
resolve(1);
})
promise1.then(res => {
console.log('promise1微任務被執行了')
})
讀者們,我的第一個問題是,Promise的微任務什麼時候被註冊?new Promise
的時候?還是什麼時候?不妨來猜一猜!
答案是.then
被執行的時候。(當然,還有.catch
的情況,這裏只是就這個例子說)。
那麼Promise微任務的狀態什麼時候變成runnable呢?相信不少讀者已經有了頭緒了,沒錯,就是Promise狀態發生轉移的時候,在本例中也就是resolve(1)
被執行的時候,Promise狀態由pending轉移爲fulfilled。在resolve(1)
執行後,這個Promise微任務就進入Microtask隊列了,並且將在本次Event Loop中被執行。
基於這個例子,我們再來加深下難度。
var promise1 = new Promise((resolve, reject) => {
setTimeout(() => {
resolve(1);
}, 0);
});
promise1.then(res => {
console.log('promise1微任務被執行了');
});
在這個例子中,Promise微任務的註冊和進隊列並不在同一次Event Loop。怎麼說呢?在第一個Event Loop中,通過.then
註冊了微任務,但是我們可以發現,new Promise
時,執行了一個setTimeout
,這是相當於註冊了一個宏任務。而resolve(1)
必須在宏任務被執行時纔會執行。很明顯,兩者中間隔了至少一次Event Loop。
如果能分析Promise微任務的過程,你自然就知道怎麼分析ObserverMutation微任務的過程了,這裏不再贅述。
如果Microtask執行時又創建了Microtask,怎麼處理?
我們知道,一次Event Loop最多隻執行一個runnable的Task,但是會執行Microtask隊列中的所有Microtask。如果在執行Microtask時,又創建了新的Microtask,這個新的Microtask是在下次Event Loop中被執行嗎?答案是否定的。微任務可以添加新的微任務到隊列中,並在下一個任務開始執行之前且當前Event Loop結束之前執行完所有的微任務。請注意不要遞歸地創建微任務,否則會陷入死循環。
下面就是一個糟糕的示例。
// bad case
function recursionMicrotask() {
Promise.resolve().then(() => {
recursionMicrotask()
})
}
recursionMicrotask();
請不要輕易嘗試,否則頁面會卡死哦!(因爲Microtask佔着Main Thread不釋放,瀏覽器渲染都沒辦法進行了)
爲什麼要區分Task和Microtask?
這是一個非常重要的問題。爲什麼不在執行完Task後,直接進行瀏覽器渲染這一步驟,而要再加上執行Microtask這一步呢?其實在前面的問題中已經解答過了。一次Event Loop只會消費一個宏任務,而微任務隊列在被消費時有“繼續上車”的機制,這就讓開發者有了更多的想象力,對代碼的控制力會更強。
做幾道題熱熱身?
在衝擊Promise/A+規範前,不妨先用幾個習題來測試下自己對Promise的理解程度。
基本操作
function mutationCallback(mutationRecords, observer) {
console.log('mt1')
}
const observer = new MutationObserver(mutationCallback)
observer.observe(document.body, { attributes: true })
Promise.resolve().then(() => {
console.log('mt2')
setTimeout(() => {
console.log('t1')
}, 0)
document.body.setAttribute('test', "a")
}).then(() => {
console.log('mt3')
})
setTimeout(() => {
console.log('t2')
}, 0)
這道題就不分析了,答案:mt2 mt1 mt3 t2 t1
瀏覽器不講武德?
Promise.resolve().then(() => {
console.log(0);
return Promise.resolve(4);
}).then((res) => {
console.log(res)
})
Promise.resolve().then(() => {
console.log(1);
}).then(() => {
console.log(2);
}).then(() => {
console.log(3);
}).then(() => {
console.log(5);
}).then(() =>{
console.log(6);
})
這道題據說是字節內部流出的一道題,說實話我剛看到的時候也是一頭霧水。經過我在Chrome測試,得到的答案確實很有規律,就是:0 1 2 3 4 5 6。
先輸出0,再輸出1,我還能理解,爲什麼輸出2和3後又突然跳到4呢,瀏覽器你不講武德啊!
emm...我被戴上了痛苦面具!
那麼這背後的執行順序到底是怎樣的呢?仔細分析下,你會發現還是有跡可循的。
老規矩,第一個問題,這道題的代碼執行過程中,產生了多少個微任務?可能很多人認爲是7個,但實際上應該是8個。
編號 | 註冊時機 | 異步回調 |
---|---|---|
mt1 | .then() | console.log(0);return Promise.resolve(4); |
mt2 | .then(res) | console.log(res) |
mt3 | .then() | console.log(1); |
mt4 | .then() | console.log(2); |
mt5 | .then() | console.log(3); |
mt6 | .then() | console.log(5); |
mt7 | .then() | console.log(6); |
mt8 | return Promise.resolve(4) 執行並且execution context stack清空後,隱式註冊 |
隱式回調(未體現在代碼中),目的是讓mt2變成runnable狀態 |
-
同步任務執行,註冊mt1~mt7七個微任務,此時execution context stack爲空,並且mt1和mt3的狀態變爲runnable。JS引擎安排mt1和mt3進入Microtask隊列(通過 HostEnqueuePromiseJob實現)。 -
Perform a microtask checkpoint,由於mt1和mt3是在同一次JS call中變爲runnable的,所以mt1和mt3的回調先後進入execution context stack執行。 -
mt1回調進入execution context stack執行, 輸出0,返回 Promise.resolve(4)
。mt1出隊列。由於mt1回調返回的是一個狀態爲fulfilled的Promise,所以之後JS引擎會安排一個job(job是ecma中的概念,等同於微任務的概念,這裏先給它編號mt8),其回調目的是讓mt2的狀態變爲fulfilled( 前提是當前execution context stack is empty)。所以緊接着還是先執行mt3的回調。 -
mt3回調進入execution context stack執行, 輸出1,mt4變爲runnable狀態,execution context stack is empty,mt3出隊列。 -
由於此時mt4已經是runnable狀態,JS引擎安排mt4進隊列,接着JS引擎會安排mt8進隊列。 -
接着,mt4回調進入execution context stack執行, 輸出2,mt5變爲runnable,mt4出隊列。JS引擎安排mt5進入Microtask隊列。 -
mt8回調執行,目的是讓mt2變成runnable狀態,mt8出隊列。mt2進隊列。 -
mt5回調執行, 輸出3,mt6變爲runnable,mt5出隊列。mt6進隊列。 -
mt2回調執行, 輸出4,mt2出隊列。 -
mt6回調執行, 輸出5,mt7變爲runnable,mt6出隊列。mt7進隊列。 -
mt7回調執行, 輸出6,mt7出隊列。執行完畢!總體來看,輸出結果依次爲: 0 1 2 3 4 5 6。
對這塊執行過程尚有疑問的朋友,可以先往下看看Promise/A+規範和ECMAScript262規範中關於Promise的約定,再回過頭來思考,也歡迎留言與我交流!
經過我在Edge瀏覽器測試,結果是:0 1 2 4 3 5 6。可以看到,不同瀏覽器在實現Promise的主流程上是吻合的,但是在一些細枝末節上還有不一致的地方。實際應用中,我們只要注意規避這種問題即可。
實現Promise/A+
熱身完畢,接下來就是直面大boss Promise/A+規範[6]。Promise/A+規範列舉了大大小小三十餘條細則,一眼看過去還是挺暈的。
仔細閱讀多遍規範之後,我有了一個基本認識,要實現Promise/A+規範,關鍵是要理清其中幾個核心點。
關係鏈路
本來寫了大幾千字有點覺得疲倦了,於是想着最後這部分就用文字講解快速收尾,但是最後這節寫到一半時,我覺得我寫不下去了,純文字的東西太乾了,幹得沒法吸收,這對那些對Promise掌握程度不夠的讀者來說是相當不友好的。所以,我覺得還是先用一張圖來描述一下Promise的關係鏈路。
首先,Promise它是一個對象,而Promise/A+規範則是圍繞着Promise的原型方法.then()
展開的。
-
.then()
的特殊性在於,它會返回一個新的Promise實例,在這種連續調用.then()
的情況下,就會串起一個Promise鏈,這與原型鏈又有一些相似之處。“恬不知恥”地再推薦一篇 「思維導圖學前端 」6k字一文搞懂Javascript對象,原型,繼承 [7],哈哈哈。 -
另一個靈活的地方在於, p1.then(onFulfilled, onRejected)
返回的新Promise實例p2,其狀態轉移的發生是在p1的狀態轉移發生之後(這裏的 之後指的是異步的之後)。並且,p2的狀態轉移爲Fulfilled還是Rejected,這一點取決於onFulfilled
或onRejected
的返回值,這裏有一個較爲複雜的分析過程,也就是後面所述的Promise Resolution Procedure算法。
我這裏畫了一個簡單的時序圖,畫圖水平很差,只是爲了讓讀者們先有個基本印象。
其中還有很多細節是沒提到的(因爲細節真的太多了,全部畫出來就相當複雜,具體過程請看我文末附的源碼)。
nextTick
看了前面內容,相信大家都有一個概念,微任務是一個異步任務,而我們要實現Promise的整套異步機制,必然要具備模擬微任務異步回調的能力。在規範中也提到了這麼一條信息:
This can be implemented with either a “macro-task” mechanism such as setTimeout or setImmediate, or with a “micro-task” mechanism such as MutationObserver or process.nextTick.
我這裏選擇的是用微任務來實現異步回調,如果用宏任務來實現異步回調,那麼在Promise微任務隊列執行過程中就可能會穿插宏任務,這就不太符合微任務隊列的調度邏輯了。這裏還對Node環境和瀏覽器環境做了兼容,Node環境中可以使用process.nextTick
回調來模擬微任務的執行,而在瀏覽器環境中我們可以選擇MutationObserver
。
function nextTick(callback) {
if (typeof process !== 'undefined' && typeof process.nextTick === 'function') {
process.nextTick(callback)
} else {
const observer = new MutationObserver(callback)
const textNode = document.createTextNode('1')
observer.observe(textNode, {
characterData: true
})
textNode.data = '2'
}
}
狀態轉移
-
Promise實例一共有三種狀態,分別是Pending, Fulfilled, Rejected,初始狀態是Pending。
const PROMISE_STATES = {
PENDING: 'pending',
FULFILLED: 'fulfilled',
REJECTED: 'rejected'
}
class MyPromise {
constructor(executor) {
this.state = PROMISE_STATES.PENDING;
}
// ...其他代碼
} -
一旦Promise的狀態發生轉移,就不可再轉移爲其他狀態。
/**
* 封裝Promise狀態轉移的過程
* @param {MyPromise} promise 發生狀態轉移的Promise實例
* @param {*} targetState 目標狀態
* @param {*} value 伴隨狀態轉移的值,可能是fulfilled的值,也可能是rejected的原因
*/
function transition(promise, targetState, value) {
if (promise.state === PROMISE_STATES.PENDING && targetState !== PROMISE_STATES.PENDING) {
// 2.1: state只能由pending轉爲其他態,狀態轉移後,state和value的值不再變化
Object.defineProperty(promise, 'state', {
configurable: false,
writable: false,
enumerable: true,
value: targetState
})
// ...其他代碼
}
} -
觸發狀態轉移是靠調用
resolve()
或reject()
實現的。當resolve()
被調用時,當前Promise也不一定會立即變爲Fulfilled狀態,因爲傳入resolve(value)
方法的value有可能也是一個Promise,這個時候,當前Promise必須追蹤傳入的這個Promise的狀態,整個確定Promise狀態的過程是通過Promise Resolution Procedure算法實現的,具體細節封裝到了下面代碼中的resolvePromiseWithValue
函數中。當reject()
被調用時,當前Promise的狀態就是確定的,一定是Rejected,此時可以通過transition
函數(封裝了狀態轉移的細節)將Promise的狀態進行轉移,並執行後續動作。// resolve的執行,是一個觸發信號,基於此進行下一步的操作
function resolve(value) {
resolvePromiseWithValue(this, value)
}
// reject的執行,是狀態可以變爲Rejected的信號
function reject(reason) {
transition(this, PROMISE_STATES.REJECTED, reason)
}
class MyPromise {
constructor(executor) {
this.state = PROMISE_STATES.PENDING;
this.fulfillQueue = [];
this.rejectQueue = [];
// 構造Promise實例後,立刻調用executor
executor(resolve.bind(this), reject.bind(this))
}
}
鏈式追蹤
假設現在有一個Promise實例,我們稱之爲p1。由於promise1.then(onFulfilled, onRejected)
會返回一個新的Promise(我們稱之爲p2),與此同時,也會註冊一個微任務mt1,這個新的p2會追蹤其關聯的p1的狀態變化。
當p1的狀態發生轉移時,微任務mt1回調會在接下來被執行,如果狀態是Fulfilled,則onFulfilled
會被執行,否則onRejected
會被執行。微任務mt1回調執行的結果將作爲決定p2狀態的依據。以下是Fulfilled情況下的部分關鍵代碼,其中promise指的是p1,而chainedPromise指的是p2。
// 回調應異步執行,所以用到了nextTick
nextTick(() => {
// then可能會被調用多次,所以異步回調應該用數組來維護
promise.fulfillQueue.forEach(({ handler, chainedPromise }) => {
try {
if (typeof handler === 'function') {
const adoptedValue = handler(value)
// 異步回調返回的值將決定衍生的Promise的狀態
resolvePromiseWithValue(chainedPromise, adoptedValue)
} else {
// 存在調用了then,但是沒傳回調作爲參數的可能,此時衍生的Promise的狀態直接採納其關聯的Promise的狀態。
transition(chainedPromise, PROMISE_STATES.FULFILLED, promise.value)
}
} catch (error) {
// 如果回調拋出了異常,此時直接將衍生的Promise的狀態轉移爲rejected,並用異常error作爲reason
transition(chainedPromise, PROMISE_STATES.REJECTED, error)
}
})
// 最後清空該Promise關聯的回調隊列
promise.fulfillQueue = [];
})
Promise Resolution Procedure算法
Promise Resolution Procedure算法是一種抽象的執行過程,它的語法形式是[[Resolve]](promise, x)
,接受的參數是一個Promise實例和一個值x,通過值x的可能性,來決定這個Promise實例的狀態走向。如果直接硬看規範,會有點喫力,這裏直接說人話解釋一些細節。
2.3.1
如果promise和值x引用同一個對象,應該直接將promise的狀態置爲Rejected,並且用一個TypeError作爲reject的原因。
If
promise
andx
refer to the same object, rejectpromise
with aTypeError
as the reason.
【說人話】舉個例子,老闆說只要今年業績超過10億,業績就超過10億。這顯然是個病句,你不能拿預期本身作爲條件。正確的玩法是,老闆說只要今年業績超過10億,就發1000萬獎金(嘿嘿,這種事期待一下就好了)。
代碼實現:
if (promise === x) {
// 2.3.1 由於Promise採納狀態的機制,這裏必須進行全等判斷,防止出現死循環
transition(promise, PROMISE_STATES.REJECTED, new TypeError('promise and x cannot refer to a same object.'))
}
2.3.2
如果x是一個Promise實例,promise應該採納x的狀態。
2.3.2 If
x
is a promise, adopt its state [3.4]:2.3.2.1 If
x
is pending,promise
must remain pending untilx
is fulfilled or rejected.2.3.2.2 If/when
x
is fulfilled, fulfillpromise
with the same value.2.3.2.3 If/when
x
is rejected, rejectpromise
with the same reason.
【說人話】小王問領導:“今年會發年終獎嗎?發多少?”領導聽了心裏想,“這個事我之前也在打聽,不過還沒定下來,得看老闆的意思。”,於是領導對小王說:“會發的,不過要等消息!”。
注意,這個時候,領導對小王許下了承諾,但是這個承諾p2的狀態還是pending,需要看老闆給的承諾p1的狀態。
-
可能性1:過了幾天,老闆對領導說:“今年業務做得可以,年終獎發1000萬”。這裏相當於p1已經是fulfilled狀態了,value是1000萬。領導拿了這個準信了,自然可以跟小王兌現承諾p2了,於是對小王說:“年終獎可以下來了,是1000萬!”。這時,承諾p2的狀態就是fulfilled了,value也是1000萬。小王這個時候就“ 別墅靠海”了。
-
可能性2:過了幾天,老闆有點發愁,對領導說:“今年業績不太行啊,年終獎就不發了吧,明年,咱們明年多發點。”顯然,這裏p1就是rejected了,領導一看這情況不對啊,但也沒辦法,只能對小王說:“小王啊,今年公司情況特殊,年終獎就不發了。”這p2也隨之rejected了,小王內心有點炸裂......
注意,Promise A/+規範2.3.2小節這裏有兩個大的方向,一個是x的狀態未定,一個是x的狀態已定。在代碼實現上,這裏有個技巧,對於狀態未定的情況,必須用訂閱的方式來實現,而.then就是訂閱的絕佳途徑。
else if (isPromise(x)) {
// 2.3.2 如果x是一個Promise實例,則追蹤並採納其狀態
if (x.state !== PROMISE_STATES.PENDING) {
// 假設x的狀態已經發生轉移,則直接採納其狀態
transition(promise, x.state, x.state === PROMISE_STATES.FULFILLED ? x.value : x.reason)
} else {
// 假設x的狀態還是pending,則只需等待x狀態確定後再進行promise的狀態轉移
// 而x的狀態轉移結果是不定的,所以兩種情況我們都需要進行訂閱
// 這裏用一個.then很巧妙地完成了訂閱動作
x.then(value => {
// x狀態轉移爲fulfilled,由於callback傳過來的value是不確定的類型,所以需要繼續應用Promise Resolution Procedure算法
resolvePromiseWithValue(promise, value, thenableValues)
}, reason => {
// x狀態轉移爲rejected
transition(promise, PROMISE_STATES.REJECTED, reason)
})
}
}
多的細節咱這篇文章就不一一分析了,寫着寫着快1萬字了,就先結束掉吧,感興趣的讀者可以直接打開源碼看(往下看)。
這是跑測試用例的效果圖,可以看到,872個case是全部通過的。
完整代碼
這裏直接給出我寫的Promise/A+規範的Javascript實現,供大家參考。後面如果有時間,會考慮詳細分析下。
-
github倉庫:promises-aplus-robin [1](順手點個star就更好了) -
源碼 [2] -
源碼註釋版 [3]
缺陷
我這個版本的Promise/A+規範實現,不具備檢測execution context stack爲空的能力,所以在細節上會有一點問題(execution context stack還未清空就插入了微任務),無法適配上面那道「瀏覽器不講武德?」的題目所述場景。
方法論
不管是手寫實現Promise/A+規範,還是實現其他Native Code,其本質上繞不開以下幾點:
-
準確理解Native Code實現的能力,就像你理解一個需求要實現哪些功能點一樣,並確定實現上的優先級。 -
針對每個功能點或者功能描述,逐一用代碼實現,優先打通主幹流程。 -
設計足夠豐富的測試用例,迴歸測試,不斷迭代,保證場景的覆蓋率,最終打造一段優質的代碼。
總結
看到結尾,相信大家也累了,感謝各位讀者的閱讀!希望本文對宏任務和微任務的解讀能給各位讀者帶來一點啓發。Promise/A+規範總體來說還是比較晦澀難懂的,這對新手來說是不太友好的,因此我建議有一定程度的Promise實際使用經驗後再深入學習Promise/A+規範。通過學習和理解Promise/A+規範的實現機制,你會更懂Promise的一些內部細節,對於設計一些複雜的異步過程會有極大的幫助,再不濟也能提升你的異步調試和排錯能力。
這裏還有一些規範和文章可以參考:
-
Promises/A+規範 [6] -
Event Loop Processing Model [8] -
tasks-microtasks-queues-and-schedules [9] -
Jobs and Host Operations to Enqueue Jobs [10]
參考
github倉庫:promises-aplus-robin: https://github.com/cumt-robin/promises-aplus-robin
[2]源碼: https://github.com/cumt-robin/promises-aplus-robin/blob/main/promises-aplus-robin.js
[3]源碼註釋版: https://github.com/cumt-robin/promises-aplus-robin/blob/main/promises-aplus-robin-annotated.js
[4]Inside look at modern web browser: https://developers.google.com/web/updates/2018/09/inside-browser-part1
[5]Using requestIdleCallback: https://developers.google.com/web/updates/2015/08/using-requestidlecallback?hl=en#using_requestidlecallback_to_make_dom_changes
[6]Promise/A+規範: https://promisesaplus.com/
[7]「思維導圖學前端 」6k字一文搞懂Javascript對象,原型,繼承: https://juejin.cn/post/6844904194097299463
[8]Event Loop Processing Model: https://html.spec.whatwg.org/#event-loop-processing-model
[9]tasks-microtasks-queues-and-schedules: https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/
[10]Jobs and Host Operations to Enqueue Jobs: https://tc39.es/ecma262/#sec-jobs
END
“ 分享、點贊、在看 ” 支持一波
本文分享自微信公衆號 - 胡哥有話說(hugeyouhuashuo)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。