為了不讓使用者多等待一分一秒,為了讓應用程式能有更敏捷的反應,為了讓CPU不落入空轉,現代開發者必然得面對的課題之一,就是非同步程式設計,從低階的多執行緒模式開始,中間曾歷經了回呼、Promise、產生器,以及async、await等各種非同步模型,開發者應認識這些模型的演進目的各是為何,才能瞭解它們的適用場合,以及撰寫時應採取的語意,而不是僅止於API層面的運用。

從Promise說起

實際上,「非同步」是個沒有精確定義的名詞,一般的描述是「執行一件任務,但不想等待,希望在任務完成時獲得通知,以便進行下一步流程」,不想等待的原因是,CPU這段時間可以去執行其他的任務,以免浪費了執行效能,因此,希望進行的非同步任務,往往是一些會阻斷流程的操作,通常是I/O密集型任務,像是檔案讀取、資料庫操作、網路下載等,當然,也可能是耗時運算,在過去,這類任務若不是太複雜的話,可透過基本的執行緒或並行API來實現。

然而,JavaScript在前後端應用的普及,成了各式非同步應用的濫觴,從最早的回呼模式開始,又有了Continuation-passing風格,以及後來更廣為接受的Promise模式,而Promise模式的風行,更連帶使得其他語言也有了類似的API實現,像是guava-libraries的ListenableFuture,或者是JDK8中的CompletableFuture,這些模式在先前專欄〈非同步操作的多種模式〉也曾經做過介紹。

Promise出現的原因,就開發者一般的理解,是為了解決回呼地獄,而造成程式碼難以閱讀的問題,將巢狀的回呼函式,改以readFilePromise(...).then(callback1).then(callback2).then(callback3)這類循序的風格來撰寫,就可以用看似同步的程式碼流程,來撰寫出非同步的執行效果,由於這類風格廣為接受,為了讓API在實作時能有個共通的標準,CommonJS制定了Promises/A規範,後來更基於該規範進一步改進,而有了Promises/A+規範。

不少程式庫是基於Promises/A或Promises/A+規範來實作(儘管兩者在狀態、術語或API上有些不同),像是jQuery,由於一些歷史性的原因,jQuery 1.x與2.x實作遵循的是Promises/A提案,而jQuery 3.x遵循Promises/A+規範,而在ECMAScript 6中,更將Promise納入了語言規範之中,遵循的是Promises/A+的提案。例如在ES6中,可以如下實現一個readFile的功能,並在各自讀取檔案後顯示結果:

function readFile(fileName) {
  return new Promise((resolve, reject) => {
    // 實際讀取檔案
    resolve(content);
  });
}
readFile('file1').then((content) => {
  console.log(content);
})
readFile('file2').then((content) => {
  console.log(content);
})

產生器與非同步

在ES6中,也新增了產生器的語法,有關產生器的介紹,可以參考我先前專欄〈產生器與惰性求值〉的內容。就ES6的語法來說的話,一個函式可以使用*標示它會是個產生器,如果函式需要「傳回」或「返回」結果,可使用yield而不是return,此時會回到呼叫者原有的流程,若呼叫者呼叫了產生器的next()方法,流程又會再度回到產生器上次呼叫yield的地方並執行後續程式碼。

從這點來看,產生器就像是個有多出入口的函式,就呼叫者與被呼叫者的角度來看,兩個流程彼此協同進行,實際上,這樣的機制被稱之為協程(Coroutine),而產生器經常被認為是一種半協程(semicoroutine)。由於每次回到產生器流程時,才會進行下一次值的運算,因此產生器在過去,經常被用在需要惰性求值的場合,用以增加程式執行的效率。

由於產生器在yield的時候,流程可回到呼叫者手中,這意謂著,透過適當的設計,在某些阻斷或耗時操作進行時可執行yield,以回到呼叫者流程,讓呼叫者可以從事其他任務,因而可作為一種實現非同步的方式。舉例來說,可以基於上頭範例中的readFile,實作出以下的產生器:

function * a_task() {
  var content1 = yield readFile('file1');
  console.log(content1);
  var content2 = yield readFile('file2');
  console.log(content2);
}

就程式碼的簡潔與可讀性來說,這個程式好了許多,而且不單是風格看來像是循序,a_task函式的執行也是循序的——yield之後,流程會離開a_task(這時可以去做些別的任務),等到有結果了,讓流程回到上次yield之處並繼續往下執行;相對地,先前readFile('file1').then(...)之後,實際上,流程就直接往下一步進行了,開發者撰寫程式時,因此還是要意識到這個非同步的事實。

語義更清楚的async、await

在上頭的範例中,a_task函式實際會是由另一個設計好的流程來呼叫,有些程式庫做了些不錯的封裝,像是co(https://github.com/tj/co)程式庫,而在ECMAScript的下個版本,也就是ES7中有了個標準的提案,新增了async、await兩個關鍵字,就目前可見的草案來看,若在readFile前加上async,也就是成為async function readFile(fileName)的話,它就成了一個非同步函式(必須傳回Promise)。

另一方面,await可以等待一個Promise物件獲得resolve,取得其結果並傳回,也就是說,先前的a_task,若依現在ES7的草案說明,可以改寫成:

async function a_task() {
  var content1 = await readFile('file1');
  console.log(content1);
  var content2 = await readFile('file2');
  console.log(content2);
}

與使用*及yield相比,async與await的標示顯然更清楚了。實際上,在Python中也有著類似的發展歷程,在Python 3.4時,有個yield from語法,可用來與asyncio模組搭配,實作出基於產生器的非同步功能,然而語義不夠清楚,因此在Python 3.5中增加了async、await加以取代,yield from基於相容而暫時存在,然而不建議使用。

獲取一致的模型

在過去,處理非同步模型時,開發者總得進入另一種思考模式,儘管Promise解決了回呼地獄的問題,讓程式碼能像是循序般的外觀,然而,實際上還是要顧慮到一些非同步的行為,每當思考著現在是同步還是非同步,總是會讓開發者頭痛的不得了。

有了async、await,乍看似乎又多了一個要讓人頭痛(與學習)的API,然而,實際上,是讓開發者有機會使用一致的模型,來同時面對同步與非同步流程的撰寫。

因為,Promise在需要明確區分出非同步流程時,還是有其空間,然而,若想要完全從循序的角度來撰寫程式,async、await就會是種選擇。

作者簡介


Advertisement

更多 iThome相關內容