关于前端:47-张图带你走进浏览器的世界

春风好媒妁，说动一树榴红。偶来雨多，茅屋又新破，且戴一笠，托故去访邻居家老叟。循着江岸梅林，一颗颗睡饱了的梅子，正是青里一抹红透，得着此刻无人，且摘它个两袖清风、一袋新酒。世间的功名不能裱壁，就向天地讨一笔闲钱糊口。正合计着老叟家的那只古瓮，怎么着，一匹快马驰过，溅得我一身泥泞，定睛一探，可不是城里那位篡了功名的新进？且拼春风一叹，还好，近日雨多。

浏览器的次要性能就是向服务器发出请求，在浏览器窗口中展现 HTML 文档、PDF、图片、视频等网络内容。这些网络资源的地位由用户应用 URI（对立资源标示符）来指定指定。

或者在大多数人眼中，浏览器是这样的：

一个展现前端，一个未知的中间层连贯着网络世界；甚至，网络世界也能够省略：一台显示器，一个神秘的幕后黑盒。

如果你是一个前端开发者，甚至每天浏览器陪伴你度过的时光比女朋友陪伴你的都要久，想想那每一个令人“不是那么期待”的晚上，每一个争分夺秒实现工作的傍晚，只有浏览器和编辑器始终是你忠诚的搭档。而 就连你始终离不开的 VS Code 编辑器，甚至也与浏览器有着莫大的渊源。

屏幕前的敌人，你相熟本人身边的那些人吗，相熟那些与你朝夕相伴的敌人吗？兴许相熟，兴许不，那么，你是否违心花些工夫来相熟一下这个在大量工夫里与你有着莫大交加的浏览器的内心世界呢？

明天，咱们就来一探到底，走进这个咱们与网络连接最严密的两头地带。全文行文构造大略如下：

兴许你晓得，第一款浏览器 —— WorldWideWeb，诞生于 1990 年。然而古代浏览器的雏形却孕育于 1980s 年代。

一位名叫蒂姆·伯纳斯 - 李的英国科学家在 1980 年代初期创立了一个名为 Inquire 的计算机程序，过后他在总部位于瑞士的欧洲核钻研组织（CERN，以其法文字母示意）工作。该打算旨在 使在 CERN 工作的许多不同集体更容易共享信息。

1990 年，第一款浏览器问世于 Tim Berners-Lee 在 CERN 工作期间。您可能想晓得 Web 浏览器到底是什么，简而言之，它是一个计算机程序，其目标是显示和检索数据。应用调配给存储在网络服务器上的每个数据集（网页）的 URL，它能够做到这一点。所以这意味着 当您在浏览器中输出内容时，您实际上是在输出地址 ，浏览器将应用该地址来获取您想要查看的信息。 浏览器的另一个要害性能是以易于了解的形式向您解释和出现计算机代码。

下图简略列举了截止 2020 年浏览器的倒退简史：

晚期比拟有名、有意义的浏览器次要包含 Erwise、ViolaWWW、Mosaic、Netscape Navigator：

1990 年浏览器诞生之后的故事，想必您曾经早有耳闻：

NCSA Mosaic，或简称 Mosaic，是互联网历史上 第一个获广泛应用和可能显示图片的网页浏览器。它由伊利诺伊大学厄巴纳 - 香槟分校的 NCSA 组织在 1993 年发表，并于 1997 年 1 月 7 日正式终止开发和反对，这款浏览器在过后大受欢迎。Mosaic 的呈现，算是点燃了前期互联网热潮的火种之一。起初 Netscape Navigator 浏览器的开发，聘用了许多原有的 Mosaic 浏览器工程师，然而没有采纳 Mosaic 网页浏览器的任何代码。而传承网景浏览器代码的后嗣为 Firefox 浏览器。
Marc Andreesen 与共事 Jim Clark 于 1994 年成立了一家公司，过后 Mosaic 还是最风行的浏览器，它们打算打造出一个比 Mosaic 更好的浏览器，占领市场，让他们变得富裕，并扭转历史。他们的第一个浏览器被称为 Mosaic Netscape 0.9，不久更名 Netscape。得益于 JavaScript（JavaScript 诞生于 1995 年，它是 Netscape 的 Brendan Eich 仅破费十天设计实现的。）和“partial-screen loading”（即便页面未齐全加载，用户也能够开始浏览页面上的详细信息，这一个新概念极大地丰盛了在线体验）等性能，它很快成为市场领导者，占据了浏览器市场上一半的份额，最疯狂的时候，网景浏览器的市场份额靠近百分之九十。

1995 年 8 月 9 日，网景公开募股，最后的价格是 14 美元一股，但起初阴差阳错，改为 28 美元一股发行，当天开盘时，网景的股票成了 75 美元一股，网景成为了过后世界上市值最高的互联网公司，Netscape 的 IPO 也助长了日益增长的网络泡沫。

Netscape 最后的胜利向那些在计算机和互联网畛域工作的人证实时代曾经永远扭转了，这让过后业内最弱小的参与者感到震惊，一家名为 Microsoft 的西雅图公司就是其中之一。计算机将通过浏览器运行，浏览器能够在任何机器上运行，从而使软件行业民主化并升高其相当大的进入壁垒，这导致许多人猜想 操作系统的时代曾经完结 。Netscape 对微软来说是一个挑战，微软在 1990 年代前期创立了本人的浏览器 Internet Explorer，过后的 IE 和当初一样，通常被视为劣质产品。因为 微软曾经建设了销售其专有操作系统 Windows 的帝国 ，因而将这种由 Netscape 等公司带头的倒退视为一种威逼。微软通过对其产品的大量投资，使其与 Netscape 一样好，胜利地迅速扭转了浏览器行业的场面。Windows 计算机在公布时曾经装置了 Internet Explorer（Microsoft 的浏览器），这使其可能在市场上占据一席之地并一直发展壮大，最终在浏览器畛域获得了胜利，这便是驰名的 第一次浏览器大战。

市场份额的疾速下滑导致 Netscape 被发售给了 AOL，2003 年 7 月，网景遣散，就在遣散的当天，Mozilla 基金会成立，2004 年基于 Mozilla 源码的 Firefox 首次登台，拉开了第二次浏览器大战的尾声。2008 年 Netscape 最终灭绝，当年的浏览器帝国正式退出了历史的舞台。

到 2003 年，微软的 Internet Explorer 管制了 92% 以上的市场，齐全扭转了 1995 年的场面。然而，尽管微软在不到十年的工夫里胜利地齐全接管了浏览器市场，但很快就会呈现其余竞争，再次重塑网络浏览器的历史。

微软在 1990 年代前期崛起并让 Netscape 等公司屈从之后，浏览器的历史仿佛曾经走到了止境。然而，正如最后公布后的状况一样，Internet Explorer 正在成为劣质产品。谷歌于 2008 年推出了其专有浏览器——Chrome。到 2012 年底，即推出仅四年后，谷歌 Chrome 浏览器凭借其易用性、跨平台性能、速度以及与标签和书签相干的非凡性能，取代 Internet Explorer 成为最受欢迎的浏览器。
在 2000 年代初期，可能是在微软将浏览器附加到其操作系统之后，Apple 公布了 Safari，一种专为 Mac 设计的浏览器，并成为目前市场上第二大浏览器。
Internet Explorer 的风行度在 2000 年代前期逐步缩小，次要是因为它变得迟缓和过期，而 Microsoft 发现自己当初仿佛曾经是在里面察看浏览器世界。该公司不想持续错过，于是着手解决这个问题，但发现一个关键问题是“Internet Explorer”这个名字曾经成为劣质浏览器的同义词。因而，为了尝试从新进入游戏，微软不得不重新命名，是以，Edge 变诞生了。Edge 是微软浏览器的最新版本，它受到了很多好评，但对于 Microsoft 来说，Edge 的呈现可能为时已晚。
IE 浏览器终成时代之泪，Microsoft Edge 成为 Windows 11 的默认浏览器。这是 Windows 零碎更新 20 年来，IE 的首次缺席，也是最初一次。早在 Win10 更新时微软就示意，将放弃更新 IE 转向开发新的浏览器 Microsoft Edge。现在是彻底要和桌面上的 IE 说再见了。—— IE 浏览器将从 Windows 11 中隐没，它也将在 2022 年安眠。

截止 2021 年 7 月初，浏览器市场份额如下所示。

浏览器应用趋势变动：

浏览器市场份额：

国内浏览器市场份额：

如果你对以上浏览器市场份额数据有趣味，能够通过以下链接进行查看：

国内浏览器市场份额
- 浏览器市场份额
寰球浏览器市场份额
- 寰球浏览器市场份额
- w3counter

三层计算机体系结构：底部是机器硬件，两头是操作系统，顶部是应用程序。

当你在电脑或手机上启动利用时，是 CPU 和 GPU 为利用供能。通常状况下利用是通过操作系统提供的机制在 CPU 和 GPU 上运行。

中央处理器（Central Processing Unit），或简称为 CPU。CPU 能够看作是计算机的大脑。一个 CPU 外围如图中的办公人员，能够逐个解决很多不同工作。它能够在解决从数学到艺术所有工作的同时还晓得如何响应客户要求。过来 CPU 大多是单芯片的。随着古代硬件倒退，你常常会有不止一个内核，为你的手机和笔记本电脑提供更多的计算能力。

4 个 CPU 外围作为办公人员，坐在办公桌前解决各自的工作：

图形处理器（Graphics Processing Unit，简称为 GPU）是计算机的另一部件。与 CPU 不同，GPU 善于同时解决跨内核的简略工作。顾名思义，它最后是为解决图形而开发的。这就是为什么在图形环境中“应用 GPU”或“GPU 反对”都与疾速渲染和顺滑交互无关。近年来随着 GPU 减速计算的遍及，仅靠 GPU 一己之力也使得越来越多的计算成为可能。

下图中，许多带特定扳手的 GPU 内核意味着它们只能解决无限工作。

过程能够被形容为是一个利用的执行程序。线程是位于过程外部并执行其过程程序的任意局部。

启动利用时会创立一个过程。程序兴许会创立一个或多个线程来帮忙它工作。操作系统为过程提供了一个能够应用的“一块”内存，所有应用程序状态都保留在该公有内存空间中。敞开应用程序时，相应的过程也会隐没，操作系统会开释内存（下图中，边界框为过程，线程作为形象鱼在过程中游动）。

过程能够申请操作系统启动另一个过程来执行不同的工作。此时，内存中的不同局部会分给新过程。如果两个过程须要对话，他们能够通过 过程间通信（IPC）来进行。许多利用都是这样设计的，所以如果一个工作过程失去响应，该过程就能够在不进行应用程序不同局部的其余过程运行的状况下重新启动。

对于如何 构建 web 浏览器并不存在标准规范，一个浏览器的构建办法可能与另一个大同小异。不同浏览器的过程 / 线程架构个别由下图几局部：

而当下“浏览器世界的王者”Chrome 架构如下图所示，渲染过程下显示了多个层，表明 Chrome 为每个标签页运行多个渲染过程。

上图中，顶部是浏览器过程，它与解决利用其它模块工作的过程进行协调。对于渲染过程来说，创立了多个渲染过程并调配给了每个标签页。Chrome 在可能的状况下会给每个标签页调配一个过程。而当初它试图给每个站点调配一个过程，包含 iframe。

浏览器过程：管制利用中的“Chrome”局部，包含地址栏，书签，回退与后退按钮，以及解决 web 浏览器中网络申请、文件拜访等不可见的特权局部；
渲染过程：管制标签页内网站展现；
插件过程：管制站点应用的任意插件，如 Flash；
GPU 过程：解决独立于其它过程的 GPU 工作。GPU 被分成不同过程，因为 GPU 解决来自多个不同利用的申请并绘制在雷同外表。

能够简略了解为不同过程对应浏览器 UI 的不同局部：

Chrome 更多的是把本人形象为一个操作系统，网页或扩大相当于一个个程序，你甚至能够发现，Chrome 的确自带了一个工作管理器，在工作管理器面板会列出以后正在运行的过程以及它们以后的 CPU/ 内存使用量状况等信息。

个别你能够通过两种办法关上 Chrome 工作管理器：

通过在浏览器顶栏（标签 tab 栏）右侧右键，抉择工作管理器查看；
点击 Chrome 浏览器右上角的“选项”菜单（个别是三个点的标识），抉择“更多工具”子菜单，点击“工作管理器”，关上工作管理器窗口。

前文中提到了 Chrome 应用多个渲染过程，那他有什么劣势呢？

稳定性：最简略的状况下，你能够设想每个标签页都有本人的渲染过程。假如你关上了三个标签页，每个标签页都领有本人独立的渲染过程。如果某个标签页失去响应，你能够关掉这个标签页，此时其它标签页仍然运行着，能够失常应用。如果所有标签页都运行在同一过程上，那么当某个失去响应，所有标签页都会失去响应，显然这样的体验会很蹩脚。上面是多 / 单过程架构的比照动图，供你参考。

安全性与沙箱化：把浏览器工作分成多个过程的另一益处是安全性与沙箱化。因为操作系统提供了限度过程权限的办法，浏览器就能够用沙箱爱护某些特定性能的过程。例如，Chrome 浏览器能够限度解决用户输出（如渲染器）的过程的文件拜访的权限。

因为过程有本人的公有内存空间，所以它们通常蕴含公共基础设施的拷贝 (如 Chrome V8 引擎)。这意味着应用了更多的内存，如果它们是同一过程中的线程，就无奈共享这些拷贝（同一个过程中的线程不共享堆栈，堆栈是保障线程独立运行所必须的）。为了节俭内存，Chrome 对可启动的过程数量有所限度。具体限度数值依设施可提供的内存与 CPU 能力而定，然而 当 Chrome 运行时达到限度时，会开始在同一站点的不同标签页上运行同一过程。

Chrome 正在经验架构改革，它转变为将浏览器程序的每一模块作为一个服务来运行，从而能够轻松实现过程的拆解或聚合。具体表现是，当 Chrome 运行在 强力硬件 上时，它会将每个服务合成到不同过程中，从而 晋升稳定性 ，然而如果 Chrome 运行在资源无限的设施上时，它会将服务聚合到一个过程中从而 节俭了内存占用。在这一架构改革实现前，相似的整合过程以缩小内存应用的办法曾经在 Android 类平台上应用。

Chrome 67 版本后，桌面版 Chrome 都默认开启了 站点隔离 ，每个标签页的 iframe 都有一个独自的渲染过程。启用站点隔离是多年来工程人员致力的后果。站点隔离并不只是调配不同的渲染过程这么简略。它从根本上扭转了 iframe 的通信形式。在一个页面上关上开发者工具，让 iframe 在不同的过程上运行，这意味着开发者工具必须在幕后工作，以使它看起来无缝。即便运行一个简略的 Ctrl + F 来查找页面中的一个单词，也意味着在不同的渲染器过程中进行搜寻。你能够看到为什么 浏览器工程师把公布站点隔离性能作为一个重要里程碑！

延长浏览：Chrome 为什么多过程而不是多线程？

如果您是一名前端工程师，那么，面试时你大概率会被问到过：从 URL 输出到页面展示到底产生了什么？，如果您对这一过程不太熟悉，倡议看看上面两篇文章，在此不过多赘述：

经典面试题：从 URL 输出到页面展示到底产生什么？
在浏览器输出 URL 回车之后产生了什么（超具体版）

浏览器的次要工作之一就是渲染展现页面，不同的浏览器内核，渲染过程也不完全相同，但大抵流程都差不多，上面这张图片是火狐浏览器（Firefox，能够认为是 Netscapede 的涅槃新生）开发文档中的一张图片。

下面这张图片大体揭示了浏览器的渲染展现流程，然而从浏览器的整体架构上来说，下面的图片展现的兴许只是浏览器体系中的冰山一角。

通常意义下，浏览器架构是如下图这样的：

包含地址栏、后退 / 后退按钮、书签菜单等。除了浏览器主窗口显示的您申请的页面外，其余显示的各个局部都属于用户界面。

用户界面和渲染引擎的桥梁，在用户界面和渲染引擎之间传送指令。浏览器引擎提供了开始加载 URL 资源和一些其余高级操作方法，比方：从新加载、后退、后退动作，错误信息、加载进度等。

负责显示申请的内容。如果申请的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。

所谓浏览器内核就是指浏览器最重要或者说外围的局部 ”Rendering Engine”，译为 ” 渲染引擎 ”。负责对网页语法的解析，比方 HTML、JavaScript，并渲染到网页上。所以浏览器内核也就是浏览器所采纳的渲染引擎，渲染引擎决定这浏览器如何显示页面的内容和页面的格局信息。不同的浏览器内核对语法的解释也不雷同，因而同一网页在不同内核的浏览器显示的成果也会有差别（浏览器兼容）。这也就是网页开发者在不须要同内核的浏览器中测试网页显示成果的起因。

延长浏览：曾红极一时的红芯浏览器，官网对其介绍是：领有智能的认证引擎、渲染引擎、管控引擎，而且还有弱小的“国密通信协定”，反对对立管控、近程管制。2018 年 8 月 15 日，红芯浏览器被爆出关上装置目录后呈现大量和谷歌 Chrome 浏览器统一的同名文件，其安装程序的文件属性中也显示了原始文件名 chrome.exe，红芯浏览器的官网已撤下了浏览器的下载链接。8 月 16 日，红芯联结创始人高婧回应，红芯浏览器“蕴含‘Chrome’在外面”，但并非剽窃，而是“站在伟人的肩膀下来做翻新”。

言归正传，浏览器内核次要包含以下三个技术分支：排版渲染引擎、JavaScript 引擎，以及其余。

排版引擎：

KHTML：KHTML，是 HTML 网页排版引擎之一，由 KDE 所开发。KHTML 领有速度快捷的长处，但对谬误语法的容忍度则比 Mozilla 产品所应用的 Gecko 引擎小。苹果电脑于 2002 年驳回了 KHTML，作为开发 Safari 浏览器之用，并公布所批改的最新及过来版本源代码。起初发表的开源 WebCore 及 WebKit 引擎，它们均是 KHTML 的衍生产品。
WebCore：WebCore 是 苹果公司 开发的排版引擎，它是在另外一个排版引擎“KHTML”的根底上而来的。应用 WebCore 的次要有 Safari 浏览器。

浏览器的内核引擎，基本上是四分天下：

Trident: IE 以 Trident 作为内核引擎;
Gecko: Firefox 是基于 Gecko 开发;
WebKit: 诞生于 1998 年，并于 2005 年由 Apple 公司开源，Safari, Google Chrome, 傲游 3, 猎豹浏览器, 百度浏览器 opera 浏览器基于 Webkit 开发。
Presto: Opera 的内核，但因为市场抉择问题，次要利用在手机平台 –Opera mini。（2013 年 2 月 Opera 发表转向 WebKit 引擎，2013 年 4 月 Opera 发表放弃 WEBKIT，追随 GOOGLE 的新开发的 blink 引擎。）

须要略作补充的是，咱们常常还会听到 Chromium、Webkit2、Blink 这些引擎。

Chromium：基于 webkit，08 年开始作为 Chrome 的引擎，Chromium 浏览器是 Chrome 的试验版，试验新个性。能够简略地了解为：Chromium 为试验版，具备泛滥新个性；Chrome 为稳定版。

图片起源：万字详文：深刻了解浏览器原理

Webkit2：2010 年随 OS X Lion 一起面世。WebCore 层面实现过程隔离与 Google 的沙箱设计存在抵触。
Blink：基于 Webkit2 分支，是 WebKit 中 WebCore 组件的一个分支，13 年谷歌开始作为 Chrome 28 的引擎集成在 Chromium 浏览器里。Android 的 WebView 同样基于 Webkit2，是当初对新个性反对度最好的内核。Opera（15 及往后版本）和 Yandex 浏览器中也在应用。
挪动端基本上全副是 Webkit 或 Blink 内核（除去 Android 上腾讯家的 X5），这两个内核对新个性的反对度较高，所以新个性能够在挪动端大展身手。

各内核关系图：

上面咱们以 WebKit 为列，进行简略介绍，以便让你对渲染引擎有一个更多的了解。WebKit 由多个重要模块组成，通过下图咱们能够对 WebKit 有个整体的理解：

WebKit 就是一个 页面渲染以及逻辑解决引擎，前端工程师把 HTML、JavaScript、CSS 这“三驾马车”作为输出，通过 WebKit 的解决，就输入成了咱们能看到以及操作的 Web 页面。从上图咱们能够看进去，WebKit 由图中框住的四个局部组成。而其中最次要的就是 WebCore 和 JSCore（或者是其它 JS 引擎）。除此之外，WebKit Embedding API 是负责浏览器 UI 与 WebKit 进行交互的局部，而 WebKit Ports 则是让 Webkit 更加不便的移植到各个操作系统、平台上，提供的一些调用 Native Library 的接口，比方在渲染层面，在 iOS 零碎中，Safari 是交给 CoreGraphics 解决，而在 Android 零碎中，Webkit 则是交给 Skia。

WebKit 的渲染流程：

首先浏览器通过 URL 定位到了一堆由 HTML、CSS、JS 组成的资源文件，通过加载器把资源文件给 WebCore。之后 HTML Parser 会把 HTML 解析成 DOM 树，CSS Parser 会把 CSS 解析成 CSSOM 树。最初把这两棵树合并，生成最终须要的渲染树，再通过布局，与具体 WebKit Ports 的渲染接口，把渲染树渲染输入到屏幕上，成为了最终出现在用户背后的 Web 页面。

用于网络调用，比方 HTTP 申请。其接口与平台无关，并为所有平台提供底层实现，负责网络通信和平安。

用于解析和执行 JavaScript 代码，执行后果将传递给渲染引擎来展现。

用于绘制根本的窗口小部件，比方组合框和窗口。其公开了与平台无关的通用接口，而在底层应用操作系统的用户界面办法。

这是长久层，浏览器须要在硬盘上保留各种数据，例如 Cookie。新的 HTML 标准 (HTML5) 定义了“网络数据库”，这是一个残缺而轻便的浏览器内数据库。

上面列出了局部浏览器的架构图，兴许有些架构曾经扭转，有趣味能够简略参考看看，除了 IE 之外，大体上各浏览器的整体架构都是相似的。

Mosaic 架构：

Firefox 架构：

Chrome 架构：

Safari 架构：

IE 架构：

V8 一词最早见于“V-8 engine”，即 V8 发动机，个别应用在中高端车辆上。8 个气缸分成两组，每组 4 个，成 V 型排列。是高层次汽车静止中最常见的发动机构造，尤其在美国，IRL，ChampCar 和 NASCAR 都要求应用 V8 发动机。

对于 Chrome V8，笔者曾有一篇笔记做了比拟具体的介绍，全文脉络如下，感兴趣能够参考浏览。

V8 是依靠 Chrome 倒退起来的，前面确不局限于浏览器内核。倒退至今 V8 利用于很多场景，例如风行的 nodejs，weex，快利用，晚期的 RN。V8 曾经验过一次比拟大的架构调整，次要变动在于“从字节码的放弃到真香”。

V8 引擎诞生的使命就是要在速度和内存回收上进行反动。JavaScriptCore 的架构是采纳生成字节码的形式，而后执行字节码。Google 感觉 JavaScriptCore 这套架构不行，生成字节码会浪费时间，不如间接生成机器码快。所以 V8 在后期的架构设计上是十分激进的，采纳了间接编译成机器码的形式。前期的实践证明 Google 的这套架构速度是有改善，然而同时也造成了 内存耗费问题。

晚期的 V8 有 Full-Codegen 和 Crankshaft 两个编译器。V8 首先用 Full-Codegen 把所有的代码都编译一次，生成对应的机器码。JS 在执行的过程中，V8 内置的 Profiler 筛选出热点函数并且记录参数的反馈类型，而后交给 Crankshaft 来进行优化。所以 Full-Codegen 实质上是生成的是未优化的机器码，而 Crankshaft 生成的是优化过的机器码。

随着网页的复杂化，V8 也慢慢的暴露出了本人架构上的缺点：

Full-Codegen 编译间接生成机器码，导致 内存占用大；
Full-Codegen 编译间接生成机器码，导致 编译工夫长 ，导致 启动速度慢；
Crankshaft 无奈优化 try，catch 和 finally 等关键字划分的代码块；
Crankshaft 新加语法反对，须要为此编写适配不同的 Cpu 架构代码。

为了解决上述毛病，V8 借鉴 JavaScriptCore 的架构，生成字节码。V8 采纳生成字节码的形式后，整体流程如下图：

当初的 V8 是一个非常复杂的我的项目，有超过 100 万行 C++ 代码。它由许多子模块形成，其中这 4 个模块是最重要的：

Parser：负责将 JavaScript 源码转换为 Abstract Syntax Tree (AST)

确切的说，在“Parser”将 JavaScript 源码转换为 AST 前，还有一个叫”Scanner“的过程，具体流程如下：
Ignition：interpreter，即解释器，负责将 AST 转换为 Bytecode，解释执行 Bytecode；同时收集 TurboFan 优化编译所需的信息，比方函数参数的类型；解释器执行时次要有四个模块，内存中的字节码、寄存器、栈、堆。Ignition 的原始动机是缩小挪动设施上的内存耗费。在 Ignition 之前，V8 的 Full-codegen 基线编译器生成的代码通常占据 Chrome 整体 JavaScript 堆的近三分之一。这为 Web 应用程序的理论数据留下了更少的空间。Ignition 的字节码能够间接用 TurboFan 生成优化的机器代码，而不用像 Crankshaft 那样从源代码从新编译。Ignition 的字节码在 V8 中提供了更清晰且更不容易出错的基线执行模型，简化了去优化机制，这是 V8 自适应优化的要害个性。最初，因为生成字节码比生成 Full-codegen 的基线编译代码更快，因而激活 Ignition 通常会改善脚本启动工夫，从而改善网页加载。
TurboFan：compiler，即优化编译器，利用 Ignition 所收集的类型信息，将 Bytecode 转换为优化的汇编代码；TurboFan 我的项目最后于 2013 年底启动，旨在解决 Crankshaft 的毛病。Crankshaft 只能优化 JavaScript 语言的子集。例如，它不是设计用于应用结构化异样解决优化 JavaScript 代码，即由 JavaScript 的 try，catch 和 finally 关键字划分的代码块。很难在 Crankshaft 中增加对新语言性能的反对，因为这些性能简直总是须要为九个反对的平台编写特定于体系结构的代码。
Orinoco：garbage collector，垃圾回收模块，负责将程序不再须要的内存空间回收。

采纳新的 Ignition+TurboFan 架构后，比 Full-codegen+Crankshaft 架构内存升高一半多，且 70% 左右的网页速度失去了晋升。

在运行 C、C++ 以及 Java 等程序之前，须要进行编译，不能间接执行源码；但对于 JavaScript 来说，咱们能够间接执行源码 (比方：node test.js)，它是在运行的时候先编译再执行，这种形式被称为 即时编译(Just-in-time compilation)，简称为 JIT。因而，V8 也属于 JIT 编译器。

V8 未诞生之前，晚期支流的 JavaScript 引擎是 JavaScriptCore 引擎。JavaScriptCore（以下简称 JSCore）次要服务于 Webkit 浏览器内核，他们都是由苹果公司开发并开源进去。JSCore 是 WebKit 默认内嵌的 JS 引擎，之所以说是默认内嵌，是因为很多基于 WebKit 分支开发的浏览器引擎都开发了自家的 JS 引擎，其中最闻名的就是前文提到的 Chrome 的 V8。这些JS 引擎的使命都是解释执行 JS 脚本。而在渲染流程上，JS 和 DOM 树之间存在着相互关联，这是因为浏览器中的 JS 脚本最次要的性能就是操作 DOM 树，并与之交互。咱们能够通过下图看下它的工作流程:

JavaScriptCore 次要模块：Lexer 词法分析器，将脚本源码分解成一系列的 Token；Parser 语法分析器，解决 Token 并生成相应的语法树；LLInt 低级解释器，执行 Parser 生成的二进制代码；Baseline JIT 基线 JIT（just in time 实时编译）；DFG 低提早优化的 JIT；FTL 高通量优化的 JIT。

能够看到，相比动态编译语言生成语法树之后，还须要进行链接，装载生成可执行文件等操作，解释型语言在流程上要简化很多。这张流程图左边画框的局部就是 JSCore 的组成部分：Lexer（词法剖析）、Parser（语法分析）、LLInt 以及 JIT（解释执行）的局部（之所以 JIT 的局部是用橙色标注，是因为并不是所有的 JSCore 中都有 JIT 局部）。

词法剖析 很好了解，就是 把一段咱们写的源代码分解成 Token 序列的过程 ，这一过程也叫分词。在 JSCore，词法剖析是由 Lexer 来实现（有的编译器或者解释器把分词叫做 Scanner，比方 Chrome v8）。
跟人类语言一样，咱们讲话的时候其实是依照约定俗成，交换习惯依照肯定的语法讲出一个又一个词语。那类比到计算机语言，计算机要了解一门计算机语言，也要了解一个语句的语法。Parser 会把 Lexer 剖析之后生成的 token 序列进行语法分析，并生成对应的一棵形象语法树 (AST)。之后，ByteCodeGenerator 会依据 AST 来生成 JSCore 的字节码，实现整个 语法解析 步骤。
JS 源代码通过了词法剖析和语法分析这两个步骤，转成了字节码，其实就是通过任何一门程序语言必经的步骤–编译。然而不同于咱们编译运行 OC 代码，JS 编译完结之后，并不会生成寄存在内存或者硬盘之中的指标代码或可执行文件。生成的指令字节码，会被立刻被 JSCore 这台虚拟机进行逐行 解释执行。运行指令字节码（ByteCode）是 JS 引擎中很外围的局部，各家 JS 引擎的优化也次要集中于此。

PS：严格的讲，语言自身并不存在编译型或者是解释型，因为语言只是一些形象的定义与束缚，并不要求具体的实现，执行形式。这里讲 JS 是一门“解释型语言”只是 JS 个别是被 JS 引擎动静解释执行，而并不是语言自身的属性。

如果对 JavaScriptCore 有更多趣味，对于 JavaScriptCore 的更多细节，倡议延长浏览以下几篇博文：

深刻了解 JSCore
深刻分析 JavaScriptCore
JavaScriptCore 全面解析
深入浅出 JavaScriptCore

这一小结，还是以 Chrome V8 为例，简略论述浏览器与 JavaScript 的关系。

在 V8 呈现之前，所有的 JavaScript 虚拟机所采纳的都是解释执行的形式，这是 JavaScript 执行速度过慢的一个次要起因 。而 V8 率先引入了 即时编译（JIT）的 双轮驱动 的设计（混合应用编译器和解释器的技术），这是一种衡量策略，混合编译执行和解释执行这两种伎俩，给 JavaScript 的执行速度带来了极大的晋升。V8 呈现之后，各大厂商也都在本人的 JavaScript 虚拟机中引入了 JIT 机制，所以目前市面上 JavaScript 虚拟机都有着相似的架构。另外，V8 也是早于其余虚拟机引入了惰性编译、内联缓存、暗藏类等机制，进一步优化了 JavaScript 代码的编译执行效率。

V8 执行一段 JavaScript 的流程如下图所示：

联合上文介绍的 Chrome V8 架构，聚焦到 JavaScript 上，浏览器拿到 JavaScript 源码，Parser，Ignition 以及 TurboFan 能够将 JS 源码编译为汇编代码，其流程图如下：

简略地说，Parser 将 JS 源码转换为 AST，而后 Ignition 将 AST 转换为 Bytecode，最初 TurboFan 将 Bytecode 转换为通过优化的 Machine Code(实际上是汇编代码)。

如果函数没有被调用，则 V8 不会去编译它。
如果函数只被调用 1 次，则 Ignition 将其编译 Bytecode 就间接解释执行了。TurboFan 不会进行优化编译，因为它须要 Ignition 收集函数执行时的类型信息。这就要求函数至多须要执行 1 次，TurboFan 才有可能进行优化编译。
如果函数被调用屡次，则它有可能会被辨认为 热点函数，且 Ignition 收集的类型信息证实能够进行优化编译的话，这时 TurboFan 则会将 Bytecode 编译为 Optimized Machine Code（已优化的机器码），以进步代码的执行性能。

图片中的红色虚线是逆向的，也就是说 Optimized Machine Code 会被还原为 Bytecode，这个过程叫做 Deoptimization。这是因为 Ignition 收集的信息可能是谬误的，比方 add 函数的参数之前是整数，起初又变成了字符串。生成的 Optimized Machine Code 曾经假设 add 函数的参数是整数，那当然是谬误的，于是须要进行 Deoptimization。

function add(x, y) {return x + y;}

add(1, 2);
add('1', '2');

V8 实质上是一个虚拟机，因为计算机只能辨认二进制指令，所以要让计算机执行一段高级语言通常有两种伎俩：

第一种是将高级代码转换为二进制代码，再让计算机去执行；
另外一种形式是在计算机装置一个解释器，并由解释器来解释执行。

解释执行和编译执行都有各自的优缺点，解释执行启动速度快，然而执行时速度慢，而编译执行启动速度慢，然而执行速度快。为了充沛地利用解释执行和编译执行的长处，躲避其毛病，V8 采纳了一种衡量策略，在启动过程中采纳了解释执行的策略，然而如果某段代码的执行频率超过一个值，那么 V8 就会采纳优化编译器将其编译成执行效率更加高效的机器代码。

简略总结如下，V8 执行一段 JavaScript 代码所经验的次要流程 包含：

初始化根底环境；
解析源码生成 AST 和作用域；
根据 AST 和作用域生成字节码；
解释执行字节码；
监听热点代码；
优化热点代码为二进制的机器代码；
反优化生成的二进制机器代码。

对于异步编程和音讯队列，UI 线程提供一个音讯队列，并将待执行的事件增加到音讯队列中，而后 UI 线程会一直循环地从音讯队列中取出事件、执行事件，通用 UI 线程宏观架构如下图所示：

WebView 是一种嵌入式浏览器，原生利用能够用它来展现网络内容 。WebView 只是一个 可视化的 组件 / 控件 / 微件等。这样咱们能够用它来作为咱们原生 app 的视觉局部。当你应用原生利用时，WebView 可能只是被暗藏在一般的原生 UI 元素中，你甚至用不到留神到它。

如果你把浏览器设想成两局部，一部分是 UI（地址栏，导航栏按钮等），其它局部是把标记跟代码转换成咱们可见和可交互视图的引擎。WebView 就是浏览器引擎局部，你能够像插入 iframe 一样将 Webview 插入到你的原生利用中，并且编程化的通知它将会加载什么网页内容。

运行在你的 WebView 中的 JavaScript 有能力调用原生的零碎 API。这意味着你不用受到 Web 代码通常必须恪守的传统浏览器平安沙箱的限度。下图解释了应用这种技术后的架构差别：

默认状况下，在 WebView 或 Web 浏览器中运行的任何 Web 代码都与利用的其余部分放弃隔离。这样做是出于平安起因，次要是为升高歹意的 JavaScript 代码对系统造成的挫伤。对于任意 Web 内容，这种安全级别很有意义, 因为你永远不能齐全信赖加载的 Web 内容。但 WebView 的状况并非如此，对于 WebView 计划，开发人员通常能够齐全管制加载的内容。恶意代码进入并在设施上造成凌乱的可能性非常低。

这就是为什么对于 WebView，开发人员能够应用各种受反对的形式来笼罩默认的平安行为，并让 Web 代码和原生利用代码互相通信。这种沟通通常称为 bridge。你能够在上文的图片中看到 bridge 可视化为 Native Bridge 和 JavaScript Bridge 的一部分。

WebView 十分好，尽管它看起来像是齐全非凡和独特的，但请记住，它们只不过是一个在利用中设置好地位和大小的、没有任何花哨 UI 的浏览器，这就是它的精华。大多数状况下，除非您调用原生 API，否则您不用在 WebView 中专门测试您的 Web 应用程序。此外，您在 WebView 中看到的内容与您在浏览器中看到的内容雷同，尤其是应用同一渲染引擎时：

在 iOS 上，Web 渲染引擎始终是 WebKit，与 Safari 和 Chrome 雷同。是的，你没看错。iOS 上的 Chrome 实际上应用了 WebKit。
在 Android 上的渲染引擎通常是 Blink，与 Chrome 雷同。
在 Windows，Linux 和 macOS 上，因为这些是更宽松的桌面平台，因而在抉择 WebView 格调和渲染引擎时会有很大的灵活性。你看到的风行渲染引擎将是 Blink（Chrome）和 Trident（Internet Explorer），然而没有一个引擎能够依赖。这齐全取决于利用以及它正在应用的 WebView 引擎。

WebView 的利用：

WebView 最常见的用处之一是显示链接的内容；
广告依然是原生利用最风行的赚钱形式之一，大多数广告是通过 WebView 提供的 Web 内容进行投放的；
Hybrid Apps，混合应用程序很受欢迎有几个起因，最大的一个是进步开发人员的生产力。如果你有一个能够在浏览器中运行的响应式 Web 应用程序，那么让雷同的应用程序在各种设施上与混合应用程序一起运行是相当简略的；当你对 Web 利用进行更新时，所有应用它的设施都能够立刻应用该更改，因为内容来自一个集中的服务器，而如果是纯原生利用，部署和更新时，你将不得不经验针对每个平台的构建、审核；
原生利用扩大，如 Microsoft Office 中相似维基百科这样的基于网络的扩大就是通过一个 WebView 实现的。

如果你对 WebView 感兴趣，可通过以下几篇文章持续理解：

7.5.1 WebView(网页视图)根本用法
Android：这是一份全面 & 具体的 Webview 应用攻略

无头浏览器 是一种未配置图形用户界面 (GUI) 的 Web 浏览器，通常通过命令行或网络通信来执行。它次要由软件测试工程师应用，没有 GUI 的浏览器执行速度更快，因为它们不用绘制视觉内容。无头浏览器的最大益处之一是它们可能在没有 GUI 反对的服务器上运行。

Headless 浏览器对于测试网页特地有用，因为它们可能像浏览器一样出现和了解超文本标记语言，包含页面布局、色彩、字体抉择以及 JavaScript 和 AJAX 的执行等款式元素，这些元素在应用其余测试方法时通常是不可用的。

Headless 浏览器有两个次要可交付成绩：

无头库，它容许嵌入利用程序控制浏览器并与网页交互。
一个无头外壳，它是一个示例应用程序，用于执行无头 API 的各种性能。

Puppeteer 是一个 Node 库，他提供了一组用来操纵 Chrome 的 API, 艰深来说就是一个 headless chrome 浏览器 (当然你也能够配置成有 UI 的，默认是没有的)。既然是浏览器，那么咱们手工能够在浏览器上做的事件 Puppeteer 都能胜任, 另外，Puppeteer 翻译成中文是”木偶”意思，所以听名字就晓得，操纵起来很不便，你能够很不便的操纵她去实现：

1）生成网页截图或者 PDF
2）高级爬虫，能够爬取大量异步渲染内容的网页
3）实现 UI 自动化测试，模仿键盘输入、表单主动提交、点击、登录网页等
4）捕捉站点的工夫线，以便追踪你的网站，帮忙剖析网站性能问题
5）模仿不同的设施
6）…

Puppeteer 跟 webdriver 以及 PhantomJS 最大的的不同就是它是站在用户浏览的角度，而 webdriver 和 PhantomJS 最后设计就是用来做自动化测试的，所以它是站在机器浏览的角度来设计的，所以它们应用的是不同的设计哲学。

Headless Chrome architecture
puppeteer
Puppeteer 入门教程
联合我的项目来谈谈 Puppeteer

Electron（原名为 Atom Shell）是 GitHub 开发的一个开源框架。它通过应用 Node.js（作为后端）和 Chromium 的渲染引擎（作为前端）实现跨平台的桌面 GUI 应用程序的开发。现已被多个开源 Web 应用程序用于前端与后端的开发，驰名我的项目包含 GitHub 的 Atom 和微软的 Visual Studio Code。

Electron Architecture 由多个 Render Process 和一个 Main 过程组成。Main Process 启动 Render Process，它们之间的通信是通过 IPC [Inter Process Communication]，如下图所示。

咱们罕用的 IDE VSCode 就是基于 Electron (原来叫 Atom Shell) 进行开发的。如下图所示，（点击 VSCode 帮忙【Help】下的切换开发人员工具即可关上以下面板）。

VS Code 的其余的次要组件有：

壳：Monaco Editor
内核：Language Server Protocol（一个代码编辑器）
Debug Adapter Protocol
Xterm.js

延长浏览：Electron | Build cross-platform desktop apps with JavaScript, HTML, and CSS

caniuse
browseemall
html5test

浏览器简史
Web 浏览器相干的一些概念
浏览器的工作原理：旧式网络浏览器幕后揭秘
从浏览器多过程到 JS 单线程，JS 运行机制最全面的一次梳理
🤔 挪动端 JS 引擎哪家强？美国硅谷找 ……
从 V8 角度揭秘你不晓得的面试八股文
高性能 JavaScript 引擎 V8 – 垃圾回收
Inside look at modern web browser【一共四篇，可供参考】

Inside look at modern web browser
浏览器是如何工作的：Chrome V8 让你更懂 JavaScript
深刻了解 JSCore
The Story of the Web: A History Of Internet Browsers
PPT – Browser Architecture
JavaScript 引擎 V8 执行流程概述
Understanding WebViews
Quantum Up Close: What is a browser engine?

本文首发于集体博客，欢送斧正和 star。

关于前端:47-张图带你走进浏览器的世界

浏览器倒退简史

浏览器的诞生与倒退

浏览器市场份额

浏览器架构

计算机的外围

CPU

GPU

过程与线程

浏览器的过程 / 线程架构模型

浏览器过程分类

Chrome 多过程架构

浏览器整体架构

用户界面

浏览器引擎

渲染引擎

网络

JavaScript 解释器

用户界面后端

数据存储

求同存异的浏览器架构

浏览器基本原理

Chrome V8

V8 的晚期架构

V8 的现有架构

JavaScriptCore

浏览器与 JavaScript

V8 执行一段 JavaScript 的流程

Chrome V8 的事件机制

浏览器的不同状态

WebView

Headless browser

Electron

浏览器代码兼容性测试

延长浏览

参考资料