深入探討JavaScript的最基本部分之執(zhí)行上下文
在這篇文章中,我將深入探討JavaScript的最基本部分之一,即Execution Context(執(zhí)行上下文)。 在本文結束時,你應該對解釋器了解得更清楚:為什么在聲明它們之前可以使用某些函數或變量?以及它們的值是如何確定的?
什么是執(zhí)行上下文?
JavaScript的執(zhí)行環(huán)境非常重要,當JavaScript代碼在行時,會被預處理為以下情況之一:
- Global code - 首次執(zhí)行代碼的默認環(huán)境。
- Function code - 每當執(zhí)行流程進入函數體時。
- Eval code - 要在eval函數內執(zhí)行的文本。
你可以閱讀大量涉及作用域的在線資料,不過為了使事情更容易理解,讓我們將術語“執(zhí)行上下文”視為當前代碼的運行環(huán)境或作用域。接下來讓我們看一個包含global和function / local上下文的代碼示例。
這里沒有什么特別之處,我們有一個由紫色邊框表示的全局上下文,和由綠色,藍色和橙色邊框表示的3個不同的函數上下文。 只能有1個全局上下文,可以從程序中的任何其他上下文訪問。
你可以擁有任意數量的函數上下文,并且每個函數調用都會創(chuàng)建一個新的上下文,從而創(chuàng)建一個私有作用域,其中無法從當前函數作用域外直接訪問函數內部聲明的任何內容。 在上面的示例中,函數可以訪問在其當前上下文之外聲明的變量,但外部上下文無法訪問在其中聲明的變量或函數。 為什么會這樣呢? 這段代碼究竟是如何處理的?
Execution Context Stack(執(zhí)行上下文堆棧)
瀏覽器中的JavaScript解釋器被實現為單個線程。 實際上這意味著在瀏覽器中一次只能做一件事,其他動作或事件在所謂的執(zhí)行堆棧中排隊。 下圖是單線程堆棧的抽象視圖:
我們已經知道,當瀏覽器首次加載腳本時,它默認進入全局上下文執(zhí)行。 如果在全局代碼中調用函數,程序的順序流進入被調用的函數,創(chuàng)建新的執(zhí)行上下文并將其推送到執(zhí)行堆棧的頂部。
如果在當前函數中調用另一個函數,則會發(fā)生同樣的事情。 代碼的執(zhí)行流程進入內部函數,該函數創(chuàng)建一個新的執(zhí)行上下文,該上下文被推送到現有堆棧的頂部。 瀏覽器將始終執(zhí)行位于堆棧頂部的當前執(zhí)行上下文,并且一旦函數執(zhí)行完當前執(zhí)行上下文后,它將從棧頂部彈出,把控制權返回到當前棧中的下一個上下文。 下面的示例顯示了遞歸函數和程序的執(zhí)行堆棧:
(function foo(i) { if (i === 3) { return; } else { foo(++i); } }(0));
代碼簡單地調用自身3次,并將i的值遞增1。每次調用函數foo時,都會創(chuàng)建一個新的執(zhí)行上下文。 一旦上下文完成執(zhí)行,它就會彈出堆棧并且講控制返回到它下面的上下文,直到再次達到全局上下文。
關于執(zhí)行堆棧execution stack有5個關鍵要點:
- 單線程。
- 同步執(zhí)行。
- 一個全局上下文。
- 任意多個函數上下文。
- 每個函數調用都會創(chuàng)建一個新的執(zhí)行上下文execution context,甚至是對自身的調用。
執(zhí)行上下文的細節(jié)
所以我們現在知道每次調用一個函數時,都會創(chuàng)建一個新的執(zhí)行上下文。 但是,在JavaScript解釋器中,對執(zhí)行上下文的每次調用都有兩個階段:
創(chuàng)建階段 [調用函數時,但在執(zhí)行任何代碼之前]:
- 創(chuàng)建作用域鏈。
- 創(chuàng)建變量,函數和參數。
- 確定“this”的值。
激活/代碼執(zhí)行階段:
- 分配值,引用函數和解釋/執(zhí)行代碼。
可以將每個執(zhí)行上下文在概念上表示為具有3個屬性的對象:
executionContextObj = { 'scopeChain': { /* variableObject + 所有父執(zhí)行上下文的variableObject */ }, 'variableObject': { /* 函數實參/形參,內部變量和函數聲明 */ }, 'this': {} }
激活對象/變量對象 [AO/VO]
在調用該函數,并且在實際執(zhí)行函數之前,會創(chuàng)建這個executionContextObj。 這被稱為第1階段,即創(chuàng)造階段。 這時解釋器通過掃描函數傳遞的實參或形參、本地函數聲明和局部變量聲明來創(chuàng)建executionContextObj。 此掃描的結果將成為executionContextObj中的variableObject。
以下是解釋器如何預處理代碼的偽代碼概述:
1.找一些代碼來調用一個函數。
2.在執(zhí)行功能代碼之前,創(chuàng)建執(zhí)行上下文。
3.進入創(chuàng)建階段:
①初始化作用域鏈。
②創(chuàng)建variable object:
- 創(chuàng)建arguments object,檢查參數的上下文,初始化名稱和值并創(chuàng)建引用副本。
- 掃描上下文以獲取函數聲明:
- 對于找到的每個函數,在variable object中創(chuàng)建一個屬性,該屬性是函數的確切名稱,該屬性存在指向內存中函數的引用指針。
- 如果函數名已存在,則將覆蓋引用指針值。
- 掃描上下文以獲取變量聲明:
- 對于找到的每個變量聲明,在variable object中創(chuàng)建一個屬性作為變量名稱,并將該值初始化為undefined。
- 如果變量名稱已存在于variable object中,則不執(zhí)行任何操作并繼續(xù)掃描。
③確定上下文中“this”的值。
4.激活/執(zhí)行階段:
- 在上下文中運行/解釋函數代碼,并在代碼逐行執(zhí)行時分配變量值。
我們來看一個例子:
function foo(i) { var a = 'hello'; var b = function privateB() { }; function c() { } } foo(22);
在調用foo(22)時,創(chuàng)建階段如下所示:
fooExecutionContext = { scopeChain: { ... }, variableObject: { arguments: { 0: 22, length: 1 }, i: 22, c: pointer to function c() a: undefined, b: undefined }, this: { ... } }
如你所見,創(chuàng)建階段處理定義屬性的名稱,而不是為它們賦值,但正式的形參/實參除外。創(chuàng)建階段完成后,執(zhí)行流程進入函數,激活/代碼執(zhí)行階段在函數執(zhí)行完畢后如下所示:
fooExecutionContext = { scopeChain: { ... }, variableObject: { arguments: { 0: 22, length: 1 }, i: 22, c: pointer to function c() a: 'hello', b: pointer to function privateB() }, this: { ... } }
關于hoisting
你可以找到許多使用JavaScript定義術語hoisting的在線資源,解釋變量和函數聲明被hoisting到其函數范圍的頂部。 但是沒有人能夠詳細解釋為什么會發(fā)生這種情況,掌握了關于解釋器如何創(chuàng)建激活對象的新知識,很容易理解為什么。 請看下面的代碼示例:
(function() { console.log(typeof foo); // function pointer console.log(typeof bar); // undefined var foo = 'hello', bar = function() { return 'world'; }; function foo() { return 'hello'; } }());
我們現在可以回答的問題是:
為什么我們可以在聲明foo之前就能訪問?
- 如果我們理解了創(chuàng)建階段,就知道在激活/代碼執(zhí)行階段之前已經創(chuàng)建了變量。因此,當函數流開始執(zhí)行時,已經在激活對象中定義了foo。
Foo被聲明兩次,為什么foo顯示為function而不是undefined或string?
- 即使foo被聲明兩次,我們通過創(chuàng)建階段知道函數在變量之前就被創(chuàng)建在激活對象上了,而且如果激活對象上已經存在了屬性名稱,我們只是繞過了聲明這一步驟。
- 因此,首先在激活對象上創(chuàng)建對函數foo()的引用,并且當解釋器到達var foo時,我們已經看到屬性名稱foo存在,因此代碼不執(zhí)行任何操作并繼續(xù)處理。
為什么bar未定義?
- bar實際上是一個具有函數賦值的變量,我們知道變量是在創(chuàng)建階段被創(chuàng)建的,但它們是使用undefined值初始化的。
希望到這里你已經能夠很好地掌握了JavaScript解釋器如何預處理你的代碼。 理解執(zhí)行上下文和堆??梢宰屇懔私獗澈蟮脑颍簽槭裁创a預處理后的值和你預期的不一樣。
你認為學習解釋器的內部工作原理是多此一舉還是非常必要的呢? 了解執(zhí)行上下文階段是否能夠幫你你寫出更好的JavaScript呢?
總結
以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接