深入ECMAScript系列(二):执行上下文
栏目: JavaScript · 发布时间: 6年前
内容简介:执行上下文(Exexution Contexts):用来通过ECMAScript编译器来追踪代码运行时计算的一种规范策略。执行上下文简单理解就是代码执行时所在环境的抽象。执行上下文同时包含
执行上下文(Exexution Contexts):用来通过ECMAScript编译器来追踪代码运行时计算的一种规范策略。
执行上下文简单理解就是代码执行时所在环境的抽象。
执行上下文同时包含 变量环境组件(VariableEnvironment) 和 词法环境组件(LexicalEnvironment) ,这两个组件多数情况下都指向相同的 词法环境(Lexical Environment) ,那为什么还要存在两个环境组件呢?我们稍后将进行详细讨论。如果不太了解词法环境的可以看下我的上一篇文章 深入ECMAScript系列(一):词法环境 。
ExecutionContext = { VariableEnvironment: { ... }, LexicalEnvironment: { ... }, } 复制代码
二、执行上下文栈
执行上下文栈(Execution Context Stack):是一个后进先出的栈式结构(LIFO),用来跟踪维护执行上下文。 运行执行上下文(running execution context) 始终位于执行上下文栈的顶层。那么什么时候会创建新的执行上下文呢?
ECMAScript可执行代码有四种类型: 全局代码,函数代码,模块代码和 eval
。每当从当前执行代码运行至其他可执行代码时,会创建新的执行上下文,将其压入执行上下文栈并成为正在运行的执行上下文。当相关代码执行完毕返回后,将正在运行的执行上下文从执行上下文栈删除,之前的执行上下文又成为了正在运行的执行上下文。
我们通过一个动图来看一下执行上下文栈的工作过程
- 开始执行任何JavaScript代码前,会创建全局上下文并压入栈,所以全局上下文一直在栈底。
- 每次调用函数都会创建新的执行上下文(即便在函数内部调用自身),并压入栈。
- 函数执行完毕返回,其执行上下文出栈。
- 所有代码运行完毕,执行上下文栈只剩全局执行上下文。
三、执行上下文的创建、入栈及出栈
上面提到过ECMAScript可执行代码有四种类型: 全局代码,函数代码,模块代码和 eval
。
这里虽然说是 全局代码 ,但是JavaScript引擎其实是按照 script
标签来解析执行的,也就是说 script
标签按照它们出现的顺序解析执行,这也就是为什么我们平时要将项目依赖js库放在前面引入的原因。
JavaScript引擎是按可执行代码块来执行代码的,在任意的JavaScript可执行代码被执行时,执行步骤可按如下理解:
- 创建一个 新的执行上下文(Execution Context)
- 创建一个 新的词法环境(Lexical Environment)
- 设置该执行上下文的 变量环境组件(VariableEnvironment) 和 词法环境组件(LexicalEnvironment)
- 将该执行上下文 推入执行上下文栈 并成为 正在运行的执行上下文
- 对代码块内的 标识符进行实例化及初始化
- 运行代码
- 运行完毕后 执行上下文出栈
变量提升(Hoisting)及暂时性死区(temporal dead zone,TDZ)
我们平常所说的 变量提升 就发生在上述执行步骤的 第四步 ,对代码块内的 标识符进行实例化及初始化 的具体表现如下:
- 执行代码块内的
let
、const
和class
声明的标识符合集记录为lexNames
- 执行代码块内的
var
和function
声明的标识符合集记录为varNames
- 如果
lexNames
内的任何标识符在varNames
或lexNames
内出现过,则报错SyntaxError
这就是为什么可以用
var
或function
声明多个同名变量,但是不能用let
、const
和class
声明多个同名变量。 - 将
varNames
内的var
声明的标识符实例化并初始化赋值undefined
,如果有同名标识符则跳过这就是所谓的 变量提升 ,我们用
var
声明的变量,在声明位置之前访问并不会报错,而是返回undefined
- 将
lexNames
内的标识符实例化,但并不会进行初始化,在运行至其声明处代码时才会进行初始化,在初始化前访问都会报错。这就是我们所说的 暂时性死区 ,
let
、const
和class
声明的变量其实也提升了,只不过没有被初始化,初始化之前不可访问。 - 最后将
varNames
内的函数声明实例化并初始化赋值对应的函数体,如果有同名函数声明,则前面的都会忽略,只有最后一个声明的函数会被初始化赋值。函数声明会被直接赋值,所有我们在函数声明位置之前也可以调用函数。
四、为什么需要两个环境组件
首先明确这两个环境组件的作用, 变量环境组件(VariableEnvironment)
用于记录 var
声明的绑定, 词法环境组件(LexicalEnvironment)
用于记录其他声明的绑定(如 let
、 const
、 class
等)。
一般情况下一个 Exexution Contexts
内的 VariableEnvironment
和 LexicalEnvironment
指向同一个词法环境,之所以要区分两个组件,主要是为了 实现块级作用域的同时不影响 var
声明及函数声明 。
众所周知,ES6之前并没有 块级作用域 的概念,但是ES6及之后我们可以通过新增的 let
及 const
等命令来实现块级作用域,并且不影响 var
声明的变量和函数声明,那么这是怎么实现的呢?
- 首先在一个正在运行的执行上下文(
running Execution Context
)内,词法环境由VariableEnvironment
和LexicalEnvironment
构成,此执行上下文内的所有标识符的绑定都记录在两个组件的环境记录内。 - 当运行至块级代码时,会将
LexicalEnvironment
记录下来,我们将其记录为oldEnv
。 - 然后创建一个新的
LexicalEnvironment
(外部词法环境outer
指向oldEnv
),我们将其记录为newEnv
,并将newEnv
设置为running Execution Context
的LexicalEnvironment
。 - 然后块级代码内的
let
、const
等声明就会绑定在这个newEnv
上面,但是var
声明和函数声明还是绑定在原来的VariableEnvironment
上面。块级代码内的函数声明会被当做
var
声明,会被提升至外部环境,块级代码运行前其值为初始值undefined
console.log(foo) // 输出:undefined { function foo() {console.log('hello')} } console.log(foo) // 输出: ƒ foo() {console.log('hello')} 复制代码
- 块级代码运行完毕后,又将
oldEnv
还原为running Execution Context
的LexicalEnvironment
。
目前包括块级代码(在一对大括号内的代码)、 for
循环语句、 switch
语句、 TryCatch
语句中的 catch
从句以及 with
语句( with
语句创建的新环境为对象式环境,其他皆为声明式环境)都是这样来实现块级作用域的。
系列文章
准备将之前写的部分深入ECMAScript文章重写,加深自己理解,使内容更有干货,目录结构也更合理。
欢迎前往阅读系列文章,如果喜欢或者有所启发,欢迎 star,对作者也是一种鼓励。
菜鸟一枚,如果有疑问或者发现错误,可以在相应的 issues 进行提问或勘误,与大家共同进步。
以上所述就是小编给大家介绍的《深入ECMAScript系列(二):执行上下文》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
第二曲线:跨越“S型曲线”的二次增长
[英]查尔斯·汉迪(Charles Handy) / 苗青 / 机械工业出版社 / 2017-6 / 49.00
S型曲线是每个组织和企业在预测未来时一定会参考的工具,一切事物的发展都逃不开S型曲线(“第一曲线”)。 然而,从公司组织、企业治理、市场的变化,到个人职业发展、社会人际关系以及未来的教育与社会价值,多维度地探讨这个世界需要重新以不同的角度来思考问题,不能够总是停留在“第一曲线”的世界。 如果组织和企业能在第一曲线到达巅峰之前,找到带领企业二次腾飞的“第二曲线”,并且第二曲线必须在第一曲......一起来看看 《第二曲线:跨越“S型曲线”的二次增长》 这本书的介绍吧!