為了解決這個(gè)硬性需求，Javascript語言提出了二種語言模式： 同步（Synchronous）和 異步 （Asynchronous）。

異步的幾種常用方法

回調(diào)函數(shù)

訂閱和發(fā)布模式

Promise

generator

async/await

回調(diào)函數(shù)方法

通過把一個(gè)函數(shù)(callback)作為參數(shù)傳入另一個(gè)函數(shù)，當(dāng)滿足一定條件的時(shí)候，就執(zhí)行callback函數(shù)。

用法：

通過回調(diào)函數(shù)的方式處理異步，是在異步早期的情況，其中jquery中的很多都是通過callback來實(shí)現(xiàn)回調(diào)的。但是這種模式代碼編寫比較耦合，不利于代碼維護(hù)。

發(fā)布訂閱模式

pub/sub模式是js設(shè)計(jì)模式中的一種，本身是借鑒于java的模式，但是在處理異步處理的時(shí)候非常有作用。通過一個(gè)信息中心EventCenter 來處理的監(jiān)聽(on)和觸發(fā)(triggle)。

通過pub/sub模式，我們可以在信息中心清楚的看到有多少信號來源，方便的集中管理，更加方便于模塊化的管理，但是如果整個(gè)項(xiàng)目都使用pub/sub模式的話，流程就變得不太清晰了，數(shù)據(jù)的得到和數(shù)據(jù)的處理分開，對于后期的維護(hù)也是一個(gè)很大的問題。

Promise

Promise構(gòu)造函數(shù)成為承諾，它分為三種狀態(tài)resolve, reject, pending ,一旦狀態(tài)從pending改為其它2個(gè)狀態(tài)之后，就不能修改了，就一個(gè)承諾一樣。

Promise接收2個(gè)參數(shù)resolve , reject，分別表示成功后執(zhí)行和失敗后執(zhí)行，可以通過實(shí)例的then()方法傳遞對于的函數(shù)。

這里看了之后，你可能會說，這個(gè)和異步處理有什么聯(lián)系嗎？你思考一下，當(dāng)一個(gè)異步操作后，我們可以不去管它什么時(shí)候結(jié)束，什么時(shí)候出錯，就像一個(gè)人承諾了，我只需要按照他的承諾去當(dāng)這個(gè)事情已經(jīng)被處理好了，是不是方便很多，下面直接上手一個(gè)例子。

我完全不用擔(dān)心它里面怎么實(shí)現(xiàn)了，反正它已經(jīng)承諾了會給我結(jié)果，我只需要通過then()方法去接受，我需要得到的值就可以了。

Promise.resolve(value) value可以是三種值

單個(gè)值

一個(gè)promsie實(shí)例

一個(gè)thenable對象

Promise.resolve(value).then((value) => {})

處理一個(gè)請求依賴另一個(gè)請求的情況

如果一個(gè)請求的結(jié)果是下一個(gè)請求的參數(shù)，如果我們使用原始的請求方法，就是出現(xiàn)一個(gè)像右的箭頭的回調(diào)地獄。

一層層嵌套，非常的恐怖，不利于維護(hù)。那么通過prmise怎么處理回調(diào)地獄呢？

上面處理回調(diào)地獄是不是看著方便很多，代碼也簡單命令，依賴性也很強(qiáng)，后面我們會繼續(xù)通過async/await繼續(xù)簡化。

處理多個(gè)請求并發(fā)的情況（不需要管服務(wù)器的返回順序）

Promise.all(arr) 接受一個(gè)promise實(shí)例的數(shù)組，可以并發(fā)多個(gè)請求給服務(wù)器，但是并不能保證接受到的先后順序，這個(gè)取決于服務(wù)器的處理速度。

處理多個(gè)請求并發(fā)，并且需要保證返回?cái)?shù)據(jù)的順序（運(yùn)用場景比較少）

上面一個(gè)方法并不會保證請求返回的結(jié)果，按照你發(fā)送的順序返回，如果我想把完整的響應(yīng)的結(jié)果按照我

希望的順序返回給我，那應(yīng)該怎么辦呢？

這樣，會等待每一個(gè)請求完成后，并把得到的數(shù)據(jù)push到totalData中，就可以按照順序得到我們想要的值了。當(dāng)然使用async/await會更加的方便。之后我們會講解。

generator構(gòu)造器

generator是一個(gè)構(gòu)造器，generator函數(shù)執(zhí)行并不會執(zhí)行函數(shù)體內(nèi)部部分，而是返回一個(gè)構(gòu)造器對象，通過構(gòu)造器對象的next()方法調(diào)用函數(shù)主體，并且每當(dāng)遇到y(tǒng)ield都會暫停執(zhí)行，并返回一個(gè)對象。

注意yield本身是不會反悔內(nèi)容的，只是給構(gòu)造器對象返回了內(nèi)容，如果想yield表達(dá)式也返回內(nèi)容，可以通過給下一個(gè)next()傳遞參數(shù)。

通過next()傳遞參數(shù)，我們可以做到值向內(nèi)部傳遞，對于后面的異步處理很有幫助。

generator異步運(yùn)用

利用構(gòu)造器的暫停和繼續(xù)的功能，我們可以很好的處理異步請求，得到數(shù)據(jù)后再進(jìn)行其他內(nèi)容。主要是運(yùn)用yield表達(dá)式返回一個(gè)promise對象的原理。

這樣我們就得到了接口請求的數(shù)據(jù)，相比于之前的promise函數(shù)的書寫是不是要簡單很多。和同步是一樣的操作。

如果我們想內(nèi)部對得到的數(shù)據(jù)進(jìn)行進(jìn)一步的處理呢？

簡單的co模塊處理generator多個(gè)函數(shù)請求

從上面我的調(diào)用方法就可以看出，利用Promise + generator的異步處理不斷地通過then()方法處理數(shù)據(jù)。有沒有一個(gè)方式是我可以直接運(yùn)行一個(gè)函數(shù)，然后就可以得到我想要的值。 例如：

網(wǎng)上已經(jīng)封裝了很多的方法，例如常見的run庫，co函數(shù)就是來處理這樣的處理方式。但是當(dāng)我們發(fā)送多個(gè)請求的時(shí)候，可能你會這樣寫：

這樣寫是會發(fā)送請求，但是并不是并發(fā)多個(gè)請求，而是等第一個(gè)請求p1之后，再進(jìn)行第二個(gè)請求p2，在性能優(yōu)化方面是不利的，也不符合我們的要求，怎么做到2個(gè)請求是獨(dú)立的，并且我們還可以通過得到2個(gè)請求的結(jié)果后，進(jìn)行其他請求。或許我們可以這樣：

這樣寫是不是和我們之前寫的Promise.all()很像？所以還可以改成這樣的：

async/await異步處理

ES7出現(xiàn)了async/await進(jìn)行異步的處理，使得異步操作就像同步代碼一樣簡單，方便了使用，由于async/await內(nèi)部封裝了generator的 處理，所有就很少有人用generator來處理異步了，但是在異步的推動中g(shù)enerator起到了很大的作用。

await： 后面接受一個(gè)promise實(shí)例

**async: 返回一個(gè)promise對象 **

一個(gè)簡單的異步請求

上面的例子是不是和generator中的異步請求很像？可以像同步一樣的編寫代碼，但是相比generator，await后面加上promise后直接返回相應(yīng)的數(shù)據(jù)，不像yield還需要從外部傳入。

處理多個(gè)請求并發(fā)的情況（不需要管服務(wù)器的返回順序）

用async/await處理多個(gè)請求并發(fā)，由于await后面需要添加Promise實(shí)例，是不是腦袋里面一下子就想到了一個(gè)Promise.all()

你可能會很好奇，為什么不需要像generator那樣通過額外的函數(shù)來調(diào)用，因?yàn)閍sync已經(jīng)幫你想好了，內(nèi)部已經(jīng)調(diào)用了，是不是很爽？

處理多個(gè)請求并發(fā)，并且需要保證返回?cái)?shù)據(jù)的順序（運(yùn)用場景比較少）

如果數(shù)據(jù)中沒有相互的聯(lián)系，但是又想一個(gè)個(gè)發(fā)送，可以這樣