浏览器内核之 WebKit 架构与模块

客官°小女子只卖身不卖艺 2021-06-26 16:06 531阅读 0赞

## 前言 ##

此文章是我最近在看的【`WebKit` 技术内幕】一书的一些理解和做的笔记。  
而【`WebKit` 技术内幕】是基于 `WebKit` 的 `Chromium` 项目的讲解。

## 1、 `WebKit` 之架构 ##

`WebKit` 的一个显著特征就是支持不同的浏览器，因为不同浏览器的需求不同，所以在 `WebKit` 中一些代码 可以共享，但是另外一部分是不同的，这些不同的部分称为 `WebKit` 的移植( `Ports` ）。

![WebKit 架构][WebKit]  
上图的 `WebKit` 架构，虚线框表示该部分模块在不同浏览器使用的 `WebKit` 内核中的实现是不同的，也就是它们 不是普遍共享的。用实线框表示的部分，表示它们是基本上是共享的，但不是绝对，是因为它们中的一些特性可能并不是共享的，而且可以通过不同的编译设置改变它们的行为。

图中最下面的是操作系统，不同浏览器可能会依赖不同的操作系统，同一个浏览器使用的 `WebKit` 也可能依赖不同的的操作系统。  
操作系统之上的就是 `WebKit` 赖以工作的众多第三方库，这些库是 `WebKit` 运行的基础。  
在它们二者之上的就是 `WebKit` 项目了。

`WebCore` 包含了了目前被 各个浏览器所使用的 `WebKit` 共享部分，这些都是加载和渲染网页的基础部分，它们必不可少，包括 **HTML (解释器)、CSS (解释器)、SVG、DOM、渲染树（RenderObject 树和RenderLayer 树等)，以及 Inspector(Web Inspector和调试网页)**。这些共享部分有些是基础框架，其背后支持也需要各个平台的不同实现。

`JavaScriptCore` 引擎是 `WebKit` 中默认 `JavaScript` 引擎，也就是说一些 `WebKit` 的移植使用该引擎。而且它只是默认，并不是唯一的，是可以替换的。事实上，`WebKit` 中对 `JavaScript` 引擎的调用是独立于引擎的。在 `Google` 的 `Chormium` 开源项目中，它被替换成 `V8` 引擎。  
`WebKit Ports` 指的是 `WebKit` 中的非共享部分，对于不同浏览器使用的 `WebKit` 来说，移植中的这些模块由于平台差异、第三方库和需求不同等原因，往往按照自己的方式来设计与实现，这就产生了移植部分，这也是导致众多 `WebKit` 版本的行为并非一到的重要原因。这其中包括硬件的 加速架构，网络栈，视频解码，图片解码等。

在 `WebCore` 和 `WebKit Ports` 之上的层主要是提供嵌入式编程接口，这些接口是提供给浏览器调用（当然也可以有其他使用者）。图中有左右两个部分分别是狭义 `WebKit` 的接口和 `WebKit2` 的接口。因为接口与具体的移植有关，所以有一个与浏览器相关的绑定层。绑定层上面就是 `WebKit` 项目对外暴露的接口层。实际上接口层的定义也是与移植密切相关的，而不是 `WebKit` 有什么统一接口。

`WebKit` 还有一个部分在图中没有展现出来，那就是测试用例，包括布局测试用例( `Layout Tests` )和性能测试用例（ `Performance Tests` ），这两类测试包括了大量的测试用例和期望结果。为了保证 `WebKit` 的代码质量，这些用例被用来验证渲染结果的正确性。

### `WebKit` 源代码结构 ###

![image.png][]  
![image.png][image.png 1]

### 基于 `Blink` 的 `Chromium` 浏览器结构 ###

`Chromium` 也是基于 `WebKit` ( `Blink` ) 的，而且在 `WebKit` 的移植部分中，所以可以通过 `Chromium` 可以了解如何基于 `WebKit` 构建浏览器。

### 架构与模块 ###

![image.png][image.png 2]  
在上面这些模块之上的就是著名 的 "`Content` 模块" 和 “`Content API`（接口）”，它们是 `Chromium` 对渲染网页功能的抽象。"`Content` 模块" 的本意是指网页的内容，这里是指用来渲染内容的模块。如果没有 `Content` 模块，浏览器的开发者也可以在 `WebKit` 的 `Chormium` 移植上渲染网页内容，但是没有办法获得沙箱模型。跨进程的 `GPU` 硬件加速机制、众多的 `HTML5` 功能，因为这些功能 很多是在 `Content` 层里面实现的。

“`Content` 模块” 和 “`Content API`” 将下面的渲染机制。安全机制和插件机制等隐藏起来，提供一个接口层。该接口目前被上层模块或者其他项目使用，内部 调用者包括 `Chromium` 浏览器、 `Content Shell` 等、外部包括 CEF (`Chromium Embedded Framework`)、`Opera` 浏览器等。

“`Chromium` 浏览器” 和 ”`Content Shell`“ 是构建在 `Content API` 之上的两个 ”浏览器“，`Chromium` 具有浏览器完整的功能，也就是我们编译出来能看到的浏览器式样。而 ”`Content Shell`“ 是使用 `Content API` 来包装的一层简单的 ”壳“，但是它也是一个简单的 ”浏览器“，用户可以使用 `Content` 模块来渲染和显示网页内容。`Content Shell` 的作用很明显，其一可以用来测试 `Content` 模块很多功能的正确性，例如渲染、硬件加速等。其二是一个参考，可以被很多外部的项目参考来开发基于 ”`Content API`“ 的浏览器或者各种类型的项目。

在 `Android` 系统上， `Content Shell` 的作用更大，这是因为同它并排的左侧的 ”`Chromium` 浏览器“ 部分的代码根本就没有开源，这直接导致开发者只能依赖 `Content Shell`。

”`Android WebView`“ 是为了满足 `Android` 系统上的 `WebView` 而设计的，其思想是利用 `Chromium` 的实现来替换原来 `Android` 系统默认的 `WebView`。

### 多进程模型 ###

多进程模型至少带来了三点好处：  
1、避免因单个页面不响应或者崩溃而影响整个浏览器的稳定性  
2、当第三方插件崩溃时不会影响页面或者浏览器的稳定性，这时因为第三方插件也被使用单独的进程来运行  
3、它方便了安全模型的实施，也就是说沙箱模型是基于多进程架构的。  
![image.png][image.png 3]  
![image.png][image.png 4]

**Chromium 浏览器主要包括以下进程类型：**  
1、`Browser` 进程：浏览器的主进程，负责浏览器界面的显示、各个页面的管理、是所有其他类型进程的祖先、负责它们的创建和销毁等工作，它有且仅有一个。  
2、`Renderer` 进程：网页的渲染进程，负责页面的渲染工作， Blink/WebKit 的渲染工作主要在这个进程中完成，可能有多个，但是 Renderer 进程的数量与用户打开的网页数量不一定一致，Chromium 设计了灵活的机制，允许用户配置。此外，在沙箱模型启动的情况下，该进程可能会发生一些改变。  
3、`NPAPI` 插件进程：该进程是为 NPAPI 类型的插件而创建的。其创建的基本原则是每种类型的插件只会被创建一次，而且仅当使用时才会被创建。当有多个网页需要使用同一种类型的插件的时候，例如很多网页需要使用 Flash 插件， Flash 插件的进程会为每个使用者创建一个实例，所以插件进程是被共享的。  
4、`GPU` 进程： 最多只有一个，当且仅当 GPU 硬件加速打开的时候才会被创建，主要用于对 3D 图形加速调用的实现。  
5、`Pepper` 插件进程：同 NPAPI 插件进程，不同的是为 Pepper 插件而创建的进程。  
6、其他类型的进程：图中还有一些其他类型的进程没有描述出来，例如 Linux 下的 “Zygote” 进程，Renderer 进程其实都是由它创建而来。另外一个就是名为 “Sandbox” 的准备进程，这在安全机制中作进一步的介绍。

对于桌面系统（`Windows、Liunx、Mac OS`）中的 `Chormium` 的浏览器，它们的进程模型总结后包括以下一些特征：  
1、`Browser` 进程和页面的渲染分开的，这保证了页面的渲染导致的崩溃不会导致浏览器主界面的崩溃。  
2、每个网页是独立的进程，这保证了页面之间相互不影响。  
3、插件进程也是独立的，插件本身的问题不会影响浏览器主界面和网页  
4、`GPU` 硬件加速进程也是独立的。

![image.png][image.png 5]  
![在这里插入图片描述][20190829131133401.png]  
![image.png][image.png 6]

### `Browser` 进程和 `Render` 进程 ###

`Browser` 进程和 `Render` 进程是如何利用 `WebKit` 渲染网页的，这其中的代码层次由图 3-6 给出。

最下面的就是 `WebKit` 接口层，一般基于 `WebKit` 接口层的浏览器直接在上面构建，而没有引入复杂的多进程架构。

然后，在 `WebKit` 接口层上面就是 `Chromium` 基于 `WebKit` 的接口层而引入黏附层，它的出现主要是因为 `Chromium` 中的一些类型和 `WebKit` 内部不一致，所以需要一个简单的桥接层。  
![image.png][image.png 7]  
再上面的就是 `Renderer`，它主要是处理进程间通信，接受来自`Browser` 进程的请求，并调用相应的 `WebKit` 接口层，同时，将 `WebKit` 的处理结果发送回去，上面这些介绍的层都是在 `Renderer` 进程中工作的。

下面就进入了 `Browser` 进程，与 `Renderer` 进程相对应的就是 `RendererHost`, 其目的也是处理同 `Renderer` 进程之间的通信。不过 `RendererHost` 是给 `Renderer` 进程发送请求并接收来自 `Renderer` 进程的结果。

`Web Contents` 表示的就是网页的内容，因为网页可能有多个需要绘制的内容，例如弹出的对话框内容，所以这里是 “`Contents`”。它同时包括显示网页内容的一个子窗口（在桌面系统上），这个子窗口最后被嵌入浏览器的用户界面，作为它的一个标签页。

### 多线程模型 ###

每个进程内部都有很多的线程。

多线程的主要目的就是为了保持用户界面的高响应度，保证 `UI` 线程（`Browser`进程中的主线程）不会被任何其他费用时的操作阻碍从而影响了对用户操作的响应。这些费时的其他操作很多，例如本地文件读写、`socket` 读写、数据库操作等。

既然文件读写等会阻碍其他操作，所以把它们放在单独的线程里面自己忙或者等待去吧。而在 `Renderer` 进程中，`Chromium` 则不让其他操作阻止渲染线程的快速执行。为了利用多核的优势，`Chromium` 将渲染过程管线化，这样可以让渲染的阶段在不同的线程执行。  
![image.png][image.png 8]  
网页的加载和渲染过程在图中模型下的基本工作方式如以下步骤：  
1、`Browser` 进程收到用户的请求，首先由 `UI` 线程处理，而且将相应的任务转给 `IO` 线程，它随即将该任务传递给 `Renderer` 进程。

2、`Renderer` 进程的 `IO` 线程经过简单解释后交给渲染线程。渲染线程接受请求，加载网页并渲染网页，这其中可能需要 `Browser` 进程获取资源和需要 `GPU` 进程来帮助渲染，最后 `Renderer` 进程将结果由 `IO` 线程传递给 `Browser` 进程。

3、最后 `Renderer` 进程接收到结果并将结果绘制出来。

### `Content` 接口 ###

`Content` 接口不仅提供了一层对多进程进行渲染的抽象接口，而且它从诞生以来一个重要的目标就是要支持所有的 `HTML5` 功能、`GPU` 硬件加速功能和沙箱机制，这可以让 `Content` 接口的使用都们不需要很多的工作即可得到很强大的能力。

`Content` 接口按照功能分成六个部分。每个部分的接口一般也可以分成两类，第一类是嵌入者（`embedder`，这里可以是 `Chromium` 浏览器、`CEF3` 和 `Content Shell` ）调用的接口，另一类是嵌入者应该实现的回调接口，被 `Content` 接口的内部实现所调用，用来参与具体实现的逻辑或者事件的监听等。  
![image.png][image.png 9]  
![在这里插入图片描述][2019082913222823.png]

## 2、 `WebKit2` ##

### `WebKit2` 架构与模块 ###

相比于狭义的 `WebKit` ，`WebKit2` 是一套全新的结构和接口，而不是一个简单的升级版。它的主要目的和思想同 `Chromium` 类似，就是将渲染过程放在单独的进程中来完成，独立于用户界面。  
![image.png][image.png 10]

依旧是自底向上介绍，`WebKit2` 中也引入了插件进程，而且它还引入了网络进程。图中的 “Web 进程” 对应于 `Chromium` 中的 `Renderer` 进程，主要是渲染网页。在这之上的是 “UI 进程”，它对应于 Chromium 中的 `Browser` 进程。接口就是暴露在该进程中，应用程序只需要调用该接口即可。其中 “应用程序 ” 指的是浏览器或者任何使用该接口的程序。

### `WebKit` 和 `WebKit2` 嵌入式接口 ###

![在这里插入图片描述][20190829132450576.png]  
![在这里插入图片描述][20190829132704398.png]  
![在这里插入图片描述][20190829133015307.png]

### 比较 `WebKit2` 和 `Chromium` 的多进程模型以及接口 ###

![在这里插入图片描述][20190829133122984.png]  
![在这里插入图片描述][20190829133140940.png]

## 3、最后 ##

希望本文对你有点帮助。

[WebKit]: /images/20210626/10359f4cfd1f4d5887f081b723a65024.png
[image.png]: /images/20210626/649117be8687462daa31a0aecc6e9e32.png
[image.png 1]: /images/20210626/d3f03b146d614059ae0c47a7b78b8ff5.png
[image.png 2]: /images/20210626/36b90ae106034e53bbf5c0e5b9b880b1.png
[image.png 3]: /images/20210626/3eb3f78743174acd8637f1c0b661f57e.png
[image.png 4]: /images/20210626/86b934686fc940cbb5d13dba7bd2388e.png
[image.png 5]: /images/20210626/5104100e1ed84849a39370af299b939d.png
[20190829131133401.png]: /images/20210626/6f5592456a9c409e898fb98943928c37.png
[image.png 6]: /images/20210626/21c08c051ed24abd8af72cc0f3715990.png
[image.png 7]: /images/20210626/23debdabfe744dc5bdffd599f2458be1.png
[image.png 8]: /images/20210626/5009972420ef46e3a20e2e532ae57737.png
[image.png 9]: /images/20210626/9c15179b3a164763bf36076a91fd4422.png
[2019082913222823.png]: /images/20210626/368b83b1f48143f99ecc6c56a2f35cd1.png
[image.png 10]: /images/20210626/b5e042dd03f14da3ac580cbdffded1bd.png
[20190829132450576.png]: /images/20210626/03712a9cb40c4c4dbaf46c26f661ccb2.png
[20190829132704398.png]: /images/20210626/da940069b87c48c88818108a2b8aa9f2.png
[20190829133015307.png]: /images/20210626/5765a21799ef43a5880535441ef57ad5.png
[20190829133122984.png]: /images/20210626/5ce550cf79a4454e81942a671f2bcb07.png
[20190829133140940.png]: /images/20210626/be60fc0b880a4934b8cdcec016aa7054.png