关于前端:Webkit-内核初探

• 作者: 阿吉
• 校对 & 整顿: lucifer

当下浏览器内核次要有 Webkit、Blink 等。本文剖析留神是自 2001 年 Webkit 从 KHTML 拆散进来并开源后，各大浏览器厂商魔改 Webkit 的期间，这些魔改的内核最终以 Chromium 受众最多而怀才不遇。本文就以 Chromium 浏览器架构为根底，逐层探入进行分析。

引子

这里以一个面试中最常见的题目 从 URL 输出到浏览器渲染页面产生了什么？开始。

这个很常见的题目，波及的常识十分宽泛。大家可先从浏览器监听用户输出开始，浏览器解析 url 的局部，剖析出应用层协定 是 HTTPS 还是 HTTP 来决定是否通过会话层 TLS 套接字，而后到 DNS 解析获取 IP，建设 TCP 套接字池 以及 TCP 三次握手，数据封装切片的过程，浏览器发送申请获取对应数据，如何解析 HTML，四次挥手等等等等。这个答复实践上能够十分具体，远比我提到的多得多。

本文试图从浏览器获取资源开始探索 Webkit。如浏览器如何获取资源，获取资源时 Webkit 调用了哪些资源加载器（不同的资源应用不同的加载器），Webkit 如何解析 HTML 等动手。想要从前端工程师的角度弄明确这些问题，能够先临时抛开 C++ 源码，从浏览器架构登程，做到大抵理解。之后学有余力的同学再去深入研究各个底层细节。

本文的路线循序渐进，从 Chromium 浏览器架构登程，到 Webkit 资源下载时对应的浏览器获取对应资源如 HTML、CSS 等，再到 HTML 的解析，再到 JS 阻塞 DOM 解析而产生的 Webkit 优化 引出浏览器多线程架构，继而出于安全性和稳定性的思考引出浏览器多过程架构。

一. Chromium 浏览器架构

（Chromium 浏览器架构）

咱们通常说的浏览器内核，指的是渲染引擎。

WebCore 根本是共享的，只是在不同浏览器中应用 Webkit 的实现形式不同。它蕴含解析 HTML 生成 DOM、解析 CSS、渲染布局、资源加载器等等，用于加载和渲染网页。

JS 解析能够应用 JSCore 或 V8 等 JS 引擎。咱们相熟的谷歌浏览器就是应用 V8。比方比拟常见的有内置属性 [[scope]] 就仅在 V8 外部应用，用于对象依据其向上索引本身不存在的属性。而对外裸露的 API，如 __proto__ 也可用于更改原型链。实际上 __proto__ 并不是 ES 规范提供的，它是浏览器提供的（浏览器能够不提供，因而如果有浏览器不提供的话这也并不是 b ug）。

Webkit Ports 是不共享的局部。它蕴含视频、音频、图片解码、硬件加速、网络栈等等，罕用于移植。

同时，浏览器是多过程多线程架构，稍后也会细入。

在解析 HTML 文档之前，须要先获取资源，那么资源的获取在 Webkit 中应该如何进行呢？

二.Webkit 资源加载

HTTP 是超文本传输协定，超文本的含意即蕴含了文本、图片、视频、音频等等。其对应的不同文件格式，在 Webkit 中 须要调用不同的资源加载器，即 特定资源加载器。

而浏览器有四级缓存，Disk Cache 是咱们最常说的通过 HTTP Header 去管制的，比方强缓存、协商缓存。同时也有浏览器自带的启发式缓存。而 Webkit 对应应用的加载器是资源缓存机制的资源加载器 CachedResoureLoader 类。

如果每个资源加载器都实现本人的加载办法，则节约内存空间，同时违反了繁多职责的准则，因而能够形象出一个共享类，即通用资源加载器 ResoureLoader 类。Webkit 资源加载是应用了三类加载器：特定资源加载器，资源缓存机制的资源加载器 CachedResoureLoader 和 通用资源加载器 ResoureLoader。

既然说到了缓存，那无妨多谈一点。

资源既然缓存了，那是如何命中的呢？答案是依据资源唯一性的特色 URL。资源存储是有肯定有效期的，而这个有效期在 Webkit 中采纳的就是 LRU 算法。那什么时候更新缓存呢？答案是不同的缓存类型对应不同的缓存策略。咱们晓得缓存少数是利用 HTTP 协定缩小网络负载的，即强缓存、协商缓存。然而如果敞开缓存了呢？比方 HTTP/1.0 Pragma:no-cache 和 HTTP/1.1 Cache-Control: no-cache。此时，对于 Webkit 来说，它会清空全局惟一的对象 MemoryCache 中的所有资源。

资源加载器内容先到这里。浏览器架构是多过程多线程的，其实多线程能够间接体现在资源加载的过程中，在 JS 阻塞 DOM 解析中发挥作用，上面咱们具体解说一下。

三. 浏览器架构

浏览器是多过程多线程架构。

对于浏览器来讲，从网络获取资源是十分耗时的。从资源是否阻塞渲染的角度，对浏览器而言资源仅分为两类：阻塞渲染 如 JS 和 不阻塞渲染 如图片。

咱们都晓得 JS 阻塞 DOM 解析，反之亦然。然而对于阻塞，Webkit 不会傻傻等着浪费时间，它在外部做了优化：启动另一个线程，去遍历后续的 HTML 文档，收集须要的资源 URL，并发下载资源。最常见的比方 <script async> 和<script defer>，其 JS 资源下载和 DOM 解析是并行的，JS 下载并不会阻塞 DOM 解析。这就是浏览器的多线程架构。

总结一下，多线程的益处就是，高响应度，UI 线程不会被耗时操作阻塞而齐全阻塞浏览器过程。

对于多线程，有 GUI 渲染线程，负责解析 HTML、CSS、渲染和布局等等，调用 WebCore 的性能。JS 引擎线程，负责解析 JS 脚本，调用 JSCore 或 V8。咱们都晓得 JS 阻塞 DOM 解析，这是因为 Webkit 设计上 GUI 渲染线程和 JS 引擎线程的执行是互斥的。如果二者不互斥，假如 JS 引擎线程清空了 DOM 树，在 JS 引擎线程清空的过程中 GUI 渲染线程仍持续渲染页面，这就造成了资源的节约。更重大的，还可能产生各种多线程问题，比方脏数据等。

另外咱们常说的 JS 操作 DOM 耗费性能，其实有一部分指的就是 JS 引擎线程和 GUI 渲染线程之间的通信，线程之间比拟耗费性能。

除此之外还有别的线程，比方事件触发线程，负责当一个事件被触发时将其增加到待处理队列的队尾。

值得注意的是，多启动的线程，仅仅是收集后续资源的 URL，线程并不会去下载资源。该线程会把下载的资源 URL 送给 Browser 过程，Browser 过程调用网络栈去下载对应的资源，返回资源交由 Renderer 过程进行渲染，Renderer 过程将最终的渲染后果返回 Browser 过程，由 Browser 过程进行最终出现。这就是浏览器的多过程架构。

多过程加载资源的过程是如何的呢？咱们下面说到的 HTML 文档在浏览器的渲染，是交由 Renderer 过程的。Renderer 过程在解析 HTML 的过程中，已收集到所有的资源 URL，如 link CSS、Img src 等等。但出于安全性和效率的角度思考，Renderer 过程并不能间接下载资源，它须要通过过程间通信将 URL 交由 Browser 过程，Browser 过程有权限调用 URLRequest 类从网络或本地获取资源。

近年来，对于有的浏览器，网络栈由 Browser 过程中的一个模块，变成一个独自的过程。

同时，多过程的益处远远不止平安这一项，即沙箱模型。还有单个网页或者第三方插件的解体，并不会影响到浏览器的稳定性。资源加载实现，对于 Webkit 而言，它须要调用 WebCore 对资源进行解析。那么咱们先看下 HTML 的解析。之后咱们再谈一下，对于浏览器来说，它领有哪些过程呢？

四.HTML 解析

对于 Webkit 而言，将解析半结构化的 HTML 生成 DOM，然而对于 CSS 样式表的解析，严格意义 CSSOM 并不是树，而是一个映射表汇合。咱们能够通过 document.styleSheets 来获取样式表的有序汇合来操作 CSSOM。对于 CSS，Webkit 也有对应的优化策略 —ComputedStyle。ComputedStyle 就是如果多个元素的款式能够不通过计算就确认相等，那么就仅会进行一次款式计算，其余元素仅共享该 ComputedStyle。

共享 ComputedStyle 准则：

(1) TagName 和 Class 属性必须一样。

(2)不能有 Style。

(3)不能有 sibling selector。

(4)mappedAttribute 必须相等。

对于 DOM 和 CSSOM，大家说的合成的 render 树在 Webkit 而言是不存在的，在 Webkit 外部生成的是 RenderObject，在它的节点在创立的同时，会依据层次结构创立 RenderLayer 树，同时构建一个虚构的绘图上下文，生成可视化图像。这四个外部示意构造会始终存在，直到网页被销毁。

RenderLayer 在浏览器控制台中 Layers 性能卡中能够看到以后网页的图层分层。图层波及到显式和隐式，如 scale()、z-index 等。层的长处之一是只重绘以后层而不影响其余层，这也是 Webkit 做的优化之一。同时 V8 引擎也做了一些优化，比如说暗藏类、优化回退、内联缓存等等。

五. 浏览器过程

浏览器过程包含 Browser 过程、Renderer 过程、GPU 过程、NPAPI 插件过程、Pepper 过程 等等。上面让咱们具体看看各大过程。

• Browser 过程：浏览器的主过程，有且仅有一个，它是过程先人。负责页面的显示和治理、其余过程的治理。
• Renderer 过程：网页的渲染过程，可有多个，和网页数量不肯定是一一对应关系。它负责网页的渲染，Webkit 的渲染工作就是在这里实现的。
• GPU 过程：最多一个。仅当 GPU 硬件加速被关上时创立。它负责 3D 绘制。
• NPAPI 过程：为 NPAPI 类型的插件而创立。其创立的根本准则是每种类型的插件都只会被创立一次，仅当应用时被创立，可被共享。
• Pepper 过程：同 NPAPI 过程，不同的是 它为 Pepper 插件而创立的过程。

留神：如果页面有 iframe，它会造成影子节点，会运行在独自的过程中。

咱们仅仅在围绕 Chromium 浏览器来说上述过程，因为在挪动端，毕竟手机厂商很多，各大厂商对浏览器过程的反对也不一样。这其实也是咱们最常见的 H5 兼容性问题，比方 IOS margin-bottom 生效等等。再比方 H5 应用 video 标签做直播，也在不同手机之间会存在问题。有的手机直播页面跳出主过程再回来，就会黑屏。

以 Chromium 的 Android 版为例子，不存在 GPU 过程，GPU 过程变成了 Browser 过程的线程。同时，Renderer 过程演变为服务过程，同时被限度了最大数量。

为了不便起见，咱们以 PC 端谷歌浏览器为例子，关上工作管理器，查看以后浏览器中关上的网页及其过程。

以后我关上了 14 个网页，不太好容易察看，但能够从下图中看到，只有一个 Browser 过程，即第 1 行。然而关上的网页对应的 Renderer 过程，并不一定是一个网页对应一个 Renderer 过程，这跟 Renderer 过程配置有关系。比方你看第 6、7 行是每个标签页创立独立 Renderer 过程，然而蓝色光标所在的第 8、9、10 行是共用一个 Renderer 过程，这属于为每个页面创立一个 Renderer 过程。因为第 9、10 行关上的页面是从第 8 行点击链接关上的。第 2 行的 GPU 过程也清晰可见，以及第 3、4、5 行的插件过程。

对于，Renderer 过程和关上的网页并不一定是一一对应的关系，上面咱们具体说一下 Renderer 过程。以后只有四种多过程策略：

1. Process-per-site-instance: 为每个页面独自创立一个过程，从某个网站关上的一系列网站都属于同一个过程。这是浏览器的默认项。上图中的蓝色光标就是这种状况。
2. Process-per-site：同一个域的页面共享一个过程。
3. Process-per-tab：为每个标签页创立一个独立的过程。比方上图第 6、7 行。
4. Single process：所有的渲染工作作为多个线程都在 Browser 过程中进行。这个根本不会用到的。

Single process 忽然让我联想到零几年的时候，那会 IE 应该还是单过程浏览器。单过程就是指所有的功能模块全副运行在一个过程，就相似于 Single process。那会玩 4399 如果一个网页卡死了，没响应，点敞开等一会，整个浏览器就解体了，得从新关上。所以多过程架构是有利于浏览器的稳定性的。尽管当下浏览器架构为多过程架构，但如果 Renderer 过程配置为 Process-per-site-instance，也可能会呈现因为单个页面卡死而导致所有页面解体的状况。

故浏览器多过程架构综上所述，益处有三：

(1)单个网页的解体不会影响这个浏览器的稳定性。

(2)第三方插件的解体不会影响浏览器的稳定性。

(3)沙箱模型提供了平安保障。

总结

Webkit 应用三类资源加载器去下载对应的资源，并存入缓存池中，对于 HTML 文档的解析，在阻塞时调用另一个线程去收集后续资源的 URL，将其发送给 Browser 过程，Browser 过程调用网络栈去下载对应的本地或网络资源，返回给 Renderer 过程进行渲染，Renderer 过程将最终渲染后果 (一系列的合成帧) 发送给 Browser 过程，Browser 过程将这些合成帧发送给 GPU 从而显示在屏幕上。
(文中有局部不谨严的中央，已由 lucifer 指出批改)

大家也能够关注我的公众号《脑洞前端》获取更多更陈腐的前端硬核文章，带你意识你不晓得的前端。