简单地说，JavaScript引擎是浏览器的组成部分之一。因为浏览器还要做很多别的事情，比如解析页面、渲染页面、Cookie管理、历史记录等等。那么，既然是组成部分，因此一般情况下JavaScript引擎都是浏览器开发商自行开发的。比如：IE9的Chakra、Firefox的TraceMonkey、Chrome的V8等等。

从而也看出，不同浏览器都采用了不同的JavaScript引擎。因此，我们只能说要深入了解哪个JavaScript引擎。

如果你做过可视化开发，不知道你是否遇到过这样一个棘手的问题：因为需要向页面中添加大量的图表或点线元素而导致页面卡顿、性能下降。一般来说你可能考虑一个方案，从 SVG 换到了 canvas，这或多或少可以解决你面临的痛点，但是背后的原因你到底了解多少？隐藏在浏览器背后的秘密到底有多少，内核和引擎我们又该了解到什么程度？换个方面来说，我们都知道 JavaScript 是单线程的，那么 HTML5 规范引入了一个叫 Web Worker 的标准是否意味着 JavaScript 真正跨入多线程编程的时代了呢？

因为要谈到 JavaScript 的实现，必须先了解它的宿主环境，我们就从宿主环境之一——浏览器开始说起吧。

浏览器的主要功能是向服务器发送请求，在自身窗口中展示我们所选择的网络资源。一个浏览器的主要组件可分为如下几个部分：

注意：和大多数浏览器不同，Chrome 浏览器的每个标签页都分别对应一个呈现引擎实例。每个标签页都是一个独立的进程。

作为一名前端工程师，我们会更注重呈现引擎和 JavaScript 解释器的部分，那么下面来详细解释下这两部分。

呈现引擎，又称渲染引擎，也被称为浏览器内核，在线程方面又称为 UI 线程，它是由各大浏览器厂商依照 W3C 标准自行研发的，常见的浏览器内核可以分这四种：Trident、Gecko、Blink、Webkit。

Trident： 俗称 IE 内核，也被叫做 MSHTML 引擎，目前在使用的浏览器有 IE11 -，以及各种国产多核浏览器中的 IE 兼容模块。另外微软的 Edge 浏览器不再使用 MSHTML 引擎，而是使用类全新的引擎 EdgeHTML。

Gecko： 俗称 Firefox 内核，Netscape6 开始采用的内核，后来的 Mozilla FireFox（火狐浏览器）也采用了该内核, Gecko 的特点是代码完全公开，因此，其可开发程度很高，全世界的程序员都可以为其编写代码，增加功能。因为这是个开源内核，因此受到许多人的青睐，Gecko 内核的浏览器也很多，这也是 Gecko 内核虽然年轻但市场占有率能够迅速提高的重要原因。

Presto： Presto 是挪威产浏览器 opera 的 “前任” 内核，最新的 opera 浏览器内核现为 Blink。

Webkit： Safari 内核，也是 Chrome 内核原型，主要是 Safari 浏览器在使用的内核，也是特性上表现较好的浏览器内核。也被大量使用在移动端浏览器上。

Blink： 由 Google 和 Opera Software 开发，在Chrome（28及往后版本）、Opera（15及往后版本）和Yandex浏览器中使用。Blink 其实是 Webkit 的一个分支，添加了一些优化的新特性，例如跨进程的 iframe，将 DOM 移入 JavaScript 中来提高 JavaScript 对 DOM 的访问速度等，目前较多的移动端应用内嵌的浏览器内核也渐渐开始采用 Blink。

由于移动互联网的普及，我们还可以单独说一说目前移动设备上浏览器常用的内核情况： iPhone 和 iPad 等苹果 iOS 平台主要是 WebKit，Android 4.4 之前的 Android 系统浏览器内核是 WebKit，Android4.4 系统浏览器切换到了Chromium，内核是 Webkit 的分支 Blink，Windows Phone 8 系统浏览器内核是 Trident。

呈现引擎最重要的作用就是“呈现”了，也就是在浏览器的屏幕上显示请求的内容。一开始它会从网络层获取请求文档的内容，内容的大小一般限制在 8000 个块以内。然后进行如下所示的基本流程：

呈现引擎将开始解析 HTML 文档，并将各标记逐个转化成“内容树”上的 DOM 节点。同时也会解析外部 CSS 文件以及样式元素中的样式数据。HTML 中这些带有视觉指令的样式信息将用于创建另一个树结构：呈现树。

呈现树包含多个带有视觉属性（如颜色和尺寸）的矩形。这些矩形的排列顺序就是它们将在屏幕上显示的顺序。

呈现树构建完毕之后，进入“布局”处理阶段，也就是为每个节点分配一个应出现在屏幕上的确切坐标。下一个阶段是绘制 - 呈现引擎会遍历呈现树，由用户界面后端层将每个节点绘制出来。

需要着重指出的是，这是一个渐进的过程。为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕之后，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。

在这里，需要注意的是不同呈现引擎在主流程中会稍有不同，例如 CSS 样式表的解析时机，Webkit 内核下，HTML 和 CSS 文件的解析是同步的，而 Geoko 内核下，CSS 文件需要等到 HTML 文件解析成内容 Sink 后才进行解析。除此外，一些描述术语也会略有不同，详细内容可以查看《浏览器的工作原理：新式网络浏览器幕后揭秘》进行了解。

什么是 JavaScript 解释器？简单地说，JavaScript 解释器就是能够“读懂” JavaScript 代码，并准确地给出代码运行结果的一段程序。

所以 JavaScript 解释器，又称为 JavaScript 解析引擎，又称为 JavaScript 引擎，也可以成为 JavaScript 内核，在线程方面又称为 JavaScript 引擎线程。比较有名的有 Chrome 的 V8 引擎（用 C/C++ 编写），除此外还有 IE9 的 Chakra、Firefox 的 TraceMonkey。它是基于事件驱动单线程执行的，JavaScript 引擎一直等待着任务队列中任务的到来，然后加以处理，浏览器无论什么时候都只有一个 JavaScript 线程在运行 JavaScript 程序。

学过编译原理的人都知道，对于静态语言来说（如Java、C++、C），处理上述这些事情的叫编译器（Compiler），相应地对于 JavaScript 这样的动态语言则叫解释器（Interpreter）。这两者的区别用一句话来概括就是：编译器是将源代码编译为另外一种代码（比如机器码，或者字节码），而解释器是直接解析并将代码运行结果输出。 比方说，firebug 的 console 就是一个 JavaScript 解释器。但我们无需过多在这些点上纠结。因为比如像 V8，它其实是为了提高 JavaScript 的运行性能，会在运行之前将 JavaScript 编译为本地的机器码然后再去执行，这样速度就快很多，相信大家对 JIT（Just In Time Compilation）一定不陌生吧。

JavaScript 解释器和我们平时讨论的 ECMAScript 有很大关系，标准的 JavaScript 解释器会根据 ECMAScript 标准去实现文档中对语言规定的方方面面，但由于这不是一个强制措施，所以也有不按照标准来实现的解释器，比如 IE6，这也是一直困扰前端开发的一个来由——兼容问题。