为准确起见，我先声明下并非撰写或者阅读这篇文章的人是小白。但有时有的话题确实会让你一下子懵掉，成为小白。至少对我来说，JavaScript代码引擎是这样的:

为网页写代码看起来像魔法一样，当我们将字符按序列写下，浏览器就会相应地运行。而了解这个魔法背后的技术会让作为程序员的你更好地提高你的技艺，至少当你尝试要解释JavaScript网页和移动套件驱动下的程序时会稍微明朗些。

首先，先介绍一些术语

JavaScript通常被称为虚拟机。虚拟机是指在既定的计算机系统中运用软件模拟的具有完整硬件系统功能的计算机系统。根据虚拟机的模拟以及代替现实计算机的精确度，它们被分为了很多种类型。

举个例子，虚拟机系统就是要提供一个可以让操作系统执行的完全仿真的平台。苹果用户对Parallels就很熟悉，这是一个能让你在苹果电脑上运行Windows的虚拟机系统。

另一方面，流程虚拟机的功能性较低，只能运行一道程序或流程。Wine是一种可以让你在Linux计算机上运行Windows运用程序的流程虚拟机，但它并不能提供一套完整的Windows操作系统。

JavaScript引擎是一种为解释和执行JavaScript代码而专门设计的流程虚拟机。注解：将通过布局网页使浏览器运行的布局引擎和解释，执行代码的较低水平的JavaScript引擎作对比是相当重要的。以下是一些比较到位的阐述。

那么，JavaScript引擎到底是做什么的呢？

当一切就绪，JavaScript的基本工作就是将开发者写的JavaScript代码转换成能被浏览器理解甚至能在应用程序上运用的最优化的快捷代码。事实上，JavaScriptCore称自己是优化的虚拟机。

更确切地说，每一个 JavaScript 引擎都实现了ECMAScript的一种版本，而JavaScript 是它的一种方言叫法。JavaScript引擎会随着ECMAScript的发展而进步，因为如此多不同的引擎都要与不同的浏览器一起运作，如headless browser, 或者像Node.js这样的执行环境。

你可能对网页浏览器很熟悉，但什么是headless browser呢？这是一种没有形象的用户交界面的网页浏览器。它们擅长对你的网页产品进行机械化的测试。PhantomJS.就是很好的例子。那Node.js又是什么呢？

Node.js是一种允许你在服务器端运用JavaScript的异步事件驱动的框架。既然它们是由JavaScript驱动的工具，它们也就应当受JavaScript引擎的驱动。

通过以上对虚拟机的定义，将JavaScript引擎称为流程虚拟机也就是理所当然的了。因为它唯一的目的就是要读取和编译JavaScript代码。然而这并不意味着它只是一种简单的引擎。举个例子，JavaScriptCore有6个分区来分析、翻译、优化以及垃圾收集JavaScript代码。

这是如何运作的？

当然，这取决于引擎。WebKit的JavaScriptCore以及谷歌的V8引擎之所以能引起我们的兴趣是因为NativeScript对它们起了杠杠作用。这两种引擎不同程度地掌握着过程码。

JavaScriptCore是通过一系列的步骤去编译和优化脚本。

它会对词汇进行分析，将其分解成一系列的记号，或附上某些既定的意义。这些记号之后会被分析程序理出句法，并嵌入句法树。之后4个JIT（及时）程序开始运行、分析和执行那些分析程序产生的字节码。

嗯？简单讲，JavaScript引擎将你的源代码分解成串（又叫做分词），再将那些串转换成为编译器能够理解的字节码，然后将其执行。

用C++编写的谷歌的V8引擎也能编译和解释JavaScript源代码，掌握内存记忆配置且可垃圾回收残留物。

它由2个能够将源代码直接转换成计算机代码的编译器组成:Full-codegen：输出非优化代码的快速编译器。Crankshaft：输出快速，优化代码的慢速编译器。

如果Crankshaft认为由Full-codegen产生的不够优化的代码需要优化，它将会取而代之，这就是“crankshafting”流程。

有趣的事实：机轴是运用在自动化产业中内部氧化引擎里的一个完整的部分。这种众所周知的引擎在更高级的载体也就是V8中有所运用。

若计算机代码是由编译过程产生的，那么这个引擎就会在浏览器中显示出所有的ECMA标准规定的数据类型、操作员、客体和功能，或者任何需要用到它们的运行环境，如NativeScript.

JavaScript引擎有哪些呢？

市场上有许多令人晕眩的JavaScript引擎要去分析、理解和执行客户端的代码。随着每一种浏览器新版本的出现，JavaScript引擎有时会做出一些改变或优化来和JavaScript代码编译中的技术水平相契合。

为了避免被那些引擎的各种名字搞晕，请记住，有许多市场营销计划会研究到它们强调的引擎和浏览器。在这份实用的JavaScript编辑器的分析报告中，作者讽刺到：万一你不理解，你要明白在编译器中，差不多有37%是由市场因素组成的，品牌重塑是你在编辑器上可以做的不多的事情之一，因此引擎被赋予了迎合市场的名字：SquirrelFish, Nitro, SFX…

在市场因素对为引擎进行命名以及重命名有着重要影响的情况下，对JavaScript引擎发展史上的重大事件做记录是很有必要的。为此，我编辑了一份便捷的表格供大家使用：

JavaScriptCore被重写为SquirrelFish，也被重塑成SquirrelFishExtreme品牌，又叫做Nitro。然而，在WebKit安装启用下的JavaScript的确也被称为JavaScript引擎（如Safari）。

**iOS开发者应该认识到Mobile Safari包含Nitro，但UIWebView并不包括JIT编译器，所以这个过程会比较慢。然而，有了iOS8系统，开发者可以运用包含Nitro的WKWebView来大幅度加速这个运行速度。Hybrid App的开发者应该会觉得比较轻松。

之所以有做出将io.js从Node.js中分离出来的一个因素是和可以支持这个项目的V8版本有关。这将会是一个挑战，就像这边所列出来的一样。

为何我们应该关心？

JavaScript引擎代码的句法分析和编译过程的目的是要在最短的时间内产生最优化的代码。

因此，这些引擎的改进和我们对于改进网页和机动范围内使其更具有操作性能的追求是一致的。当你去追溯这些发展，你会发现列在arewefastyyet.com的图表上有许多各种各样的引擎的运用。

任何网页开发者都应该意识到，我们那么刻苦去研发、调试和维护的能够演绎代码的浏览器存在内在的差异。为何有的脚本在某个浏览器上运行的很慢，却在另外一个浏览器上运行顺畅？

同样地，移动开发者，尤其是使用 webview 来展示内容的混合移动应用开发者，或者那些使用像 NativeScript 这种运行时环境的开发者，会想知道是什么引擎在编译它们的JavaScript代码。移动网页的开发者应该对小型设备上各种各样的浏览器的内部限制性以及可能性要有所了解。作为 网页、移动或应用程序的开发人员，保持发展性，跟上 JavaScript 引擎的变化会让你受益匪浅。