一般知道,js腳步語言的執行環境是單線程的,就是它會等一個任務完成,纔會進行第二個任務,然後一直向下進行,這樣的執行環境簡單,但是處理不了複雜的運用,當一個請求需要非常舊的時間的時候,下一個流程就會被擱淺,如果長時間得不到反饋,進程就這樣的奔潰了。
爲了解決這個硬性需求,Javascript語言提出了二種語言模式: 同步(Synchronous)和 異步 (Asynchronous)。
異步的幾種常用方法
回調函數
訂閱和發佈模式
Promise
generator
async/await
回調函數方法
通過把一個函數(callback)作爲參數傳入另一個函數,當滿足一定條件的時候,就執行callback函數。
用法:
通過回調函數的方式處理異步,是在異步早期的情況,其中jquery中的很多都是通過callback來實現回調的。但是這種模式代碼編寫比較耦合,不利於代碼維護。
發佈訂閱模式
pub/sub模式是js設計模式中的一種,本身是借鑑於java的模式,但是在處理異步處理的時候非常有作用。通過一個信息中心EventCenter 來處理的監聽(on)和觸發(triggle)。
通過pub/sub模式,我們可以在信息中心清楚的看到有多少信號來源,方便的集中管理,更加方便於模塊化的管理,但是如果整個項目都使用pub/sub模式的話,流程就變得不太清晰了,數據的得到和數據的處理分開,對於後期的維護也是一個很大的問題。
Promise
Promise構造函數成爲承諾,它分爲三種狀態resolve, reject, pending ,一旦狀態從pending改爲其它2個狀態之後,就不能修改了,就一個承諾一樣。
Promise接收2個參數resolve , reject,分別表示成功後執行和失敗後執行,可以通過實例的then()方法傳遞對於的函數。
這裏看了之後,你可能會說,這個和異步處理有什麼聯繫嗎?你思考一下,當一個異步操作後,我們可以不去管它什麼時候結束,什麼時候出錯,就像一個人承諾了,我只需要按照他的承諾去當這個事情已經被處理好了,是不是方便很多,下面直接上手一個例子。
我完全不用擔心它裏面怎麼實現了,反正它已經承諾了會給我結果,我只需要通過then()方法去接受,我需要得到的值就可以了。
Promise.resolve(value) value可以是三種值
單個值
一個promsie實例
一個thenable對象
Promise.resolve(value).then((value) => {})
處理一個請求依賴另一個請求的情況
如果一個請求的結果是下一個請求的參數,如果我們使用原始的請求方法,就是出現一個像右的箭頭的回調地獄。
一層層嵌套,非常的恐怖,不利於維護。那麼通過prmise怎麼處理回調地獄呢?
上面處理回調地獄是不是看着方便很多,代碼也簡單命令,依賴性也很強,後面我們會繼續通過async/await繼續簡化。
處理多個請求併發的情況(不需要管服務器的返回順序)
Promise.all(arr) 接受一個promise實例的數組,可以併發多個請求給服務器,但是並不能保證接受到的先後順序,這個取決於服務器的處理速度。
處理多個請求併發,並且需要保證返回數據的順序(運用場景比較少)
上面一個方法並不會保證請求返回的結果,按照你發送的順序返回,如果我想把完整的響應的結果按照我
希望的順序返回給我,那應該怎麼辦呢?
這樣,會等待每一個請求完成後,並把得到的數據push到totalData中,就可以按照順序得到我們想要的值了。當然使用async/await會更加的方便。之後我們會講解。
generator構造器
generator是一個構造器,generator函數執行並不會執行函數體內部部分,而是返回一個構造器對象,通過構造器對象的next()方法調用函數主體,並且每當遇到yield都會暫停執行,並返回一個對象。
注意yield本身是不會反悔內容的,只是給構造器對象返回了內容,如果想yield表達式也返回內容,可以通過給下一個next()傳遞參數。
通過next()傳遞參數,我們可以做到值向內部傳遞,對於後面的異步處理很有幫助。
generator異步運用
利用構造器的暫停和繼續的功能,我們可以很好的處理異步請求,得到數據後再進行其他內容。主要是運用yield表達式返回一個promise對象的原理。
這樣我們就得到了接口請求的數據,相比於之前的promise函數的書寫是不是要簡單很多。和同步是一樣的操作。
如果我們想內部對得到的數據進行進一步的處理呢?
簡單的co模塊處理generator多個函數請求
從上面我的調用方法就可以看出,利用Promise + generator的異步處理不斷地通過then()方法處理數據。有沒有一個方式是我可以直接運行一個函數,然後就可以得到我想要的值。 例如:
網上已經封裝了很多的方法,例如常見的run庫,co函數就是來處理這樣的處理方式。但是當我們發送多個請求的時候,可能你會這樣寫:
這樣寫是會發送請求,但是並不是併發多個請求,而是等第一個請求p1之後,再進行第二個請求p2,在性能優化方面是不利的,也不符合我們的要求,怎麼做到2個請求是獨立的,並且我們還可以通過得到2個請求的結果後,進行其他請求。或許我們可以這樣:
這樣寫是不是和我們之前寫的Promise.all()很像?所以還可以改成這樣的:
async/await異步處理
ES7出現了async/await進行異步的處理,使得異步操作就像同步代碼一樣簡單,方便了使用,由於async/await內部封裝了generator的 處理,所有就很少有人用generator來處理異步了,但是在異步的推動中generator起到了很大的作用。
await: 後面接受一個promise實例
**async: 返回一個promise對象 **
一個簡單的異步請求
上面的例子是不是和generator中的異步請求很像?可以像同步一樣的編寫代碼,但是相比generator,await後面加上promise後直接返回相應的數據,不像yield還需要從外部傳入。
處理多個請求併發的情況(不需要管服務器的返回順序)
用async/await處理多個請求併發,由於await後面需要添加Promise實例,是不是腦袋裏面一下子就想到了一個Promise.all()
你可能會很好奇,爲什麼不需要像generator那樣通過額外的函數來調用,因爲async已經幫你想好了,內部已經調用了,是不是很爽?
處理多個請求併發,並且需要保證返回數據的順序(運用場景比較少)
如果數據中沒有相互的聯繫,但是又想一個個發送,可以這樣