????????最近在做微信小程序，然而今天在js的異步問(wèn)題上遇到坑。。。眾所周知js的異步機(jī)制是為了提升效率，避免因某一步時(shí)間過(guò)長(zhǎng)而影響整個(gè)程序的運(yùn)行效率，也因此在微信小程序里request接口使用了異步機(jī)制（這是在我實(shí)驗(yàn)后才得知的，之前閱讀小程序的開(kāi)發(fā)文檔并沒(méi)有注意到這一點(diǎn)），首先，我的程序是需要返回信息里邊的數(shù)組來(lái)進(jìn)行顯示，所以異步機(jī)制在這里反而成為阻礙，閑話不多說(shuō)，進(jìn)入正題。
????????首先我想到的是加延時(shí)函數(shù)，既然是異步那就讓函數(shù)等他一會(huì)兒就是了，但是這個(gè)想法在幾分鐘內(nèi)就被我否決了，因?yàn)檠訒r(shí)函數(shù)第一沒(méi)有絲毫的嚴(yán)謹(jǐn)性，第二即使能夠?qū)崿F(xiàn)也會(huì)造成比較大的影響，不僅異步機(jī)制的優(yōu)勢(shì)會(huì)被掩蓋掉，而且會(huì)造成較多的時(shí)間浪費(fèi)。
? ? ? ? 然后通過(guò)上網(wǎng)查閱資料，發(fā)現(xiàn)了一個(gè)js異步問(wèn)題解決神器------------promise:
? ? ? ? 他是這樣說(shuō)的：Promise 是異步編程的一種解決方案，比傳統(tǒng)的解決方案——回調(diào)函數(shù)和事件——更合理和更強(qiáng)大。它由社區(qū)最早提出和實(shí)現(xiàn)，ES6 將其寫(xiě)進(jìn)了語(yǔ)言標(biāo)準(zhǔn)，統(tǒng)一了用法，原生提供了Promise對(duì)象。
所謂Promise，簡(jiǎn)單說(shuō)就是一個(gè)容器，里面保存著某個(gè)未來(lái)才會(huì)結(jié)束的事件（通常是一個(gè)異步操作）的結(jié)果。從語(yǔ)法上說(shuō)，Promise 是一個(gè)對(duì)象，從它可以獲取異步操作的消息。Promise 提供統(tǒng)一的 API，各種異步操作都可以用同樣的方法進(jìn)行處理。
Promise對(duì)象有以下兩個(gè)特點(diǎn)。
（1）對(duì)象的狀態(tài)不受外界影響。Promise對(duì)象代表一個(gè)異步操作，有三種狀態(tài)：pending（進(jìn)行中）、fulfilled（已成功）和rejected（已失敗）。只有異步操作的結(jié)果，可以決定當(dāng)前是哪一種狀態(tài)，任何其他操作都無(wú)法改變這個(gè)狀態(tài)。這也是Promise這個(gè)名字的由來(lái)，它的英語(yǔ)意思就是“承諾”，表示其他手段無(wú)法改變。
（2）一旦狀態(tài)改變，就不會(huì)再變，任何時(shí)候都可以得到這個(gè)結(jié)果。Promise對(duì)象的狀態(tài)改變，只有兩種可能：從pending變?yōu)閒ulfilled和從pending變?yōu)閞ejected。只要這兩種情況發(fā)生，狀態(tài)就凝固了，不會(huì)再變了，會(huì)一直保持這個(gè)結(jié)果，這時(shí)就稱為 resolved（已定型）。如果改變已經(jīng)發(fā)生了，你再對(duì)Promise對(duì)象添加回調(diào)函數(shù)，也會(huì)立即得到這個(gè)結(jié)果。這與事件（Event）完全不同，事件的特點(diǎn)是，如果你錯(cuò)過(guò)了它，再去監(jiān)聽(tīng)，是得不到結(jié)果的。
注意，為了行文方便，本章后面的resolved統(tǒng)一只指fulfilled狀態(tài)，不包含rejected狀態(tài)。
有了Promise對(duì)象，就可以將異步操作以同步操作的流程表達(dá)出來(lái)，避免了層層嵌套的回調(diào)函數(shù)。此外，Promise對(duì)象提供統(tǒng)一的接口，使得控制異步操作更加容易。
Promise也有一些缺點(diǎn)。首先，無(wú)法取消Promise，一旦新建它就會(huì)立即執(zhí)行，無(wú)法中途取消。其次，如果不設(shè)置回調(diào)函數(shù)，Promise內(nèi)部拋出的錯(cuò)誤，不會(huì)反應(yīng)到外部。第三，當(dāng)處于pending狀態(tài)時(shí)，無(wú)法得知目前進(jìn)展到哪一個(gè)階段（剛剛開(kāi)始還是即將完成）。
如果某些事件不斷地反復(fù)發(fā)生，一般來(lái)說(shuō)，使用Stream?模式是比部署Promise更好的選擇。
? ? ? ? 然而這個(gè)仍然不是我想要的結(jié)果，顯然這個(gè)神器對(duì)于我來(lái)說(shuō)太繁瑣復(fù)雜了，解決一個(gè)小小的異步問(wèn)題使用到這么多還是太浪費(fèi)了，然后我就想到了最終的方法------回調(diào)函數(shù)
? ??????因?yàn)榭梢园颜{(diào)用者與被調(diào)用者分開(kāi)，所以調(diào)用者不關(guān)心誰(shuí)是被調(diào)用者。它只需知道存在一個(gè)具有特定原型和限制條件的被調(diào)用函數(shù)。簡(jiǎn)而言之，回調(diào)函數(shù)就是允許用戶把需要調(diào)用的函數(shù)的指針作為參數(shù)傳遞給一個(gè)函數(shù)，以便該函數(shù)在處理相似事件的時(shí)候可以靈活的使用不同的方法。
? ? ? ? 這樣看來(lái)就簡(jiǎn)單多了，直接上代碼吧。
? ? ? ? 這樣之前的傳值無(wú)法接收的問(wèn)題就完美解決了，是不是很簡(jiǎn)單呢？
