開發(fā)者的javascript造詣取決于對【動態(tài)】和【異步】這兩個詞的理解水平。
網(wǎng)站建設哪家好,找創(chuàng)新互聯(lián)建站!專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、成都微信小程序、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了柞水免費建站歡迎大家使用!
Promise
技術是【javascript
異步編程】這個話題中非常重要的,它一度讓我感到熟悉又陌生,我熟悉其所有的API
并能夠在編程中相對熟練地運用,卻對其中原理和軟件設計思想感到陌生,即便我讀了很多源碼分析和教程也一度很難理解為什么Promise
這樣一個普通的類能夠實現(xiàn)異步,也曾嘗試著去按照Promise/A+規(guī)范來編寫Promise
,但很快便陷入了一種更大的混亂之中。直到我接觸到一些軟件設計思想以及軟件工程方面的知識后,從代碼之外的角度來理解一些細節(jié)的必要性時,那些陌生才開始一點點消失。
如果你覺得有些新東西很那理解,有很大的原因是因為你和設計者所擁有的基礎知識儲備不是一個水平的,導致你無法理解設計者寫出某段代碼時所基于的指導思想,當你無法理解某些看起來很復雜的東西時,筆者的建議是先了解它希望解決的問題,這個問題或許是具體的業(yè)務邏輯需求,或許是抽象的軟件設計層面的,然后嘗試自己想辦法去解決它,請永遠記得別人是開發(fā)者,你也是,你要做的是面向需求,而不僅僅是跟著別人走。即時最終你沒能開發(fā)出這個模塊而去學習源碼時,你也會發(fā)現(xiàn)面對需求而進行的主動思考對此帶來的幫助。
Promise
的本質,是一個分布式的狀態(tài)機。而PromiseAPI
的本質,就是一個發(fā)布訂閱模型。
Promise
解決了什么問題?
這是一個最基本的問題,Promise
是一個有關可靠性和狀態(tài)管理的編程范式,它通常被認為從代碼層面將javascript
中著名的回調地獄改變成扁平化的寫法,并為指定的業(yè)務邏輯打上狀態(tài)標記,讓開發(fā)者可以更容易地控制代碼執(zhí)行的流程。但事實上Promise
的設計初衷并不是為了實現(xiàn)異步,而且很多開發(fā)者并沒有意識到,回調并不意味著異步?。?!(你傳入另一個函數(shù)的回調函數(shù)有可能被異步執(zhí)行,也有可能被同步執(zhí)行)。想更好地理解Promise
,就必須把【異步】這個標簽從中剝離,而圍繞【狀態(tài)管理】,【可靠性】這些關鍵詞進行展開。
Promise
只是一個類,為什么就能夠實現(xiàn)異步?
Promise
本身的確只是一個普通的類,而且在不依賴ES6
的環(huán)境中,開發(fā)者甚至可以手動實現(xiàn)這樣一個類,在沒有研究Promise
的代碼之前,筆者一直主觀地認為其內部是通過類似于事件監(jiān)聽的機制來實現(xiàn)異步的,否則程序本身怎么會知道發(fā)出的http
請求什么時候返回結果。
這個問題是在筆者學習完EventLoop
和Generator
函數(shù)的相關知識后才理解的,其實Promise
本身并沒有實現(xiàn)異步,javascript
語言中的異步都是通過事件循環(huán)的機制(《javascript基礎修煉(5)——Event Loop(node.js)》)來實現(xiàn)的,簡單地說就是說異步事件的響應是會被事件循環(huán)不斷去主動檢測的,當異步動作滿足了再次被執(zhí)行的條件時(比如http
請求返回了結果,或者在另一個線程開啟的大運算量的邏輯執(zhí)行完畢后返回了消息),就會被加入調用棧來執(zhí)行,Promise
和Generator
只是配合事件循環(huán)來進行狀態(tài)管理和流程控制,它們本身和事件循環(huán)的機制是解耦的。
Promise
作為構造函數(shù)調用而生成實例時到底發(fā)生了什么事情?
這里所指的是下面這樣的代碼:
promise = new Promise(function(resolve, reject){
//....
});
面試中經(jīng)常會問到有關Promise
執(zhí)行次序的問題,很多非常熟悉Promise
用法的讀者也并沒有意識到,實際上傳入的匿名函數(shù)是會同步執(zhí)行的。Promise
所做的事情,是為當前這個不知道何時能完成的動作打上一些狀態(tài)的標記,并傳入兩個用于回收控制權的方法作為參數(shù)來啟動執(zhí)行這個匿名函數(shù),通過then
方法指定的后續(xù)執(zhí)行邏輯會先緩存起來(這里的描述并不嚴謹),當這個異步動作完成后調用resolve
或者reject
方法后,再繼續(xù)執(zhí)行事先被緩存起來的流程。
Promise/A+標準看起來很復雜,該如何去實現(xiàn)?
Promise/A+規(guī)范的確很復雜,我也不建議你直接就通過這樣的方式來了解Promise
的實現(xiàn)細節(jié),【規(guī)范】意味著嚴謹性,也表示其中有很多容錯的機制,這會極大地妨礙你對Promise
核心邏輯的理解,Promise
代碼大的復雜性,在于它對于鏈式調用的支持(如果不需要支持鏈式調用,你會發(fā)現(xiàn)自己幾乎不需要思考就可以分分鐘擼一個Promise
庫出來)。筆者的建議是先想辦法去解決主要問題,再對照Promise/A+規(guī)范去檢視自己的代碼。
Promise為什么要實現(xiàn)鏈式調用?
鏈式調用的實現(xiàn),實現(xiàn)了Promise
的多步驟流程控制功能,對一個多于兩個步驟的流程中,即使沒有實現(xiàn)鏈式調用,Promise
實際上依然可以工作,但當你真的那樣做時,你會發(fā)現(xiàn)它又變成了一個新的回調地獄。
Promise的可靠性是指什么?
Promise
的可靠性指它的狀態(tài)只能被改變一次,之后就不能再修改,且唯一修改它的方法是調用promise
實例中的內部resolve( )
或reject( )
方法,它們是定義在Promise
內部的,從外部無法訪問到,只能通過Promise
內部提供的機制來觸發(fā)判定方法(new Promise(executor)
生成實例時,當還行到executor時,Promise會將內部的resolve
和reject
方法作為實參傳入executor,從而暴露修改自身狀態(tài)的能力),相比之下,普通對象的屬性或者thenable
對象(指擁有then
方法的非Promise實例對象)的屬性都是可以被直接修改的,所以promise
的狀態(tài)和結果被認為是更可靠的。
假設有一個異步的動作A,還有一個希望在A完成以后執(zhí)行的動作B,和一個在B完成以后去執(zhí)行的動作C,我們來看一下Promise
是如何實現(xiàn)流程控制。
A動作開始之前,我們把它丟進Promise
構造函數(shù),Promise
給了A一個控制器(上面有resolve和reject兩個按鈕)和一個帶有兩個抽屜的儲物柜(onFulfilledCallbacks和onRejectedCallbacks),接著給A交代:我已經(jīng)登記好信息了,你去執(zhí)行吧,等你執(zhí)行完以后,如果你認為執(zhí)行成功了,就按一下控制器的resolve按鈕,如果認為執(zhí)行失敗了就按一下reject按鈕,但是你要小心,這個控制器只能用一次,按完它會自動發(fā)送消息,儲物柜上有接收器,如果收到resolve
信號,onFulfilledCallbacks這個抽屜就會打開,如果收到reject
信號,onRejectedCallbacks這個抽屜就會打開,之后另一個柜子就會鎖死,我每隔一段時間會來查看一下你的狀態(tài)(注意這里是在事件循環(huán)中主動輪詢來查看promise
實例是否執(zhí)行結束的),如果我看到你的儲物柜有一個抽屜打開了的話的話,就會把里面的東西拿出來依次執(zhí)行接下來的事情。在這之前,如果有人想關注你的執(zhí)行情況的話,我會讓它留下兩張字條,分別寫下不同的抽屜打開的時需要做的事情,因為最終只有一個抽屜可以打開,他必須得寫兩張字條,除非他只關注某個抽屜的動向,然后使用你這個儲物柜的then
方法就可以把字條塞到對應的柜子里,之后等抽屜打開時,我只需要根據(jù)字條上的信息打電話給他就行了。A覺得這樣是比較穩(wěn)妥的,于是拿著promise給它的控制器去執(zhí)行了。
代碼繼續(xù)執(zhí)行,這時候出現(xiàn)了一個B,B說我得先看看A的執(zhí)行結果,再決定做什么,執(zhí)行器說你也別在這干等著了,A在我們這里存放了一個智能儲物柜,它回頭會把結果遠程發(fā)送回來,你把你的聯(lián)系方式寫在這兩張字條上,然后通過A的儲物柜的then
方法放進去吧,聯(lián)系方式也可以寫成不一樣的,到時候A返回結果的話,對應的抽屜就會打開,我按照你寫的聯(lián)系方式發(fā)消息給你就行了。B想了想也是,于是就寫下了兩個不同的號碼放進了A儲物柜對應的抽屜里,接著就回家睡覺去了。
代碼繼續(xù)執(zhí)行,這時候又出現(xiàn)了一個C,C說我想等B返回結果以后再執(zhí)行,這時候執(zhí)行器犯難了,B還沒出發(fā)呢,我也沒有給它分配回調儲物柜,所以沒辦法用同樣的方式對待C,執(zhí)行器只能對C說,我們這規(guī)定如果沒有對應標記的儲物柜的話,暫時不提供服務,這樣吧,你先把你的聯(lián)系方式寫好交給我,等回頭如果B出發(fā)的話,我會給它分派儲物柜,到時候把你的需求放在對應的抽屜里,等B返回對應結果以后我再通知你,C覺得也行,于是就照做了。但是C走后,執(zhí)行器就想了,要是后面再來DEF都要跟在不同的人后面去執(zhí)行,那這些事情我都得先保管著,這也太累了,而且容易搞亂,不能這么搞啊。
上一會講到在現(xiàn)有機制下缺乏多步驟流程管理的機制,當異步任務A執(zhí)行且沒有返回結果時,后續(xù)所有的動作都被暫存在了執(zhí)行器手里,只能隨著時間推移,當標志性事件發(fā)生時再逐步去分發(fā)事件。為了能夠實現(xiàn)多步驟的流程管理,執(zhí)行器想出了一個方法,為每一個來注冊后續(xù)業(yè)務邏輯的人都提供一個智能儲物柜,這樣在辦理登記時就可以直接將后續(xù)的方法分發(fā)到對應的抽屜里,常見的問題就解決了。
如果沒有鏈式調用,第三節(jié)中的多步驟的偽代碼可能是如下的樣子:
//為了聚焦核心邏輯,下面的偽代碼省略了onReject的回調
promiseA = new Promise(function(resolve, reject){
//A帶著控制器開始執(zhí)行
A(resolve,reject);
});
promiseA.then(function(resA){
//A執(zhí)行結束以后,開始判斷B到底是否要執(zhí)行
promiseB = new Promise(function(resolveB, rejectB){
//如果B需要執(zhí)行,則分配兩個儲物柜,并派發(fā)狀態(tài)控制器,B帶著A返回的數(shù)據(jù)resA開始執(zhí)行
B(resA,resolveB,rejectB);
});
promiseB.then(function(resB){
//B執(zhí)行結束以后,開始判斷C到底是否要執(zhí)行
promiseC = new Promise(function(resolveC, rejectC){
//如果C需要執(zhí)行,則分配兩個儲物柜,并派發(fā)狀態(tài)控制器,C帶著B返回的數(shù)據(jù)resB開始執(zhí)行
C(resB, resolveC, rejectC);
});
//...如果有D的話
})
});
在邏輯流程中僅僅有3個步驟的時候,回調地獄的苗頭就已經(jīng)顯露無疑了。Promise
被設計用來解決回調嵌套過深的問題,如果只能按上面的方法來使用的話顯然是不能滿足需求的。如果可以支持鏈式調用,那么上面代碼的編寫方式就變成了:
//為了聚焦核心邏輯,下面的偽代碼省略了onReject的回調
promiseA = new Promise(function(resolve, reject){
//A帶著控制器開始執(zhí)行
A(resolve,reject);
});
promiseA.then(function(resA){
//在使用then方法向A的儲物柜里存放事件的同時,也生成了自己的儲物柜
return new Promise(function(resolveB, rejectB){
B(resA, resolveB, rejectB);
});
}).then(function(resB){
return new Promise(function(resolveC, rejectC){
C(resB, resolveC, rejectC);
});
}).then(function(resC){
//如果有D動作,則繼續(xù)
})
很明顯,當流程步驟增多時,支持鏈式調用的方法具有更好的擴展性。下一節(jié)講一下Promise
最關鍵的鏈式調用環(huán)節(jié)的實現(xiàn)。
如果需要then
方法支持鏈式調用,則Promise.prototype.then
這個原型方法就需要返回一個新的promise
。事實上即使在最初的時間節(jié)點上來看,后續(xù)注冊的任務也符合在未來某個不確定的時間會返回結果的特點,只是多了一些前置條件的限制。返回新的promise
實例是非常容易做到的,但從代碼編寫的邏輯來理解,這里的promise
到底是什么意思呢?先看一下基本實現(xiàn)的偽代碼:
//為簡化核心邏輯,此處只處理Promise狀態(tài)為PENDING的情況
//同時也省略了容錯相關的代碼
Promise.prototype.then = function(onFulfilled, onRejected){
let that = this;
return new Promise(function(resolve, reject){
//對onFulfilled方法的包裝和歸類
that.onFulfilledCallbacks.push((value) => {
let x = onFulfilled(value);
someCheckMethod(resolve, x, ...args);
});
//對onRejected方法的包裝和歸類
that.onRejectedCallbacks.push((reason) => {
let x = onRejected(reason);
someCheckMethod(reject, x, ...args);
});
});
};
可以看到在支持鏈式調用的機制下,最終被添加至待執(zhí)行隊列中的函數(shù)并不是通過then
方法添加進去的函數(shù),而是通過Promise
包裝為其增加了狀態(tài)信息,并且將這個狀態(tài)改變的控制權交到了onFulfilled
函數(shù)中,onFulfilled
函數(shù)的返回結果,會作為參數(shù)傳入后續(xù)的判定函數(shù),進而影響在執(zhí)行resolve
的執(zhí)行邏輯,這樣就將新promise
控制權暴露在了最外層。
所以,then方法中返回的promise實例,標記的就是添加進去的
onFulfilled
和onRejected
方法的執(zhí)行狀態(tài)。這里的關鍵點在于,onFulfilled
函數(shù)執(zhí)行并返回結果后,才會啟動對于這個promise的決議。
在新的鏈式調用的支持下,上面的故事流程就發(fā)生了變化。當B前來登記事件時,執(zhí)行器說我們這現(xiàn)在推出了一種委托服務,你想知道那個儲物柜的最新動態(tài),就把你的電話寫在字條上放在對應的抽屜里,之后當這個抽屜打開后,我們就會把它返回的信息發(fā)送到你留在字條上的號碼上,我們會給你提供一個智能儲物柜(帶有this._onFulfillCallbacks
抽屜和this._onRejectedCallbacks
抽屜)和一個控制器,這樣別人也可以關注你的動態(tài),但你的控制器暫時不能用,我們將某個消息發(fā)送到你留的手機號碼上時,才會同步激活你的控制器功能,但它也只能作用一次。
再來考慮一種特殊的場景,就是當A動作調用resolve(value )
方法來改變狀態(tài)機的狀態(tài)時,傳入的參數(shù)仍然是一個PENDING
狀態(tài)的promise
,這相當于A說自己已經(jīng)完成了,但是此時卻無法得到執(zhí)行結果,也就不可能將結果作為參數(shù)來啟動對應的apromise._onFulfilledCallbacks
隊列或者apromise_onRejectedCallbacks
隊列,此時只能先等著這個promise
改變狀態(tài),然后才能執(zhí)行對A動作的決議。也就是說A的決議動作要延遲到這個新的promise
被決議以后。用偽代碼來表示這種情況的處理策略就是如下的樣子:
//內部方法
let that = this;//這里的this指向了promise實例
function resolve(result){
if(result instanceof Promise){
return result.then(resolve, reject);
}
//執(zhí)行相應的緩存隊列里的函數(shù)
setTimeout(() => {
if (that.status === PENDING) {
that.status = FULFILLED;
that.value = result;
that.onFulfilledCallbacks.forEach(cb => cb(that.result));
}
});
}
當前promise
實例的決議通過result.then(resolve,reject)被推遲到result返回結果之后,而真正執(zhí)行時所需要操作的對象和屬性,已經(jīng)通過let that = this與實例進行了綁定 。
很多開發(fā)者在這里會覺得非?;靵y,很可能是沒有意識到每一個promise
實例都會生成內部方法resolve( )
和reject( )
,即時當Promise
類實例化的過程結束后,它們依然會被保持在自己的閉包作用域中,在執(zhí)行棧中涉及到多個處于PENDING
狀態(tài)的promise
時,它們的內部方法都是存活的。如果還是覺得抽象,可以利用Chrome的調試工具,將下面的代碼逐步執(zhí)行,并觀察右側調用棧,就可以看到當傳入決議函數(shù)的是另一個promise
時,外層的決議函數(shù)都會以閉包的形式繼續(xù)存在。
let promise1 = new Promise(function(resolve, reject){
setTimeout(function fn1(){
let subpromise = new Promise(function (resolvesub,rejectsub) {
setTimeout(function fn2() {
resolvesub('value from fn2');
},2000);
});
resolve(subpromise);
},2000);
});
promise1.then(function fn3(res) {
console.log(res);
});
【Promise/A+規(guī)范】:https://github.com/promises-aplus/promises-spec
理清了上面各種情況的基本策略后,我們已經(jīng)具備了構建一個相對完備的Promise
模塊的能力。我強烈建議你按照Promise/A+規(guī)范來親自動手實現(xiàn)一下這個模塊,你會發(fā)現(xiàn)在實現(xiàn)的過程中仍然有大量的代碼層面的問題需要解決,但你一定會受益于此。網(wǎng)上有非常多的文章講述如何根據(jù)Promise/A+標準來實現(xiàn)這個庫,可是在筆者看來這并不是什么值得炫耀的事情,就好像對照著攻略在打游戲一樣。
作為工程師,你既要能夠一行一行寫出這樣一個模塊,更要關注規(guī)范為什么要那樣規(guī)定。
【Promise/A+測試套件】: https://github.com/promises-aplus/promises-tests
如果你對照規(guī)范的要求寫出了這個模塊,可以利用官方提供的測試套件(包含800多個測試用例來測試規(guī)范中規(guī)定的各個細節(jié))來測試自己編寫的模塊并完善它。javascript語言中都是通過鴨式辯型來檢測接口的,無論你是怎樣實現(xiàn)規(guī)范的各個要求,只要最終通過測試套件的要求即可。如果你依舊覺得心里沒譜,也可以參考別人的博文來學習Promise
的細節(jié),例如這篇《Promise詳解與實現(xiàn)》就給了筆者很大幫助。
當越過了語言層面的難點后,推薦你閱讀《深入理解Promise五部曲》這個系列的文章。大多數(shù)開發(fā)者對于Promise
的理解和應用都是用來解決回調地獄問題的,而這個系列的文章會讓你從另一個角度重新認識Promise,不得不說文章中用發(fā)布訂閱模式來類比解釋Promise
的實現(xiàn)機制對于筆者理解Promise提供了巨大的幫助,同時它也能夠引發(fā)一些通過學習promise/A+規(guī)范很難意識到的關于精髓和本質的思考。
創(chuàng)新互聯(lián)www.cdcxhl.cn,專業(yè)提供香港、美國云服務器,動態(tài)BGP最優(yōu)骨干路由自動選擇,持續(xù)穩(wěn)定高效的網(wǎng)絡助力業(yè)務部署。公司持有工信部辦法的idc、isp許可證, 機房獨有T級流量清洗系統(tǒng)配攻擊溯源,準確進行流量調度,確保服務器高可用性。佳節(jié)活動現(xiàn)已開啟,新人活動云服務器買多久送多久。
分享標題:javascript基礎修煉(7)——Promise,異步,可靠性-創(chuàng)新互聯(lián)
URL標題:http://jinyejixie.com/article44/depeee.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供靜態(tài)網(wǎng)站、App設計、品牌網(wǎng)站設計、面包屑導航、服務器托管、網(wǎng)站排名
聲明:本網(wǎng)站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內容