René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"js没那么简单（1）-- 执行上下文","articleBody":"## 前言\r\n我为什么写这个文章？也许换个耳熟能详的话题会有更多人看吧。之前发了个tls感觉阅读量不行。\r\n\r\n要讲ecma语法吗？我觉得还是不了吧，毕竟这些繁琐，枯燥，而且门槛低。\r\n\r\n那讲什么好？讲一点我自己觉得大家都知道，但是可能理解不到位都东西。\r\n\r\n我自己理解到位吗？我想不一定很到位，但是一定很有思考价值。\r\n\r\n这是一个系列？它可能是一个系列，就从执行上下文和运行开始吧。\r\n\r\njs难不难？看你自己都目标吧，我觉得没有简单的东西，当你思考越多，就会看到更多东西，相对以前的理解就是难的。\r\n\r\n那就开始吧\r\n\r\n### 正文\r\n#### js或者ecmascript？\r\n大家用了那么久js，有没有搞清楚规范和实现的区别呢？ECMA这个组织定义了这个语言的规范，Javascript是这个规范的一个实现。这意味着，他可以有很多实现的可能，只是Javascript是其中一个最热门的实现。我们通常说的ecma规范，那指的是一种口头协议规范，通常我们说javascript语言，那指的是已经实现了ecma某个规范的一种语言。\r\n\r\n在这个基础上，**执行上下文**就是ecma规范里面提到的一个抽象概念。这意味着，这东西不是一个具体已经实现出来的东西，他仅仅只是一个抽象模型，具体在计算机内部是怎么编译运行，以什么样的面向对象代码呈现，那应该是引擎（v8）实现的细节的内容。\r\n\r\n那么**执行上下文**的意义在于，它可以给一个抽象模型，让我们更简单的预测js的运行机制。同时，执行上下文对后续理解js内存，垃圾回收，闭包等具有深刻意义，他可以帮助我们在不需要很了解基础底层情况下去分析内存，执行过程。\r\n\r\n#### js代码是如何工作的？\r\n![](https://user-gold-cdn.xitu.io/2020/7/23/1737b9b8972fda26?w=974\u0026h=170\u0026f=png\u0026s=23791)\r\n为了不复杂化思路，我们可以暂时把js运行过程分成上图三个大步骤。\r\n1. 获取js代码\r\n2. 编译\r\n3. 运行\r\n\r\n编译阶段：js代码在编译阶段（序列化--\u003e抽象语法树--\u003e可执行代码）被编译成机器可识别大可执行代码\r\n\r\n运行：运行代码\r\n\r\n#### 执行上下文（Execution Contexts）\r\n[执行上下文（Execution Contexts）](http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf)是ECMA规范262第八章节中提出的抽象概念。这个概念定义了，js代码在运行时，所处的上下文环境。在简单的代码中，我们可以简单的理解上下文环境结构由：**词法环境**（Lexical Environments）和 **变量环境**（Variable Environment）两个部分。我们这里只需要关注这两部分：\r\n![](https://user-gold-cdn.xitu.io/2020/7/24/1737ec1db136db10?w=620\u0026h=208\u0026f=png\u0026s=37775)\r\n词法环境： 词法环境定义了由代码编译过程中，ecma规范词法对应的一些关系，比如记录函数内部的this内容，不对外暴露，可以理解为ecma内部自己的语法关系。\r\n\r\n变量环境：变量环境指的的是在词法环境中，代码运行时生成的变量关系，可以理解为由我们创建的变量。\r\n\r\n另外，我们写的代码，包括函数里的代码执行，在规范中叫**可执行代码**。于是，我们可以把代码的运行流程，更细致的概括为，那么执行上下文和可以执行代码会伴随在js的运行周期里：\r\n\r\n![](https://user-gold-cdn.xitu.io/2020/7/24/1737edf78d8fa366?w=1736\u0026h=272\u0026f=png\u0026s=81180)\r\n\r\n这我们在进一步的理解执行上下文，在js中，有三个比较场景会生成上下文对象：\r\n1. 全局上下文\r\n2. 函数上下文\r\n3. eval上下文\r\n\r\n所以，JS只有三种环境下会生成执行上下文，这意味着js不像c语言那样，具有单独块作用域的概念，只有函数作用域和全局作用域\r\n\r\n#### 执行上下文的生成时机\r\n上面我们把代码的过程抽象成**编译时**和***运行时***。而执行上下文会在编译时就确定上下文关系，所以可以认为，在编译过程中，在解析js代码所对应的词法关系时候，编译器就已经确定了代码中每个环境对应的执行上下文的关系，只是说，这时候还没被激活。虽然这里还没提到作用域链，但是我们通常把这种在词法阶段确定的关系叫做**静态**。由于执行上下文中也会有作用域链，所以JS通常被称为词法作用域或者静态作用域。\r\n\r\n这意味着，js在编译阶段其实已经做好了很多事情，当然也包括我们常说的变量提升。\r\n让我们看下真实代码中如何体现：\r\n\r\n\r\n#### 运行过程和调用栈\r\n既然加执行上下文，那它必然和执行时候密切相关。相信大部分人都知道，我们常说的会说的名词，函数调用栈。这个函数调用栈其实就是执行上下文的调用栈。我们上面提到，还有全局环境会生成全局上下文，eval环境会生成eval上下文。所以，这些上下文都会在激活时候进入调用栈。\r\n\r\n比如，全局上下文，在编译完，代码开始运行时候就开始入栈，因为全局环境是最先开始运行的。\r\n\r\n```javascirpt\r\nfunction a(){}\r\nfunction b(){}\r\n\r\na()\r\nb()\r\n```\r\n![](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/81fe9f2fcd8e486f8116900ae434c325~tplv-k3u1fbpfcp-zoom-1.image)\r\n\r\n如图，对于全局环境来说，可执行代码如图。实际在运行时，内存里应该以机器码形式存在。当运行到a()，a函数到执行上下文会生成然后入栈。\r\n\r\n\r\n#### 从执行上下文中看变量提升\r\n变量提升是一个我们经常关注的内容，我们通常把变量提升解释为，在js预编译阶段会对变量做一个提升，这里可以用一个简单对demo来重现这一经典现象：\r\n```javascript\r\nconsole.log(val) // undifined\r\nadd(1, 2) // 3\r\nfunction add(v1, v2) {\r\n    return v1 + v2\r\n}\r\n\r\nvar val = 1\r\n```\r\n可以看到，在变量声明前使用它，完全没有问题。对于经常使用js的人，这代码并没有任何稀奇。\r\n\r\n但是，如果我们更深一层的去思考，变量提升的本质是什么。我们回想上面js的运行过程。从一段js代码，编译成可执行代码。我们把这个代码带到这个流程中去，我可以进一步把上面的代码抽象成这样：\r\n![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8b10ed9738644bf8a10b02049319b414~tplv-k3u1fbpfcp-zoom-1.image)\r\n\r\n入图所示，以上js脚本代码，通过词法解析，编译器会确认为该段代码具有两个不同的上下文环境，每一个环境中对应的内容我也标记出来了。比如全局上下文中，对应可执行代码是:\r\n```\r\nconsole.log(val)\r\nadd(1, 2)\r\nvar val = 1\r\n```\r\n其对应的环境变量是val和add函数指针，函数指针值得是其对应的是静态代码区域的可执行代码。实际上是函数上下文中对应的可执行代码。\r\n\r\n那么在运行时候，全局上下文首先激活入栈，然后全局的脚本代码开始执行:\r\n\r\n![](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/35132d9ff5564e63a647bffb61c71a1e~tplv-k3u1fbpfcp-zoom-1.image)\r\n\r\n当执行到console.log时候，我们看到，虽然我们脚本代码中val在console.log后面，但是依然打出来了undifined，而不是报错。这是得力于词法环境到功劳。因为js在编译时候就帮我们生成对应到变量，只不过，其还没有对应到值而已。\r\n\r\n![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3ea05ceed7554be8ba0f0ed61274b801~tplv-k3u1fbpfcp-zoom-1.image)\r\n\r\n然后当游标执行到add(1, 2)时，由于函数变量也已经生成，并且由于时函数声明形式。所以编译器时知道函数对应到可执行代码所处到指针，于是调用了函数，然后激活函数到上下文，并且入栈。其调用栈正如上文所示。即使函数在代码中是在执行代码到后面，但是得力于词法解析到功劳，add函数变量在编译时已经生成。\r\n\r\n![](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/068fd06150a84033ac2c9c0ae01631c9~tplv-k3u1fbpfcp-zoom-1.image)\r\n最后当执行到val = 1时候，函数先出栈，然后变量环境到val也会对应得到赋值。\r\n\r\n这里需要说下，就是为了能够大家看懂，我用js的方式展示执行代码。但是实际上编译完成的执行代码应该是机器码。可以看到图中，变量环境中，两个变量val，和add分别是undefined和一个指向函数的一个引用。\r\n\r\n到这里，我相信应该就很容易理解，为什么会存在变量提升这样的现象。本质上是因为js在编译过程中的词法解析阶段，就已经生成了执行上下文的关系，所以代码还没运行时候，变量的环境已经创建好了，而在代码运行时候。即使我们的执行代码是比变量更前的，依然可以拿到变量的引用，在代码运行时，上下文对象才会激活。\r\n\r\n所以这一章节重点就是：**上下文对象生成时机在词法解析阶段，而上下文对象激活时机在运行阶段**\r\n\r\n#### eval环境\r\nEval代码在运行时，上下文中会多一个调用所处环境多上下文引用。\r\n\r\n#### 变量提升的问题\r\n变量提升可以认为是最初js设计上的一些不足，因为由上面的描述得知，这种从简的设计导致了变量提升。这种提升会在一些可能的块作用域中产生一些影响。比如while，for循环。对于那些曾经接触过c或者java这类语言的人来说，js这样简单的只有函数作用域块的特点会很难以理解。在for循环和while里面变量的提升，都会导致变量在全局情况下被覆盖，无法缓存的问题。\r\n\r\n当然后面es6也有let和const的概念去解决块作用域的问题。但是本质上来说，变量提升不是一个很好的特性。\r\n\r\n最后，可以通过上下文对象试着去想，闭包多本质是怎么样的，后续有时间在讨论。\r\n\r\n\r\n\r\n\r\n\r\n\r\n","author":{"url":"https://github.com/wython","@type":"Person","name":"wython"},"datePublished":"2020-08-06T08:08:13.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/14/wython.github.io/issues/14"}