共计 3761 个字符，预计需要花费 10 分钟才能阅读完成。
这是第 102 篇不掺水的原创，想获取更多原创好文，请搜寻公众号关注咱们吧~ 本文首发于政采云前端博客：v8 执行 js 的过程
前言
本文意在简略的介绍一下 V8 执行 JS 的过程，通过理解 V8 执行 JS 的过程，晓得 JS 代码出现在浏览器上到底做了什么。当然自己也是在陆续摸索 V8，文章中如有不当之处，还望不吝指正，感性交换。
家喻户晓，机器（CPU）只能辨认机器码（二进制码），对于 JS 代码，它是辨认不了的，所以当代码成为页面呈现在屏幕上的时候，必然是做了很多的转译工作。
V8 执行 Javascript 过程
如上图所示，咱们将一步步进行拆分剖析：
JS TO AST
在 V8 引擎拿到 JS 代码之后，解析器（Parser）会对其进行词法剖析和语法分析。
词法剖析
将 JS 代码拆分成对应的 Token，Token 是能拆分的最小单位，固定 type 表述类型 / 属性，value 示意对应的值，如下图 Token。
#### 语法分析
在进行词法剖析转为 Token 之后，解析器持续依据生成的 Token 生成对应的 AST，AST 置信前端同学并不生疏，也是热词之一，无论是在 Vue、React 中虚构 DOM 的示意，或者 Babel 对 JS 转译的示意都是先将其转化为对应的 AST，解析器解析之后的 AST 构造如下图所示：
能够看到，一段极小的代码片段，被解析成 AST 之后简单了很多，在图中的 AST 还仅仅是简化后的数据，全副的 AST 其实还有很多参数，将会更简单。
字节码
在解析器（Parser）将 JS 代码解析成 AST 之后，解释器（Ignition）依据 AST 来生成字节码（也称两头码）。前文提到 CPU 只能辨认机器码，对字节码是辨认不了的，这里就衍生出一个问题，如果 CPU 辨认不了字节码，那为什么还要在两头插一步来消耗资源转字节码呢？效率不是很更低吗？
在计算机学科里聊效率，都回避不了工夫和空间这两个概念，绝大部分的优化都是空间换工夫和工夫换空间，两者的均衡，效率如何达到最高，是一个很值得深入研究的问题。
拿之前版本的 V8 引擎执行 JS 来说，是没有转字节码这一步骤的，间接从 AST 转成机器码，这个过程称为编译过程，所以每次拿到 JS 文件的时候，首先都会编译，而这个过程还是比拟浪费时间的，这是一件比拟头疼的事件，须要一个解决办法。
一个网页第一次关上，敞开再次去关上，大部分状况下，还是和原来 JS 文件统一的，除非开发者批改了代码，但这个能够临时不思考，毕竟哪个网站也不会一天闲的无聊，不停的批改，上传替换。
缓存机器码
依照这个思路，既然绝大多数状况下，文件不会批改，那编译后的机器码能够思考缓存下来，这样一来，下次再关上或者刷新页面的时候就省去编译的过程了，能够间接执行了，存储机器码被分成了两种状况，一个是浏览器未敞开时候，间接存储到浏览器本地的内存中，一个是浏览器敞开了，间接存储在磁盘上，而晚期的 V8 也的确是这么做的，典型的就义空间换工夫。
缓存带来的问题
思考一个问题，从下面的图中能够看到，一个很小的代码片段，转换成 AST 之后，变大了很多，文件大了导致一个问题就是须要更大的内存来存储，而 JS 文件转成机器码（即二进制文件），会比原来的 JS 文件大几百甚至几千倍，这就象征这一个几十 KB 的 JS 文件将会达到几十 MB，这就很可怕，原本 Chrome 多过程架构就曾经很占用内存了，再来这一出，配置再好的电脑，也怕是无福消受 Chrome 了，毕竟使用者体验的好坏，间接决定了一个产品在市场上是否能生存上来，只管 V8 缓存了编译后的代码，缩小了编译的工夫，进步了工夫上的效率，但代价是内存占用太大了，所以 Chrome 团队是有必要优化这个问题的。
惰性编译
当然，引进其余技术是须要工夫去开发和优化的，在一个技术架构产生的同时，必然会有劣势方面的补救，而晚期版本的 V8 为了解决占用内存和启动速度，引进了 惰性编译 ，那么问题来了， 惰性编译 做了什么去提高效率的呢？
惰性编译 还是比拟容易了解的，从作用域的角度思考，ES6 之前之只有全局作用域和函数作用域，而 惰性编译 的思路就是 V8 启动的时候只编译和缓存全局作用域的代码，而函数作用域中的代码，会在调用的时候去编译，同样函数外部编译后的代码一样不会被缓存下来。
惰性编译存在的问题
引入 惰性编译 之后，在编译速度和缓存上看来，都失去了晋升，所有看起来仿佛很完满了，对，是看起来，然而设计进去的货色，你永远不晓得使用者会怎么应用，在 ES6 和 Vue、React 等这些没有遍及之前，绝大部分开发者都应用的是 jQuery，以及 RequireJS 等相似产品，JQ 插件各种援用，各种插件或者开发者本人封装的办法，为了不净化其余使用者的变量，个别都封装成一个函数，这样问题就来了，惰性编译 不会保留函数编译后的机器码和了解编译函数，如果一个插件太大那等到应用函数再去编译，编译的工夫上就会变得很慢，这相当于是开发者将 惰性编译 给玩完了，路给封死了。
引入字节码
好吧，玩不过开发者了，那 V8 团队只好换个思路，就引入字节码吧。首先要了解什么是字节码，字节码其实是机器码的形象，各种字节码的互相形成，能够实现 JS 所需的所有性能，当然首先一点，字节码比机器码占用的内存要小很多很多，根本是机器码所在内存的几十甚至几百分之一，这样一来字节码缓存下来所耗费的内存还是能够承受的。
这里会有一个疑难，既然 CPU 不能辨认字节码，那是不是还须要将字节码转成机器码呢？不然怎么执行，答案是必定。解释在将 AST 转为字节码之后，会在执行的时候将字节码转成机器码，这个执行过程必定是比间接执行机器码要慢的，所以在执行方面，速度上会比较慢，然而 JS 源码通过解析器转 AST，而后再通过解释器转字节码，这个过程是比编译器间接将 JS 源码转机器码要快很多的，全流程看来，整个工夫上是差不了多少的，然而却减小了大量的内存占用，何乐而不为。
编译器
热代码
在代码中，经常会有同一部分代码，被屡次调用，同一部分代码如果每次都须要解释器转二进制代码再去执行，效率上来说，会有些节约，所以在 V8 模块中会有专门的监控模块，来监控同一代码是否屡次被调用，如果被屡次调用，那么就会被标记为 热代码，这有什么作用呢？
优化编译器
TurboFan (优化编译器) 这个词置信关注手机界的同学并不生疏，华为、小米等这些品牌，在近几年产品发布会上都会呈现这个词，次要的能力是通过软件计算能力来优化一系列的性能，使得效率更优。
接着热代码持续说，当存在热代码的时候，V8 会借着 TurboFan 将为热代码的字节码转为机器码并缓存下来，这样一来，当再次调用热代码时，就不在须要将字节码转机器码，当然热代码相对来说还是少部分的，所以缓存也并不会占用太大内存，并且晋升了执行效率，同样此处也是就义空间换工夫。
反优化
JS 语言是动静语言，十分之灵便，对象的构造和属性在运行时是能够产生扭转的，构想一个问题，如果热代码在某次执行的时候，忽然其中的某个属性被批改了，那么编译成机器码的热代码还能继续执行吗？答案是必定不能。这个时候就要应用到优化编译器的 反优化 了，他会将热代码退回到 AST 这一步，这个时候解释器会从新解释执行被批改的代码，如果代码再次被标记为热代码，那么会反复执行优化编译器的这个步骤。
总结
从剖析的过程来看，V8 对 JS 执行的过程，不仅应用到了解释器，还用到了优化编译器。这种两者联合去解决的形式，业界称为 JIT (Just-In-Time)。应用这种联合的形式来解决 JS，次要是利用了 AST 造成的文件较小，而通过优化编译器编译后的热代码执行效率高，两者联合，各自施展各自的劣势，将效率尽量晋升到最大。
V8 所做的事件，远远不止这些，这里也仅仅是简略详情和剖析一下主流程上所做的一些事件，如果细化到每个点，还有很多概念，比方内联缓存、暗藏类、快属性、慢属性、创建对象，以及笔者之前写的垃圾回收等等，所做的事件切实太多，就不一一例举了。
开源作品
- 政采云前端小报
开源地址 www.zoo.team/openweekly/ (小报官网首页有微信交换群)
招贤纳士
政采云前端团队（ZooTeam），一个年老富裕激情和创造力的前端团队，隶属于政采云产品研发部，Base 在风景如画的杭州。团队现有 40 余个前端小伙伴，平均年龄 27 岁，近 3 成是全栈工程师，妥妥的青年风暴团。成员形成既有来自于阿里、网易的“老”兵，也有浙大、中科大、杭电等校的应届新人。团队在日常的业务对接之外，还在物料体系、工程平台、搭建平台、性能体验、云端利用、数据分析及可视化等方向进行技术摸索和实战，推动并落地了一系列的外部技术产品，继续摸索前端技术体系的新边界。
如果你想扭转始终被事折腾，心愿开始能折腾事；如果你想扭转始终被告诫须要多些想法，却无从破局；如果你想扭转你有能力去做成那个后果，却不须要你；如果你想扭转你想做成的事须要一个团队去撑持，但没你带人的地位；如果你想扭转既定的节奏，将会是“5 年工作工夫 3 年工作教训”；如果你想扭转原本悟性不错，但总是有那一层窗户纸的含糊… 如果你置信置信的力量，置信平凡人能成就不凡事，置信能遇到更好的本人。如果你心愿参加到随着业务腾飞的过程，亲手推动一个有着深刻的业务了解、欠缺的技术体系、技术发明价值、影响力外溢的前端团队的成长历程，我感觉咱们该聊聊。任何工夫，等着你写点什么，发给 ZooTeam@cai-inc.com
