前言

我为什么写这个文章?也许换个耳熟能详的话题会有更多人看吧。之前发了个tls感觉阅读量不行。

要讲ecma语法吗?我觉得还是不了吧,毕竟这些繁琐,枯燥,而且门槛低。

那讲什么好?讲一点我自己觉得大家都知道,但是可能理解不到位都东西。

我自己理解到位吗?我想不一定很到位,但是一定很有思考价值。

这是一个系列?它可能是一个系列,就从执行上下文和运行开始吧。

js难不难?看你自己都目标吧,我觉得没有简单的东西,当你思考越多,就会看到更多东西,相对以前的理解就是难的。

那就开始吧

正文

js或者ecmascript?

大家用了那么久js,有没有搞清楚规范和实现的区别呢?ECMA这个组织定义了这个语言的规范,Javascript是这个规范的一个实现。这意味着,他可以有很多实现的可能,只是Javascript是其中一个最热门的实现。我们通常说的ecma规范,那指的是一种口头协议规范,通常我们说javascript语言,那指的是已经实现了ecma某个规范的一种语言。

在这个基础上,执行上下文就是ecma规范里面提到的一个抽象概念。这意味着,这东西不是一个具体已经实现出来的东西,他仅仅只是一个抽象模型,具体在计算机内部是怎么编译运行,以什么样的面向对象代码呈现,那应该是引擎(v8)实现的细节的内容。

那么执行上下文的意义在于,它可以给一个抽象模型,让我们更简单的预测js的运行机制。同时,执行上下文对后续理解js内存,垃圾回收,闭包等具有深刻意义,他可以帮助我们在不需要很了解基础底层情况下去分析内存,执行过程。

js代码是如何工作的?

为了不复杂化思路,我们可以暂时把js运行过程分成上图三个大步骤。

1. 获取js代码
2. 编译
3. 运行

编译阶段:js代码在编译阶段(序列化-->抽象语法树-->可执行代码)被编译成机器可识别大可执行代码

运行:运行代码

执行上下文(Execution Contexts)

执行上下文(Execution Contexts)是ECMA规范262第八章节中提出的抽象概念。这个概念定义了,js代码在运行时,所处的上下文环境。在简单的代码中,我们可以简单的理解上下文环境结构由:词法环境(Lexical Environments)和 变量环境(Variable Environment)两个部分。我们这里只需要关注这两部分:

词法环境: 词法环境定义了由代码编译过程中,ecma规范词法对应的一些关系,比如记录函数内部的this内容,不对外暴露,可以理解为ecma内部自己的语法关系。

变量环境:变量环境指的的是在词法环境中,代码运行时生成的变量关系,可以理解为由我们创建的变量。

另外,我们写的代码,包括函数里的代码执行,在规范中叫可执行代码。于是,我们可以把代码的运行流程,更细致的概括为,那么执行上下文和可以执行代码会伴随在js的运行周期里:

这我们在进一步的理解执行上下文,在js中,有三个比较场景会生成上下文对象:

1. 全局上下文
2. 函数上下文
3. eval上下文

所以,JS只有三种环境下会生成执行上下文,这意味着js不像c语言那样,具有单独块作用域的概念,只有函数作用域和全局作用域

执行上下文的生成时机

上面我们把代码的过程抽象成编译时和运行时。而执行上下文会在编译时就确定上下文关系,所以可以认为,在编译过程中,在解析js代码所对应的词法关系时候,编译器就已经确定了代码中每个环境对应的执行上下文的关系,只是说,这时候还没被激活。虽然这里还没提到作用域链,但是我们通常把这种在词法阶段确定的关系叫做静态。由于执行上下文中也会有作用域链,所以JS通常被称为词法作用域或者静态作用域。

这意味着,js在编译阶段其实已经做好了很多事情,当然也包括我们常说的变量提升。
让我们看下真实代码中如何体现:

运行过程和调用栈

既然加执行上下文,那它必然和执行时候密切相关。相信大部分人都知道,我们常说的会说的名词,函数调用栈。这个函数调用栈其实就是执行上下文的调用栈。我们上面提到,还有全局环境会生成全局上下文,eval环境会生成eval上下文。所以,这些上下文都会在激活时候进入调用栈。

比如,全局上下文,在编译完,代码开始运行时候就开始入栈,因为全局环境是最先开始运行的。

function a(){}
function b(){}
a()
b()

如图,对于全局环境来说,可执行代码如图。实际在运行时,内存里应该以机器码形式存在。当运行到a(),a函数到执行上下文会生成然后入栈。

从执行上下文中看变量提升

变量提升是一个我们经常关注的内容,我们通常把变量提升解释为,在js预编译阶段会对变量做一个提升,这里可以用一个简单对demo来重现这一经典现象:

console.log(val) // undifined
add(1, 2) // 3
function add(v1, v2) {
 return v1 + v2
}
var val = 1

可以看到,在变量声明前使用它,完全没有问题。对于经常使用js的人,这代码并没有任何稀奇。

但是,如果我们更深一层的去思考,变量提升的本质是什么。我们回想上面js的运行过程。从一段js代码,编译成可执行代码。我们把这个代码带到这个流程中去,我可以进一步把上面的代码抽象成这样:

入图所示,以上js脚本代码,通过词法解析,编译器会确认为该段代码具有两个不同的上下文环境,每一个环境中对应的内容我也标记出来了。比如全局上下文中,对应可执行代码是:

console.log(val)
add(1, 2)
var val = 1

其对应的环境变量是val和add函数指针,函数指针值得是其对应的是静态代码区域的可执行代码。实际上是函数上下文中对应的可执行代码。

那么在运行时候,全局上下文首先激活入栈,然后全局的脚本代码开始执行:

当执行到console.log时候,我们看到,虽然我们脚本代码中val在console.log后面,但是依然打出来了undifined,而不是报错。这是得力于词法环境到功劳。因为js在编译时候就帮我们生成对应到变量,只不过,其还没有对应到值而已。

然后当游标执行到add(1, 2)时,由于函数变量也已经生成,并且由于时函数声明形式。所以编译器时知道函数对应到可执行代码所处到指针,于是调用了函数,然后激活函数到上下文,并且入栈。其调用栈正如上文所示。即使函数在代码中是在执行代码到后面,但是得力于词法解析到功劳,add函数变量在编译时已经生成。

最后当执行到val = 1时候,函数先出栈,然后变量环境到val也会对应得到赋值。

这里需要说下,就是为了能够大家看懂,我用js的方式展示执行代码。但是实际上编译完成的执行代码应该是机器码。可以看到图中,变量环境中,两个变量val,和add分别是undefined和一个指向函数的一个引用。

到这里,我相信应该就很容易理解,为什么会存在变量提升这样的现象。本质上是因为js在编译过程中的词法解析阶段,就已经生成了执行上下文的关系,所以代码还没运行时候,变量的环境已经创建好了,而在代码运行时候。即使我们的执行代码是比变量更前的,依然可以拿到变量的引用,在代码运行时,上下文对象才会激活。

所以这一章节重点就是:上下文对象生成时机在词法解析阶段,而上下文对象激活时机在运行阶段

eval环境

Eval代码在运行时,上下文中会多一个调用所处环境多上下文引用。

变量提升的问题

变量提升可以认为是最初js设计上的一些不足,因为由上面的描述得知,这种从简的设计导致了变量提升。这种提升会在一些可能的块作用域中产生一些影响。比如while,for循环。对于那些曾经接触过c或者java这类语言的人来说,js这样简单的只有函数作用域块的特点会很难以理解。在for循环和while里面变量的提升,都会导致变量在全局情况下被覆盖,无法缓存的问题。

当然后面es6也有let和const的概念去解决块作用域的问题。但是本质上来说,变量提升不是一个很好的特性。

最后,可以通过上下文对象试着去想,闭包多本质是怎么样的,后续有时间在讨论。