JavaScript是如何工做的：事件循環和異步編程的崛起 + 5種使用 async/await 更好地編碼方式！

時間 2019-11-12

標籤 javascript 如何事件循環異步編程崛起使用 async await 更好編碼方式欄目 JavaScript 简体版

原文原文鏈接

摘要： 深度理解JS事件循環！！！javascript

Fundebug經受權轉載，版權歸原做者全部。前端

此篇是 JavaScript是如何工做的第四篇，其它三篇能夠看這裏：java

經過第一篇文章回顧在單線程環境中編程的缺陷以及如何解決這些缺陷來構建健壯的JavaScript UI。按照慣例，在本文的最後，分享5個如何使用async/ wait編寫更簡潔代碼的技巧。c++

爲何單線程是一個限制？

在發佈的第一篇文章中，思考了這樣一個問題：當調用堆棧中有函數調用須要花費大量時間來處理時會發生什麼?web

例如，假設在瀏覽器中運行一個複雜的圖像轉換算法。ajax

當調用堆棧有函數要執行時，瀏覽器不能作任何其餘事情——它被阻塞了。這意味着瀏覽器不能渲染，不能運行任何其餘代碼，只是卡住了。那麼你的應用 UI 界面就卡住了，用戶體驗也就不那麼好了。算法

在某些狀況下，這可能不是主要的問題。還有一個更大的問題是一旦你的瀏覽器開始處理調用堆棧中的太多任務，它可能會在很長一段時間內中止響應。這時，不少瀏覽器會拋出一個錯誤，提示是否終止頁面：編程

JavaScript程序的構建塊

你可能在單個.js文件中編寫 JavaScript 應用程序，但能夠確定的是，你的程序由幾個塊組成，其中只有一個正在執行，其他的將在稍後執行。最多見的塊單元是函數。小程序

大多數剛接觸JavaScript的開發人員彷佛都有這樣的問題，就是認爲全部函數都是同步完成，沒有考慮的異步的狀況。以下例子：segmentfault

你可能知道標準 Ajax 請求不是同步完成的，這說明在代碼執行時 Ajax(..) 函數尚未返回任何值來分配給變量 response。

一種等待異步函數返回的結果簡單的方式就是 回調函數：

注意：實際上能夠設置同步Ajax請求，但永遠不要那樣作。若是設置同步Ajax請求，應用程序的界面將被阻塞——用戶將沒法單擊、輸入數據、導航或滾動。這將阻止任何用戶交互，這是一種可怕的作法。

如下是同步 Ajax 地，可是請千萬不要這樣作：

這裏使用Ajax請求做爲示例，你可讓任何代碼塊異步執行。

這能夠經過 setTimeout(callback，milliseconds) 函數來完成。setTimeout 函數的做用是設置一個回調函數milliseconds後執行，以下：

function first() {
    console.log('first');
}
function second() {
    console.log('second');
}
function third() {
    console.log('third');
}
first();
setTimeout(second, 1000); // Invoke `second` after 1000ms
third();

輸出：

first
third
second

解析事件循環

這裏從一個有點奇怪的聲明開始——儘管容許異步 JavaScript 代碼(就像上例討論的setTimeout)，但在ES6以前，JavaScript自己實際上歷來沒有任何內置異步的概念，JavaScript引擎在任何給定時刻只執行一個塊。

那麼，是誰告訴JS引擎執行程序的代碼塊呢?實際上，JS引擎並非單獨運行的——它是在一個宿主環境中運行的，對於大多數開發人員來講，宿主環境就是典型的web瀏覽器或Node.js。實際上，如今JavaScript被嵌入到各類各樣的設備中，從機器人到燈泡，每一個設備表明 JS 引擎的不一樣類型的託管環境。

全部環境中的共同點是一個稱爲事件循環的內置機制，它處理程序的多個塊在一段時間內經過調用調用JS引擎的執行。

這意味着JS引擎只是任意JS代碼的按需執行環境，是宿主環境處理事件運行及結果。

例如，當 JavaScript 程序發出 Ajax 請求從服務器獲取一些數據時，在函數(「回調」)中設置「response」代碼，JS引擎告訴宿主環境:"我如今要推遲執行，但當完成那個網絡請求時，會返回一些數據，請回調這個函數並給數據傳給它"。

而後瀏覽器將偵聽來自網絡的響應，當監聽到網絡請求返回內容時，瀏覽器經過將回調函數插入事件循環來調度要執行的回調函數。如下是示意圖：

這些Web api是什麼?從本質上說，它們是沒法訪問的線程，只能調用它們。它們是瀏覽器的併發部分。若是你是一個Nojs.js開發者，這些就是 c++ 的 Api。

這樣的迭代在事件循環中稱爲**(tick)標記**，每一個事件只是一個函數回調。

讓咱們「執行」這段代碼，看看會發生什麼:

1. 初始化狀態都爲空，瀏覽器控制檯是空的的，調用堆棧也是空的

2. console.log('Hi')添加到調用堆棧中

3. 執行console.log('Hi')

4. console.log('Hi')從調用堆棧中移除。

5. setTimeout(function cb1() { ... }) 添加到調用堆棧。

6. setTimeout(function cb1() { ... }) 執行，瀏覽器建立一個計時器計時，這個做爲Web api的一部分。

7. setTimeout(function cb1() { ... })自己執行完成，並從調用堆棧中刪除。

8. console.log('Bye') 添加到調用堆棧

9. 執行 console.log('Bye')

10. console.log('Bye') 從調用調用堆棧移除

11. 至少在5秒以後，計時器完成並將cb1回調推到回調隊列。

12. 事件循環從回調隊列中獲取cb1並將其推入調用堆棧。

13. 執行cb1並將console.log('cb1')添加到調用堆棧。

14. 執行 console.log('cb1')

15. console.log('cb1') 從調用堆棧中移除

16. cb1 從調用堆棧中移除

快速回顧：

值得注意的是，ES6指定了事件循環應該如何工做，這意味着在技術上它屬於JS引擎的職責範圍，再也不僅僅扮演宿主環境的角色。這種變化的一個主要緣由是ES6中引入了 Promises，由於ES6須要對事件循環隊列上的調度操做進行直接、細度的控制。

setTimeout(…) 是怎麼工做的

須要注意的是，setTimeout(…)不會自動將回調放到事件循環隊列中。它設置了一個計時器。當計時器過時時，環境將回調放到事件循環中，以便未來某個**標記(tick)**將接收並執行它。請看下面的代碼:

setTimeout(myCallback, 1000);

這並不意味着myCallback將在1000毫秒後就立馬執行，而是在1000毫秒後，myCallback被添加到隊列中。可是，若是隊列有其餘事件在前面添加回調剛必須等待先後的執行完後在執行myCallback。

有很多的文章和教程上開始使用異步JavaScript代碼，建議用setTimeout(回調,0)，如今你知道事件循環和setTimeout是如何工做的：調用setTimeout 0毫秒做爲第二個參數只是推遲迴調將它放到回調隊列中，直到調用堆棧是空的。

請看下面的代碼:

console.log('Hi');
setTimeout(function() {
    console.log('callback');
}, 0);
console.log('Bye');

雖然等待時間被設置爲0 ms，但在瀏覽器控制檯的結果以下:

Hi
Bye
callback

ES6的任務隊列是什麼?

ES6中引入了一個名爲「任務隊列」的概念。它是事件循環隊列上的一個層。最爲常見在Promises 處理的異步方式。

如今只討論這個概念，以便在討論帶有Promises的異步行爲時，可以瞭解 Promises 是如何調度和處理。

想像一下：任務隊列是一個附加到事件循環隊列中每一個標記末尾的隊列。某些異步操做可能發生在事件循環的一個標記期間，不會致使一個全新的事件被添加到事件循環隊列中，而是將一個項目(即任務)添加到當前標記的任務隊列的末尾。

這意味着能夠放心添加另外一個功能以便稍後執行，它將在其餘任何事情以前當即執行。

任務還可能建立更多任務添加到同一隊列的末尾。理論上，任務「循環」(不斷添加其餘任務的任等等)能夠無限運行，從而使程序沒法得到轉移到下一個事件循環標記的必要資源。從概念上講，這相似於在代碼中表示長時間運行或無限循環(如while (true) ..)。

任務有點像 setTimeout(callback, 0) 「hack」，但其實現方式是引入一個定義更明確、更有保證的順序：稍後，但越快越好。

回調

正如你已經知道的，回調是到目前爲止JavaScript程序中表達和管理異步最多見的方法。實際上，回調是JavaScript語言中最基本的異步模式。無數的JS程序，甚至是很是複雜的程序，除了一些基本都是在回調異步基礎上編寫的。

然而回調方式仍是有一些缺點，許多開發人員都在試圖找到更好的異步模式。可是，若是不瞭解底層的內容，就不可能有效地使用任何抽象出來的異步模式。

在下一章中，咱們將深刻探討這些抽象，以說明爲何更復雜的異步模式(將在後續文章中討論)是必要的，甚至是值得推薦的。

嵌套回調

請看如下代碼:

咱們有一個由三個函數組成的鏈嵌套在一塊兒，每一個函數表示異步系列中的一個步驟。

這種代碼一般被稱爲「回調地獄」。可是「回調地獄」實際上與嵌套/縮進幾乎沒有任何關係，這是一個更深層次的問題。

首先，咱們等待「單擊」事件，而後等待計時器觸發，而後等待Ajax響應返回，此時可能會再次重複全部操做。

乍一看，這段代碼彷佛能夠將其異步性天然地對應到如下順序步驟:

listen('click', function (e) {
    // ..
});

而後：

setTimeout(function(){
    // ..
}, 500);

接着：

ajax('https://api.example.com/endpoint', function (text){
    // ..
});

最後：

if (text == "hello") {
    doSomething();
}
else if (text == "world") {
    doSomethingElse();
}

所以，這種連續的方式來表示異步代碼彷佛更天然，不是嗎?必定有這樣的方法，對吧?

Promises

請看下面的代碼:

var x = 1;
var y = 2;
console.log(x + y);

這很是簡單：它對x和y的值進行求和，並將其打印到控制檯。可是，若是x或y的值丟失了，仍然須要求值，要怎麼辦?

例如，須要從服務器取回x和y的值，而後才能在表達式中使用它們。假設咱們有一個函數loadX和loadY``，它們分別從服務器加載x和y的值。而後，一旦x和y都被加載，假設咱們有一個函數sum，它對x和y`的值進行求和。

它可能看起來像這樣(很醜，不是嗎?)

這裏有一些很是重要的事情——在這個代碼片斷中，咱們將x和y做爲異步獲取的的值，而且執行了一個函數sum(…)(從外部)，它不關心x或y，也不關心它們是否當即可用。

固然，這種基於回調的粗略方法還有不少不足之處。這只是一個咱們沒必要判斷對於異步請求的值的處理方式一個小步驟而已。

Promise Value

用Promise來重寫上例:

在這個代碼片斷中有兩層Promise。

fetchX 和 fetchY 先直接調用，返回一個promise，傳給 sum。 sum 建立並返回一個Promise，經過調用 then 等待 Promise，完成後，sum 已經準備好了（resolve），將會打印出來。

第二層是 sum(…) 建立的 Promise ( 經過 Promise.all([ ... ]) )而後返回 Promise，經過調用then(…)來等待。當 sum(…) 操做完成時，sum 傳入的兩個 Promise 都執行完後，能夠打印出來了。這裏隱藏了在sum(…)中等待x和y將來值的邏輯。

**注意：**在sum（...）內，Promise.all（[...]）調用建立一個 promise（等待 promiseX 和 promiseY 解析）。而後鏈式調用 .then（...）方法裏再的建立了另外一個 Promise，而後把返回的 x 和和（values[0] + values[1]）進行求和並返回。

所以，咱們在sum（...）末尾調用then（...）方法 — 其實是在返回的第二個 Pwwromise 上運行，而不是由Promise.all([ ... ])建立 Promise。此外，雖然沒有在第二個 Promise 結束時再調用 then方法，其時這裏也建立一個 Promise。

Promise.then(…) 實際上可使用兩個函數，第一個函數用於執行成功的操做，第二個函數用於處理失敗的操做：

若是在獲取x或y時出現錯誤，或者在添加過程當中出現某種失敗，sum(…) 返回的 Promise將被拒絕，傳遞給 then(…) 的第二個回調錯誤處理程序將從 Promise 接收失敗的信息。

從外部看，因爲 Promise 封裝了依賴於時間的狀態（等待底層值的完成或拒絕，Promise 自己是與時間無關的），它能夠按照可預測的方式組成，不須要開發者關心時序或底層的結果。一旦 Promise 決議，此刻它就成爲了外部不可變的值。

可連接調用 Promise 真的頗有用：

建立一個延遲2000ms內完成的 Promise ，而後咱們從第一個then（...）回調中返回，這會致使第二個then（...）等待 2000ms。

注意：由於Promise 一旦被解析，它在外部是不可變的，因此如今能夠安全地將該值傳遞給任何一方，由於它不能被意外地或惡意地修改，這一點在多方遵照承諾的決議時尤爲正確。一方不可能影響另外一方遵照承諾決議的能力，不變性聽起來像是一個學術話題，但它其實是承諾設計最基本和最重要的方面之一，不該該被隨意忽略。

使用 Promise 仍是不用？

關於 Promise 的一個重要細節是要肯定某個值是不是一個實際的Promise 。換句話說，它是否具備像Promise 同樣行爲？

咱們知道 Promise 是由new Promise(…)語法構造的，你可能認爲`` p instanceof Promise`是一個足夠能夠判斷的類型，嗯,不徹底是。

這主要是由於能夠從另外一個瀏覽器窗口(例如iframe)接收 Promise 值，而該窗口或框架具備本身的 Promise 值，與當前窗口或框架中的 Promise 值不一樣，因此該檢查將沒法識別 Promise 實例。

此外，庫或框架能夠選擇性的封裝本身的 Promise，而不使用原生 ES6 的Promise 來實現。事實上，極可能在老瀏覽器的庫中沒有 Promise。

吞掉錯誤或異常

若是在 Promise 建立中，出現了一個javascript一場錯誤(TypeError 或者 ReferenceError)，這個異常會被捕捉，而且使這個 promise 被拒絕。

可是，若是在調用 then(…) 方法中出現了 JS 異常錯誤，那麼會發生什麼狀況呢?即便它不會丟失，你可能會發現它們的處理方式有點使人吃驚，直到你挖得更深一點:

看起來foo.bar()中的異常確實被吞噬了，不過,它不是。然而，還有一些更深層次的問題，咱們沒有注意到。 p.then(…) 調用自己返回另外一個 Promise，該 Promise 將被 TypeError 異常拒絕。

處理未捕獲異常

許多人會說，還有其餘更好的方法。

一個常見的建議是，Promise 應該添加一個 done(…)，這其實是將 Promise 鏈標記爲 「done」。done(…) 不會建立並返回 Promise ，所以傳遞給 done(..) 的回調顯然不會將問題報告給不存在的連接 Promise 。

Promise 對象的回調鏈，無論以 then 方法或 catch 方法結尾，要是最後一個方法拋出錯誤，都有可能沒法捕捉到（由於 Promise 內部的錯誤不會冒泡到全局）。所以，咱們能夠提供一個 done 方法，老是處於回調鏈的尾端，保證拋出任何可能出現的錯誤。

ES8中改進了什麼 ?Async/await （異步/等待）

JavaScript ES8引入了 async/await，這使得使用 Promise 的工做更容易。這裏將簡要介紹async/await 提供的可能性以及如何利用它們編寫異步代碼。

使用 async 聲明異步函數。這個函數返回一個 AsyncFunction 對象。AsyncFunction 對象表示該函數中包含的代碼的異步函數。

調用使用 async 聲明函數時，它返回一個 Promise。當這個函數返回一個值時，這個值只是一個普通值而已，這個函數內部將自動建立一個承諾，並使用函數返回的值進行解析。當這個函數拋出異常時，Promise 將被拋出的值拒絕。

使用 async 聲明函數時能夠包含一個 await 符號，await 暫停這個函數的執行並等待傳遞的 Promise 的解析完成，而後恢復這個函數的執行並返回解析後的值。

async/wait 的目的是簡化使用承諾的行爲

讓看看下面的例子:

function getNumber1() {
    return Promise.resolve('374');
}
// 這個函數與getNumber1相同
async function getNumber2() {
    return 374;
}

相似地，拋出異常的函數等價於返回被拒絕的 Promise 的函數:

function f1() {
    return Promise.reject('Some error');
}
async function f2() {
    throw 'Some error';
}

await 關鍵字只能在異步函數中使用，並容許同步等待 Promise。若是在 async 函數以外使用 Promise，仍然須要使用 then 回調:

還可使用「異步函數表達式」定義異步函數。異步函數表達式與異步函數語句很是類似，語法也幾乎相同。異步函數表達式和異步函數語句之間的主要區別是函數名，能夠在異步函數表達式中省略函數名來建立匿名函數。異步函數表達式能夠用做生命(當即調用的函數表達式)，一旦定義它就會運行。

var loadData = async function() {
    // `rp` is a request-promise function.
    var promise1 = rp('https://api.example.com/endpoint1');
    var promise2 = rp('https://api.example.com/endpoint2');
   
    // Currently, both requests are fired, concurrently and
    // now we'll have to wait for them to finish
    var response1 = await promise1;
    var response2 = await promise2;
    return response1 + ' ' + response2;
}

更重要的是，在全部主流的瀏覽器都支持 async/await:

最後，重要的是不要盲目選擇編寫異步代碼的「最新」方法。理解異步 JavaScript 的內部結構很是重要，瞭解爲何異步JavaScript如此關鍵，並深刻理解所選擇的方法的內部結構。與編程中的其餘方法同樣，每種方法都有優勢和缺點。

編寫高度可維護性、非易碎異步代碼的5個技巧

1. 簡化代碼:

使用 async/await 能夠編寫更少的代碼。每次使用 async/await時，都會跳過一些沒必要要的步驟：使用.then，建立一個匿名函數來處理響應，例如：**

// rp是一個請求 Promise 函數。
rp(‘https://api.example.com/endpoint1').then(function(data) {
    // …
});

和：

// `rp` is a request-promise function.
var response = await rp(‘https://api.example.com/endpoint1');

2. 錯誤處理

Async/wait 可使用相同的代碼結構(衆所周知的try/catch語句)處理同步和異步錯誤。看看它是如何與 Promise 結合的:**

function loadData() {
    try { // Catches synchronous errors.
        getJSON().then(function(response) {
            var parsed = JSON.parse(response);
            console.log(parsed);
        }).catch(function(e) { // Catches asynchronous errors
            console.log(e); 
        });
    } catch(e) {
        console.log(e);
    }
}

與

async function loadData() {
    try {
        var data = JSON.parse(await getJSON());
        console.log(data);
    } catch(e) {
        console.log(e);
    }
}

3. 條件

用async/ wait編寫條件代碼要簡單得多:

function loadData() {
  return getJSON()
    .then(function(response) {
      if (response.needsAnotherRequest) {
        return makeAnotherRequest(response)
          .then(function(anotherResponse) {
            console.log(anotherResponse)
            return anotherResponse
          })
      } else {
        console.log(response)
        return response
      }
    })
}

與

async function loadData() {
  var response = await getJSON();
  if (response.needsAnotherRequest) {
    var anotherResponse = await makeAnotherRequest(response);
    console.log(anotherResponse)
    return anotherResponse
  } else {
    console.log(response);
    return response;    
  }
}

4. 錯誤堆棧

與 async/await不一樣，從 Promise 鏈返回的錯誤堆棧不提供錯誤發生在哪裏。看看下面這些

function loadData() {
  return callAPromise()
    .then(callback1)
    .then(callback2)
    .then(callback3)
    .then(() => {
      throw new Error("boom");
    })
}
loadData()
  .catch(function(e) {
    console.log(err);
// Error: boom at callAPromise.then.then.then.then (index.js:8:13)
});

與：

async function loadData() {
  await callAPromise1()
  await callAPromise2()
  await callAPromise3()
  await callAPromise4()
  await callAPromise5()
  throw new Error("boom");
}
loadData()
  .catch(function(e) {
    console.log(err);
    // output
    // Error: boom at loadData (index.js:7:9)
});

5. 調試

若是你使用過 Promise ，那麼你知道調試它們是一場噩夢。例如，若是在一個程序中設置了一個斷點，而後阻塞並使用調試快捷方式(如「中止」)，調試器將不會移動到下面，由於它只「逐步」執行同步代碼。使用async/wait，您能夠逐步完成wait調用，就像它們是正常的同步函數同樣。

編輯中可能存在的bug無法實時知道，過後爲了解決這些bug,花了大量的時間進行log 調試，這邊順便給你們推薦一個好用的BUG監控工具Fundebug。

原文：https://blog.sessionstack.com...

你的點贊是我持續分享好東西的動力，歡迎點贊！

一個笨笨的碼農，個人世界只能終身學習！

**更多內容請關注公衆號《大遷世界》！

關於Fundebug

Fundebug專一於JavaScript、微信小程序、微信小遊戲、支付寶小程序、React Native、Node.js和Java實時BUG監控。自從2016年雙十一正式上線，Fundebug累計處理了9億+錯誤事件，獲得了Google、360、金山軟件、百姓網等衆多知名用戶的承認。歡迎免費試用！