关于本文标题，我并不认为参与写或者读本文的人是白痴。但是有时某个话题会让你觉得自己就像个白痴一样，而 JavaScript 引擎就是这些话题之一，至少对于我来说是这样。

有时编写 Web 应用的代码会感觉充满魔力，因为我们只是写了一系列字符，就能在浏览器里看到效果了。但是理解魔法背后的技术，可以帮助你更好地提高编程技巧。至少当你试图解释在 JavaScript 驱动的 web 或移动应用的幕后发生了什么的时候，会觉得自己不那么白痴了。

很多年前，那是我还是个研究生讲师，向一个教授抱怨还没有掌握那些特别难懂的法语语法点，可以教给我的本科学生。我记得当时她说的话：“有时候，学习某个事物的唯一方式就是教授它。”

尝试向工程师解释 NativeScript 是如何通过 JavaScript 引擎在幕后工作、在运行时连接调用原生的 APIs——面对这样一件复杂的工作很容易在一片杂草中迷失方向。事实上，任何 JavaScript 开发者都应该对我们每天使用的这门技术基础的引擎感到好奇。现在我们一起来仔细分析下 JavaScript 引擎到底做了什么，为什么不同的平台使用不同引擎，多年来它们是如何发展的，以及作为开发者我们为什么要关注这些。

首先，一些专业术语

“JavaScript 引擎”通常被称作一种 虚拟机。“虚拟机”是指软件驱动的给定的计算机系统的模拟器。有很多类型的虚拟机，它们根据自己在多大程度上精确地模拟或代替真实的物理机器来分类。

例如，“系统虚拟机”提供了一个可以运行操作系统的完整仿真平台。Mac 用户很熟悉的 Parallels 就是一个允许你在 Mac 上运行 Windows系统虚拟机。

另一方面，“进程虚拟机”不具备全部的功能，能运行一个程序或者进程。Wine 是一个允许你在 Linux 机器上运行 Windows 应用的进程虚拟机，但是并不在 Linux 中提供完整的 Windows 操作系统。

JavaScript 虚拟机是一种进程虚拟机，专门设计来解释和执行的 JavaScript 代码。

注意：要区别在浏览器中排布页面布局的 布局引擎 和解释和执行代码的底层 JavaScript 引擎是非常重要的。在 这里 可以找到一个很好的阐释。

那么，确切来讲，到底什么是 JavaScript 引擎，它做了什么？

JavaScript 引擎的基本工作是把开发人员写的 JavaScript 代码转换成高效、优化的代码，这样就可以通过浏览器进行解释甚至嵌入到应用中。事实上，JavaScriptCore 自称为“优化虚拟机”。

更准确地讲，每个 JavaScript 引擎都实现了一个版本的 ECMAScript，JavaScript 是它的一个分支。随着 ECMAScript 的不断发展，JavaScript 引擎也不断改进。之所以有这么多不同的引擎，是因为它们每个都被设计运行在不同的 web 浏览器、headless 浏览器、或者像 Node.js 那样的运行时环境中。

你也许熟悉 web 浏览器，那什么是 headless 浏览器呢？它是一个没有图形用户界面的 web 浏览器。它们在对 web 产品进行自动化测试时十分有用。一个很棒的例子就是 PhantomJS。那 Node.js 又和 JavaScript 引擎有什么关系？Node.js 是一个异步的、事件驱动的框架，让你在服务器端可以使用 JavaScript。既然他们是驱动 JavaScript 的工具，所以它们也是由 JavaScript 引擎驱动。

按照上述关于虚拟机的定义，把 JavaScript 引擎称作进程虚拟机就很好理解了，因为它的唯一的目的就是读取和编译 JavaScript 代码。这并不意味着它只是个简单的引擎。比如，JavaScriptCore 就有六个“构建模块”可以分析、解释、优化、垃圾回收 JavaScript 代码。

它是如何工作的？

当然，这决定于引擎。吸引我们注意的两个主要的引擎都利用了 NativeScript ，它们分别是 WebKit 的 JavaScriptCore 和 Google 的 V8 引擎。这两个引擎使用不同的方式处理代码。

JavaScriptCore 执行 一系列步骤 来解释和优化脚本：

它进行词法分析，就是将源代码分解成一系列具有明确含义的符号或字符串。

然后用语法分析器分析这些符号，将其构建成语法树。

接着四个 JIT（Just-In-Time）进程开始参与进来，分析和执行解析器所生成的字节码。

什么？简单来说，JavaScript 引擎会加载你的源代码，把它分解成字符串（又叫做分词），再 把这些字符串转换 成编译器可以理解的字节码，然后执行这些字节码。

Google 的 V8 引擎 是用 C++ 编写的，它也能够编译并执行 JavaScript 源代码、处理内存分配和垃圾回收。它被设计成由两个编译器组成，可以把源码直接编译成机器码：

Full-codegen：输出未优化代码的快速编译器

Crankshaft: 输出执行效率高、优化过的代码的慢速编译器

如果 Crankshaft 确定需要优化的代码是由 Full-codegen 生成的未优化代码，它就会取代 Full-codegen，这个过程叫做“crankshafting”。

一旦编译过程中产生了机器代码，引擎就会向浏览器暴露所有的数据类型、操作符、对象、在 ECMA 标准中指定的函数、或任何运行时需要使用的东西，NativeScript 就是如此。

有哪些 JavaScript 引擎？

有一大堆令人眼花缭乱的 JavaScript 引擎可以用来解释、分析和执行你的客户端代码。每个浏览器版本发布时，它的 JavaScript 引擎都可能有所改变或优化以跟上 JavaScript 代码执行技术的状况的变化。

你还没被这些浏览器引擎的名字完全弄糊涂之前，请记住很多市场营销的元素被加入了这些引擎和以它们为基础的浏览器。这篇对 JavaScript 编译 十分有用的分析 中，作者讽刺地指出：“你所不知道的是，编译器大约有 37% 是由市场营销构成的，对编译器进行品牌重塑也是你能做的为数不多的事情之一，智慧的市场营销，故而有了一系列名字：SquirrelFish、Nitro、SFX……”。

在牢记营销对命名和重命名这些引擎的影响的同时，注意到几件在 JavaScript 引擎发展史上的重大事件是很有用的。我为你做了一个便于理解的图表：

Browser, Headless Browser, or Runtime JavaScript Engine

Mozilla	Spidermonkey
Chrome	V8
Safari	JavaScriptCore
IE and Edge	Chakra
PhantomJS	JavaScriptCore
HTMLUnit	Rhino
TrifleJS	V8
Node.js	V8
Io.js*	V8

*JavaScriptCore 被改写为 SquirrelFish，升级版本为 QuirrelFish Extreme，也叫做 Nitro。然而，构成 Webkit 实现基础的 JavaScript 引擎就是 JavaScriptCore（比如 Safari）。

**iOS 开发者应该要知道移动设备的 Safari 使用 Nitro，但是 UIWebView 不包括 JIT 编译，所以体验会慢一些。然而开发人员可以在 iOS8 中使用包含 Nitro 的 WKWebView，使用体验 明显 变快。混合移动应用程序的开发人员应该能松口气了。

*最终 io.js 从 Node.js 分离开的原因之一就是为了支持 V8 版本的引擎。这仍然是一个挑战，正如 这里 讲述的。

我们为什么要关注？

JavaScript 引擎的代码解析和执行过程的目标就是在最短时间内编译出最优化的代码。

最重要的是，这些引擎的演进与我们对发展 web 和 移动平台的不断探究息息相关，让它们尽可能具有高性能，是相辅相成的。为了追踪这种演进，你可以看到各种各样的引擎在基准图中是如何表现的，就好像 arewefastyet.com 总结的。例如，比较 Chrome 在搭载 V8 引擎与 non-Crankshafted 引擎时的表现就很有趣。

任何一个 web 开发者都要意识到，我们努力编写、调试和维护的代码在不同浏览器中执行效果必然有所差异。为什么某段代码在一个浏览器上工作得很慢，但在另一个上却快得多？

同样地，移动开发者，尤其是使用 webview 显示页面内容的混合移动应用开发者，或者那些使用像 NativeScript 这种运行时环境的开发者，想知道是什么引擎在解释执行他们的 JavaScript 代码。移动 web 开发者应该注意到那些小小设备上的浏览器所具备的各种局限性和可能性。作为一个想持续发展的 web、移动或应用程序开发人员，时刻关注 JavaScript 引擎的变化会带给你超值回报。

总结：

js 中的基本数据类型 undefined null boolean number string

js 中的一种复杂数据类型 object 它是所有对象的基础类型

js 和其他语言一样拥有9种基本的控制语句

js 中的函数无需指定返回值，实际上未指定返回值的函数返回的是undefined

js 中的参数可以随意的传递 注意arguments[] 数组 它可以帮助你

js 中的函数是不能重载的，但是你可以模仿。