從一道Promise執(zhí)行順序的題目看Promise實(shí)現(xiàn)
之前在網(wǎng)上看到一道Promise執(zhí)行順序的題目——打印以下程序的輸出：
- new Promise(resolve => {
- console.log(1);
- resolve(3);
- }).then(num => {
- console.log(num)
- });
- console.log(2)
這道題的輸出是123，為什么不是132呢？因?yàn)槲乙恢崩斫釶romise是沒有異步功能，它只是幫忙解決異步回調(diào)的問題，實(shí)質(zhì)上是和回調(diào)是一樣的，所以如果按照這個(gè)想法，resolve之后應(yīng)該會(huì)立刻then。但實(shí)際上并不是。難道用了setTimeout？
如果在promise里面再加一個(gè)promise：
- new Promise(resolve => {
- console.log(1);
- resolve(3);
- Promise.resolve().then(()=> console.log(4))
- }).then(num => {
- console.log(num)
- });
- console.log(2)
執(zhí)行順序是1243，第二個(gè)Promise的順序會(huì)比***個(gè)的早，所以直觀來看也是比較奇怪，這是為什么呢？
Promise的實(shí)現(xiàn)有很多庫，有jQuery的deferred，還有很多提供polyfill的，如es6-promise，lie等，它們的實(shí)現(xiàn)都基于Promise/A+標(biāo)準(zhǔn)，這也是ES6的Promise采用的。
為了回答上面題目的執(zhí)行順序問題，必須得理解Promise是怎么實(shí)現(xiàn)的，所以得看那些庫是怎么實(shí)現(xiàn)的，特別是我錯(cuò)誤地認(rèn)為不存在的Promise的異步是怎么實(shí)現(xiàn)的，因?yàn)?**一行的console.log(2)它并不是***執(zhí)行的，那么必定有某些類似于setTimeout的異步機(jī)制讓上面同步的代碼在異步執(zhí)行，所以它才能在代碼執(zhí)行完了之后才執(zhí)行。
當(dāng)然我們不只是為了解答一道題，主要還是借此了解Promise的內(nèi)部機(jī)制。讀者如果有時(shí)間有興趣可以自行分析，然后再回過頭來比較一下本文的分析?；蛘吣憧梢愿旅娴乃悸罚倨鹗髽?biāo)和鍵盤和我一起干。
這里使用lie的庫，相對于es6-promise來說代碼更容易看懂，先npm install一下：
- npm install lie
讓代碼在瀏覽器端運(yùn)行，準(zhǔn)備以下html：
- <!DOCType html>
- <html>
- <head>
- <meta charset="utf-8">
- </head>
- <body>
- <script src="node_modules/lie/dist/lie.js"></script>
- <script src="index.js"></script>
- </body>
- </html>
其中index.js的內(nèi)容為：
- console.log(Promise);
- new Promise(resolve => {
- console.log(1);
- resolve(3);
- Promise.resolve().then(()=> console.log(4))
- }).then(num => {
- console.log(num)
- });
- console.log(2);
把Promise打印一下，確認(rèn)已經(jīng)把原生的那個(gè)覆蓋了，對比如下：
因?yàn)樵腜romise我們是打不了斷點(diǎn)的，所以才需要借助一個(gè)第三方的庫。
我們在第4行的resolve(3)那里打個(gè)斷點(diǎn)進(jìn)去看一下resolve是怎么執(zhí)行的，層層進(jìn)去，***的函數(shù)是這個(gè)：
我們發(fā)現(xiàn)，這個(gè)函數(shù)好像沒干啥，它就是設(shè)置了下self的state狀態(tài)為FULFILLED（完成），并且把結(jié)果outcome設(shè)置為調(diào)resolve傳進(jìn)來的值，這里是3，如果resolve傳來是一個(gè)Promise的話就會(huì)進(jìn)入到上圖187行的Promise鏈處理，這里我們不考慮這種情況。這里的self是指向一個(gè)Promise對象：
它主要有3個(gè)屬性——outcome、queue、state，其中outcome是resolve傳進(jìn)來的結(jié)果，state是Promise的狀態(tài)，在第83行的代碼可以查到Promise的狀態(tài)總共有3種：
- var REJECTED = ['REJECTED'];
- var FULFILLED = ['FULFILLED'];
- var PENDING = ['PENDING'];
Rejected失敗，fulfilled成功，pending還在處理中，在緊接著89行的Promise的構(gòu)造函數(shù)可以看到，state初始化的狀態(tài)為pending：
- function Promise(resolver) {
- if (typeof resolver !== 'function') {
- throw new TypeError('resolver must be a function');
- }
- this.state = PENDING;
- this.queue = [];
- this.outcome = void 0;
- if (resolver !== INTERNAL) {
- safelyResolveThenable(this, resolver);
- }
- }
并且在右邊的調(diào)用棧可以看到，resolver是由Promise的構(gòu)造函數(shù)觸發(fā)執(zhí)行的，即當(dāng)你new Promise的時(shí)候就會(huì)執(zhí)行傳參的函數(shù)，如下圖所示：
傳進(jìn)來的函數(shù)支持兩個(gè)參數(shù)，分別是resolve和reject回調(diào)：
傳進(jìn)來的函數(shù)支持兩個(gè)參數(shù)，分別是resolve和reject回調(diào)：
- let resolver = function(resolve, reject) {
- if (success) resolve();
- else reject();
- };
- new Promise(resolver);
這兩個(gè)函數(shù)是Promise內(nèi)部定義，但是要在你的函數(shù)里調(diào)一下它的函數(shù)，告訴它什么時(shí)候成功了，什么時(shí)候失敗了，這樣它才能繼續(xù)下一步的操作。所以這兩個(gè)函數(shù)參數(shù)是傳進(jìn)來的，它們是Promise的回調(diào)函數(shù)。Promise是怎么定義和傳遞這兩個(gè)函數(shù)的呢？還是在剛剛那個(gè)斷點(diǎn)的位置，但是我們改變一下右邊調(diào)用棧顯示的位置：
上圖執(zhí)行的thenable函數(shù)就是我們傳給它的resolver，然后傳遞onSuccess和onError，分別是我們在resolver里面寫的resolve和reject這兩個(gè)參數(shù)。如果我們調(diào)了它的resolve即onSuccess函數(shù)，它就會(huì)調(diào)236行的handlers.resolve就到了我們***次打斷點(diǎn)的那張圖，這里再放一次：
然后去設(shè)置當(dāng)前Promise對象的state，outcome等屬性。這里沒有進(jìn)入到193行的while循環(huán)里，因?yàn)閝ueue是空的。這個(gè)地方下文會(huì)繼續(xù)提到。
接著，我們在then那里打個(gè)斷點(diǎn)進(jìn)去看一下：
then又做了些什么工作呢？如下圖所示：
then可以傳兩個(gè)參數(shù)，分別為成功回調(diào)和失敗回調(diào)。我們給它傳了一個(gè)成功回調(diào)，即上圖劃線的地方。并且由于在resolver里面已經(jīng)把state置成fulfilled完成態(tài)了，所以它會(huì)執(zhí)行unwrap函數(shù)，并傳遞成功回調(diào)、以及resolve給的結(jié)果outcome（還有一個(gè)參數(shù)promise，主要是用于返回，形成then鏈）。
unwrap函數(shù)是這樣實(shí)現(xiàn)的：
在167行執(zhí)行then里傳給Promise的成功回調(diào)，并傳遞結(jié)果outcome。
這段代碼是包在一個(gè)immediate函數(shù)里的，這里就是解決Promise異步問題的關(guān)鍵了。并且我們在node_modules目錄里面，也發(fā)現(xiàn)了lie使用了immediate庫，它可以實(shí)現(xiàn)一個(gè)nextTick的功能，即在當(dāng)前代碼邏輯單元同步執(zhí)行完了之后立刻執(zhí)行，相當(dāng)于setTimeout 0，但是它又不是直接用setTimeout 0實(shí)現(xiàn)的。
我們重點(diǎn)來看一下它是怎么實(shí)現(xiàn)一個(gè)nextTick的功能的。immediate里面會(huì)調(diào)一個(gè)scheduleDrain（drain是排水的意思）：
- function immediate(task) {
- // 這個(gè)判斷先忽略
- if (queue.push(task) === 1 && !draining) {
- scheduleDrain();
- }
- }
實(shí)現(xiàn)邏輯在這個(gè)scheduleDrain，它是這么實(shí)現(xiàn)的：
- var Mutation = global.MutationObserver || global.WebKitMutationObserver;
- var scheduleDrain = null;
- {
- // 瀏覽器環(huán)境，IE11以上支持
- if (Mutation) {
- // ...
- }
- // Node.js環(huán)境
- else if (!global.setImmediate && typeof global.MessageChannel !== 'undefined')
- }
- // 低瀏覽器版本解決方案
- else if ('document' in global && 'onreadystatechange' in global.document.createElement('script')) {
- }
- // ***實(shí)在沒辦法了，用最次的setTimeout
- else {
- scheduleDrain = function () {
- setTimeout(nextTick, 0);
- };
- }
- }
它會(huì)有一個(gè)兼容性判斷，優(yōu)先使用MutationObserver，然后是使用script標(biāo)簽的方式，這種到IE6都支持，***啥都不行就用setTimeout 0.
我們主要看一下Mutation的方式是怎么實(shí)現(xiàn)的，MDN上有介紹這個(gè)MutationObserver的用法，可以用它來監(jiān)聽DOM結(jié)點(diǎn)的變化，如增刪、屬性變化等。Immediate是這么實(shí)現(xiàn)的：
- if (Mutation) {
- var called = 0;
- var observer = new Mutation(nextTick);
- var element = global.document.createTextNode('');
- // 監(jiān)聽節(jié)點(diǎn)的data屬性的變化
- observer.observe(element, {
- characterData: true
- });
- scheduleDrain = function () {
- // 讓data屬性發(fā)生變化，在0/1之間不斷切換，
- // 進(jìn)而觸發(fā)observer執(zhí)行nextTick函數(shù)
- element.data = (called = ++called % 2);
- };
- }
使用nextTick回調(diào)注冊一個(gè)observer觀察者，然后創(chuàng)建一個(gè)DOM節(jié)點(diǎn)element，成為observer的觀察對象，觀察它的data屬性。當(dāng)需要執(zhí)行nextTick函數(shù)的時(shí)候，就調(diào)一下scheduleDrain改變data屬性，就會(huì)觸發(fā)觀察者的回調(diào)nextTick。它是異步執(zhí)行的，在當(dāng)前代碼單元執(zhí)行完之后立刻之行，但又是在setTimeout 0之前執(zhí)行的，也就是說，以下代碼，***行的5是***輸出的：
- setTimeout(()=> console.log(5), 0);
- new Promise(resolve => {
- console.log(1);
- resolve(3);
- // Promise.resolve().then(()=> console.log(4))
- }).then(num => {
- console.log(num)
- });
- console.log(2);
這個(gè)時(shí)候，我們就可以回答為什么上面代碼的輸出順序是123，而不是132了。***點(diǎn)可以肯定的是1是***輸出的，因?yàn)閚ew一個(gè)Promise之后，傳給它的resolver同步執(zhí)行，所以1***打印。執(zhí)行了resolve(3)之后，就會(huì)把當(dāng)前Promiser對象的state改成完成態(tài)，并記錄結(jié)果outcome。然后跳出來執(zhí)行then，把傳給then的成功回調(diào)給immediate在nextTick執(zhí)行，而nextTick是使用Mutation異步執(zhí)行的，所以3會(huì)在2之后輸出。
如果在promise里面再寫一個(gè)promsie的話，由于里面的promise的then要比外面的promise的then先執(zhí)行，也就是說它的nextTick更先注冊，所以4是在3之前輸出。
這樣基本上就解釋了Promise的執(zhí)行順序的問題。但是我們還沒說它的nextTick是怎么實(shí)現(xiàn)的，上面代碼在執(zhí)行immediate的時(shí)候把成功回調(diào)push到一個(gè)全局的數(shù)組queue里面，而nextTick是把這些回調(diào)按順序執(zhí)行，如下代碼所示：
- function nextTick() {
- draining = true;
- var i, oldQueue;
- var len = queue.length;
- while (len) {
- oldQueue = queue;
- // 把queue清空
- queue = [];
- i = -1;
- // 執(zhí)行當(dāng)前所有回調(diào)
- while (++i < len) {
- oldQueue[i]();
- }
- len = queue.length;
- }
- draining = false;
- }
它會(huì)先把排水的變量draining設(shè)置成true，然后處理完成之后再設(shè)置成false，我們再回顧一下剛剛執(zhí)行immediate的判斷：
- function immediate(task) {
- if (queue.push(task) === 1 && !draining) {
- scheduleDrain();
- }
- }
由于JS是單線程的，所以我覺得這個(gè)draining的變量判斷好像沒有太大的必要。另外一個(gè)判斷，當(dāng)queue為空時(shí)，push一個(gè)變量進(jìn)來，這個(gè)時(shí)候queue只有1個(gè)元素，返回值就為1。所以如果之前已經(jīng)push過了，那么這里就不用再觸發(fā)nextTick，因?yàn)?**次的push會(huì)把所有queue回調(diào)元素都執(zhí)行的，只要保證后面的操作有被push到這個(gè)queue里面就好了。所以這個(gè)判斷是一個(gè)優(yōu)化。
另外，es6-promise的核心代碼是一樣的，只是它把immediate函數(shù)改成asap(as soon as possible)，它也是優(yōu)先使用Mutation.
還有一個(gè)問題，上面說的resolver的代碼是同步，但是我們經(jīng)常用Promise是用在異步的情況，resolve是異步調(diào)的，不是像上面同步調(diào)的，如：
- let resolver = function(resolve) {
- setTimeout(() => {
- // 異步調(diào)用resolve
- resolve();
- }, 2000);
- // resolver執(zhí)行完了還沒執(zhí)行resolve
- };
- new Promise(resolver).then(num => console.log(num));
這個(gè)時(shí)候，同步執(zhí)行完resolver，但還沒執(zhí)行resolve，所以在執(zhí)行then的時(shí)候這個(gè)Promise的state還是pending的，就會(huì)走到134的代碼（剛剛執(zhí)行的是132行的unwrap）：
它會(huì)創(chuàng)建一個(gè)QueueItem然后放到當(dāng)前Promise對象的queue屬性里面（注意這里的queue和上面說的immediate里全局的queue是兩個(gè)不同的變量）。然后異步執(zhí)行結(jié)束調(diào)用resolve，這個(gè)時(shí)候queue不為空了：
就會(huì)執(zhí)行queue隊(duì)列里面的成功回調(diào)。因?yàn)閠hen是可以then多次的，所以成功回調(diào)可能會(huì)有多個(gè)。它也是調(diào)用immediate，在nextTick的時(shí)候執(zhí)行的。
也就是說如果是同步resolve的，是通過MutationObserver/Setimeout 0之類的方式在當(dāng)前的代碼單元執(zhí)行完之后立刻執(zhí)行成功回調(diào)；而如果是異步resolve的，是先把成功回調(diào)放到當(dāng)前Promise對象的一個(gè)隊(duì)列里面，等到異步結(jié)束了執(zhí)行resolve的時(shí)候再用同樣的方式在nextTick調(diào)用成功回調(diào)。
我們還沒說失敗的回調(diào)，但大體是相似的。
【本文是51CTO專欄作者“人人網(wǎng)FED”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系原作者獲取授權(quán)】
