Webkit底层原理(1)--Webkit架构和模块

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接：https://blog.csdn.net/caomage/article/details/101923150

一、Webkit架构

Webkit的一个显著的特征就是它支持不同的浏览器，因为不同浏览器的需求不同，所以在Webkit中，一些代码可以共享，但是另一部分是不同的，这些不同的部分称为Webkit移植（Ports）。Webkit的整体结构如图：

在这里插入图片描述

图中最下面是操作系统，Webkit可以在不同的操作系统上工作。不同浏览器可能会依赖不同的操作系统，同一个浏览器使用的Webkit也可能依赖不同的操作系统，例如，Chromium浏览器支持Windows、Mac OS、Linux、Android等系统。在操作系统层之上就是Webkit赖以工作的众多第三方库，这些库是Webkit运行的基础。如何高效的使用它们是Webkit和各种浏览器厂商的重大课题，主要是如何设计良好的架构来利用它们以获得高性能。 在这些库之上就是Webkit项目了，图中将其分为两层，每层包含很多模块，图中这些模块支撑了网页加载和渲染过程：

1. WebCore部分包含了目前被各个浏览器所使用的Webkit共享部分，这些都是加载和渲染网页必不可少的基础部分，具体包括HTML解释器、CSS解释器、SVG、DOM、渲染树（RenderObject）、RenderLayer树等，以及Inspector（Web Inspector、调试网页）。
2. JavaScriptCore引擎是Webkit中的默认JavaScript引擎。刚开始，它的性能并不是很好，但是随着越来越多的优化被加入，现在性能已经非常不错了。之所以说它是默认的，是因为它并不是不可替换的，事实上，Webkit中对JavaScript引擎的调用是独立于引擎之上的。在Google的Chormium开源项目中，它被替换为V8引擎。
3. Webkit Ports指的是Webkit中的非共享部分，对于不同浏览器使用的Webkit来说，移植中的这些模块由于平台差异、依赖的第三方库和需求不同，往往按照自己的方式来设计和实现，这也是众多Webkit版本行为不一致的重要原因。
4. 在往上则是提供嵌入式编程接口，这些嵌入式接口是提供给浏览器调用的。
5. 当然，由于图片大小有限，还有一个重要的部分没有画出来，那就是测试用例，包括布局测试用例和性能测试用例。

二、Chromium浏览器结构及模块

1. 结构和模块

Chromium也是基于Webkit（Blink）的，结构如图：

在这里插入图片描述

图中描述了Chromium的架构和主要的模块。从图中可以看出，Blink只是其中一块，和它并列的还有很多模块，包括V8引擎、沙箱模型等等。 在这些模块之上就是Content模块和Content接口，它们是Chromium对网页功能的抽象。它们将下面的渲染机制、安全机制和插件机制等隐藏起来，提供一个接口层。该接口目前被上层模型或者其他项目使用。 Chromium浏览器和Content Shell是构件在Content API上的两个浏览器，Chromium具有浏览器的完整功能，Content Shell是使用Content API来包装的一层简单的壳，但是它也是一个简单的浏览器，用户可以使用Content模块来渲染网页内容。

2. 多进程模型

以前使用浏览器打开很多页面的，不幸其中某个页面崩溃了，会导致其他所有的页面也都崩溃。但是，现在好了，浏览器都支持多进程模型，虽然会带来更多的资源消耗，但是它的优势非常明显：

1. 避免因单个页面的崩溃而影响整个浏览器的稳定；
2. 当第三方插件崩溃时也不会影响浏览器的整体稳定；
3. 更加方便安全模型的实施。

下图是Chromium的多进程模型：

在这里插入图片描述

其中包含一下进程类型：

1. Browser进程：浏览器的主进程，负责浏览器界面的显示、各个页面的管理，有且仅有一个。
2. Renderer进程：网页的渲染进程，负责页面的渲染工作，Blink/Webkit的渲染工作主要在该进程中完成，可能有多个，注意：Renderer进程的数量和用户打开的页面数量不一定相等。Chromium设计了灵活的机制，允许用户配置。
3. NPAPI插件进程：该进程是为NPAPI类型的插件而创建的。其创建的基本原则是每种类型的插件只会被创建一次，而且仅当使用的时候才创建。插件进程是被共享的。
4. GPU进程：最多一个，当且仅当GPU硬件加速打开的时候才会被创建，主要用于3D图形加速调用的实现。
5. Pepper插件进程：同NPAPI插件进程。

3. 多线程模型

每个进程内部都有很多的线程，多线程的目的是为了保持用户界面的高响应度，保证UI线程不会被其他费时的操作阻塞从而影响用户体验。类似的费时操作有很多，比如本地文件读写，数据库操作等。而在Renderer进程中，Chromium则不让其他操作阻塞渲染进程的快速进行。更甚者，为了利用多核的优势，将渲染过程管线化，只有可以让渲染的不同阶段在不同的线程中执行。下图是主要进程中的重要线程信息以及它们是如何工作的。

在这里插入图片描述

网页的加载和渲染过程如下：

1. Browser进程收到用户的请求，首先有UI线程处理，而且将相应的任务转给IO线程，它随即将该任务交给Renderer进程；
2. Renderer进程的IO线程经过简单的解释够交给渲染线程。渲染线程接受请求，加载网页并渲染网页，这其中可能需要Browser进程获取资源和需要GPU进程来帮助渲染。最后Renderer进程将结果有IO线程传递给Browser进程；
3. 最后，Browser接收到结果并将结果绘制出来。