Chromium为代表的浏览器架构及Blink内核的功能架构

导语：本文从市面主流的浏览器及相应的内核引擎开始，介绍了Chromium为代表的浏览器架构及Blink内核的功能架构。Chromium为多进程架构，用户从启动运行浏览器后，先后经过页面导航、渲染、资源加载、样式计算、布局、绘制、合成到栅格化，最后完成GPU展示。而页面渲染完成后，浏览器如何响应页面操作事件也进行了深入的介绍。良心推荐！   本文第二至五部分内容根据 Mariko Kosaka 的英文原版《Inside look at modern web browser》，进行翻译、理解、总结提炼、条理化、加入应用示例、进行相关知识补充扩展而来。

一、浏览器概论浏览器经历了很多年的发展，浏览器引擎也在不停地迭代和演进。从PC时代到移动端，以独立浏览器的形态还是以系统WebView组件内嵌的形态存在，在互联网的生态系统中一直扮演着重要的角色。了解浏览器及其原理可以让我们打开另一个世界。  

1. 浏览器引擎

以下是市面留存的主流浏览器的引擎介绍。

1.1 浏览器引擎

Trident：IE浏览器引擎

Gecko：Firefox浏览器引擎

Presto：Opera浏览器引擎

Webkit：Safari，Google Chrome浏览器引擎。  

1) Chromium：基于webkit，08年开始作为Chrome的引擎，Chromium浏览器是Chrome的实验版，实验新特性。   2) Webkit2：2010年随OS X Lion一起面世。WebCore层面实现进程隔离与Google的沙箱设计存在冲突。   3) Blink：基于Webkit2分支，13年谷歌开始作为Chrome 28的引擎集成在Chromium浏览器里。Android的WebView同样基于Webkit2。  1.2 微软浏览器目前PC场景操作系统仍是windows一统天下，对桌面用户来说，虽然IE的市场份额在下降，但是IE曾经也风光过。IE内核以Trident为主，最新的Edge也兼容了Chromium内核。   Microsoft Edge：内核为：EDGE，Windows 10默认浏览器，不能单独下载安装。兼容Chromium内核，同时保留EDGE内核来兼容企业网站

Internet Explorer 11：Windows 8.1，引擎Trident 7.0

Internet Explorer 10：Windows 8默认浏览器，引擎Trident

Internet Explorer 9

Internet Explorer 8：Windows 7集成

Internet Explorer 7：Windows Vista集成，2016年停止支持

Internet Explorer 6：2014年停止支持

2. 浏览器架构

目前chromium浏览器的架构主要由下以几个部分构成。

以下为架构的介绍：

操作系统：WebKit可以运行在不同的操作系统上，如Chromium浏览器支持Windows、Linux、Android等系统；

第三方库：这些库是WebKit运行的基础，包括2D图形库、3D图形库、网络库、存储库、音视频库等；

WebCore：WebKit加载和渲染网页的基础，是不同浏览器所使用的WebKit中共享的部分，包括HTML解析器、CSS解析器、SVG、布局、渲染树等等；

JavaScript引擎：JavaScript解析器，WebKit默认的引擎是JavaScriptCore，Google的Blink为V8引擎；

WebKit Ports：WebKit中的移植部分，包括网络栈、音视频解码、硬件加速等模块，这部分对WebKit的功能和性能影响比较大。

WebKit嵌入式接口：WebKit对外暴露的接口层，这个接口是提供给浏览器调用的，如给chromium调用，因为接口与具体的移植也有关系，所以中间会有一个WebKit绑定层

JavaScriptCore（用于Safari）

JavaSript Parser，JSON Parser

字节编译器：使用内部字节码格式

汇编程序：在运行时使用代码修补 - >它需要可写代码内存

数据流图：基于编译时推测优化生成代码的新举措

解释器：运行生成的字节码

Regexp引擎：支持JIT

垃圾收集器：标记和扫描

运行时：所有JS全局对象（日期，字符串，数字等）

调试器，Profiler

WebCore

资源加载器：HTML和XML解析器，DOM

SVG和SMIL

CSS：分析器，选择器，动画

渲染和布局

绑定生成器：IDL文件：JSC，V8，ObjC

HTML5：音频，视频，画布，WebGL，通知功能

WebInspector

平台集成：图形，字体，声音，视频

相关资料

Blink内核：https://src.chromium.org/viewvc

2.1 多进程架构

  图片引自chromium-design-doc https://www.chromium.org/developers/design-documents/multi-process-architecture  2.1.1 Chromium多进程架构早期的web浏览器页面行为不当、浏览器错误、浏览器插件错误都会引起整个浏览器或当前运行的选项卡关闭。因此将chromium应用程序放在相互隔离的独立的进程中：

单个程序崩溃不会损害其他应用程序  

不影响操作系统完整性  

每个用户不能访问其他用户数据(内存保护、访问控制)

2.1.2 架构组成

UI主进程：页面选项卡、插件进程作为浏览器进程。

渲染进程：特定选项卡作为渲染进程(渲染器)，使用Blink(Webkit)开源布局引擎解释和布局HTML。

2.1.3 渲染过程管理

RenderProcess：每个渲染进程都有一个全局对象，管理与父浏览器的通信并维护全局状态  

RenderProcessHost：浏览器为每个渲染进程维护相应的渲染进程宿主，为每个渲染器管理浏览器状态和IPC(IPC已弃用，最新用Mojo)通信  

RenderView：每个渲染进程有一或多个RenderView对象，对应内容选项卡。RenderProcessHost为渲染器的每个视图(RenderView)维护一个RenderViewHost。每个视图用一个ID区分。

2.1.4 运行流程

渲染进程共享：开启浏览器新窗口或新选项卡时，创建新的浏览器进程，并创建RenderView。不同页面/iframe可共享同个渲染进程。  

崩溃监视：浏览器的IPC连接会监视进程句柄，如句柄对应的渲染进程已崩溃，会向标签发送通知，浏览器会显示“悲伤标签”  

沙箱运行：渲染器在单独的进程中运行，通过沙箱限制其对系统资源(文件、网络、显示、击键)的访问，而须通过父浏览器进程访问  

内存交回：进程最小化、隐藏的选项卡将其内存自动放入“可用内存”，内存不足时，windows会将该可用内存数据写磁盘，内存被用于更高优先级任务，以提高可见程序的响应速度。

2.1.5 插件扩展第三方编写的NPAPI插件因存在不稳定，同时需控制对系统资源的访问，在各自独立的进程中运行，与渲染器分开。   插件设计文档：https://www.chromium.org/developers/design-documents/plugin-architecture   2.2 Webkit(Blink)架构Blink是Web平台的渲染引擎，实现了浏览器选项卡中呈现的内容：

HTML：实现Web平台规范，HTML规范(DOM、CSS、Web IDL)  

JavaScript：嵌入V8并运行JavaScript  

网络：从底层网络堆栈请求资源  

渲染：构建DOM树，计算样式和布局，嵌入合成器并绘制图形  

通过内容公共Api对外提供公共能力。    

2.2.1 Blink的运行流程多进程架构，有一个浏览器进程和N个沙盒渲染器进程，Blink在沙盒渲染中运行。浏览器选项卡、iframe可共享同个渲染器进程。   沙箱运行：在沙箱中，须通过父浏览器进程来调度使用资源（文件访问、网络、音视频播放、用户配置文件读取(cookie，密码)等。Blink将浏览器进程抽象为一组服务，使用Mojo与服务、浏览器进程交互。  2.2.2  渲染进程中的线程

1个主线程：运行JavaScript、DOM、CSS、样式布局计算

N个工作线程：运行Web Worker，ServiceWorker，Worklet

内部线程：Blink和V8会创建几个线程处理web audio，数据库，GC等

跨线程通信：使用PostTask API，不鼓励共享内存编程除非性能原因。

2.2.3 Blink的运行和退出

运行：任何使用Blink的场景都需调用 BlinkInitializer::Initialize() 初始化  

退出：渲染器被强制退出，而不会被清理  

2.2.4 Blink的项目代码结构

platform：低级功能集合，如单片内核、几何、图形工具  

core：core与DOM紧密结合  

web：实现规范中的web平台功能  

modules：包含独立的功能，如web audio，indexed db等。  

bindings / core：大量使用V8 API  

controller：一组使用core、modules的高级库，如devtools。  

依赖关系：Chromium -> controller -> modules / bindings -> core / bindings -> platform -> 低级单元(base、V8、cc)

2.2.5 platform内部构成1) WTF：统一编码原语，如WTF::Vector, WTF::HashSet, WTF::HashMap, WTF::String and WTF::AtomicString来代替std:vector 等。   2) 内存管理：a. PartitionAlloc b.Oilpan(Blink GC) c.malloc/free/new/delete   3) 任务调度：为提高渲染引擎的响应，应执行异步。所有任务都应发布到Blink Scheduler任务队列，指定正确类型并设置优先级，以使得能巧妙地安排任务。   4) Page/Frame/Document/ExecutionContext/DOMWindow   分别对应选项卡、iframe、window.document、主线程和工作线程上下文、JavaScript中的窗口对象。    

渲染进程中各种数量关系

渲染器进程/Page = 1/N  

页数/帧= 1/M  

框架/DOMWindow/文档（或ExecutionContext）= 1/1/1 （会随时变化）

5) 进程外iframe 站点隔离：为每个站点创建一个渲染器进程(相同一二级域名)。跨站点由两个渲染器托管。             6) 分离的iframe/文件

doc = iframe.contentDocumentiframe.remove() //iframe 与 dom 树分离doc.createElement('div'); //仍可在分离的框架上运行脚本 左滑可查看完整代码，下同  

7) Web IDL绑定

8) V8

Isolate：一一对应物理线程。主线程、工作线程都有自己的独立线程。  

Context：对应全局对象，如为Frame时对应Frame的窗口对象，每个帧都有自己的窗口对象  

World：支持Chrome扩展程序内容脚本

关系：一个frame = N个窗口对象 = 用于N个world。Context对应该窗口对象   V8的API低级且难以使用，在platform/bindings中提供很多V8 API辅助类。每个C++ DOM对象，如Node都有其对应的V8包装器。V8包装器对应的C++ DOM对象具有强引用。C++ DOM对象只对V8包装器弱引用。

2.3 V8V8是Google的开源高性能JavaScript和WebAssembly引擎，用C++编写，它实现ECMAScript和WebAssembly，可独立运行或嵌入到任何C++应用程序中，如Chrome和Node.js。

相关资料 ECMAScript：https://tc39.es/ecma262/  WebAssembly：https://webassembly.github.io/spec/core/ 

二、Chrome的多进程架构

注意：以下内容根据 Mariko Kosaka 的英文原版《Inside look at modern web browser》(见参考文献)，进行翻译、理解、总结提炼、条理化、加入应用示例、进行相关知识补充扩展而来。

1. 背景：计算机的核心是CPU和GPU

CPU：Center Processing Unit，同时支持并行、串行操作，需很强通用性处理不同数据类型、要支持复杂通用逻辑判断，需引入大量分支和中断处理，结构异常复杂。   GPU：Graphics Processing Uint，专为执行图形渲染必须的复杂的数学和几何计算而设计。

图片引自Mariko Kosaka的《Inside look at modern web browser》  

图片引自Mariko Kosaka的《Inside look at modern web browser》  

  三层计算机体系结构 图片引自Mariko Kosaka的《Inside look at modern web browser》      

2. 基础：在Process和Thread执行程序

启动应用程序时，创建一个进程，并提供”slab”内存，所有应用程序状态保存在该专用内存中，关闭程序时，系统释放内存。  

应用程序可能会创建多个线程完成工作任务。

图片引自Mariko Kosaka的《Inside look at modern web browser》  

图片引自Mariko Kosaka的《Inside look at modern web browser》  

3. 浏览器架构

浏览器架构没有统一标准规范，不同浏览器可能使用不同线程或多个不同进程来构建web。少数线程间通过IPC通信。  

3.1 不同浏览器实现的体系结构

  图片引自Mariko Kosaka的《Inside look at modern web browser》  

3.2 Chrome的多进程架构

图片引自Mariko Kosaka的《Inside look at modern web browser》  

4. 不同进程作用

浏览器：控制应用程序chrome部分，包括地址栏，书签，后退和前进按钮。及处理Web浏览器的不可见特权部分，例如网络请求和文件访问

渲染：控制显示网站的选项卡内的任何内容

插件：控制网站使用的任何插件，例如flash。

GPU：独立于其他进程处理GPU任务。它被分成不同的进程，因为GPU处理来自多个应用程序的请求并将它们绘制在同表面中。

其他进程：浏览器右上角更多 -> 更多工具 -> 任务管理器，查看其他进程，如实用程序网络服务、辅助框架

图片引自Mariko Kosaka的《Inside look at modern web browser》  

5. 多进程架构

优点：  

防一个页面崩溃影响整个浏览器

安全性和沙箱：操作系统提供了限制进程权限的方法，因此浏览器可以从某些功能中对某些进程进行沙箱处理。如任意访问文件

进程有自己的私有内存空间，可以拥有更多的内存。为了节省内存，Chrome限制了它可以启动的进程数量。限制因设备的内存和CPU功率而异，但当Chrome达到限制时，它会在一个进程中开始从同一站点运行多个选项卡

图片引自Mariko Kosaka的《Inside look at modern web browser》  

6. 服务化 - 节省更多内存

浏览器程序中相同的功能方法，正在将浏览器的每个部分作为一项服务运行，可以轻松拆分为不同进程或聚合成一个进程。   当Chrome在强大的硬件上运行时，它可能会将每个服务拆分为不同的流程，从而提供更高的稳定性，但如果它位于资源约束设备上，Chrome会将服务整合到一个流程中，从而节省内存占用。  

Android的平台上已经使用了类似的方法来整合流程以减少内存使用。

  图片引自Mariko Kosaka的《Inside look at modern web browser》  

7. 给Iframe分配单独渲染进程 - 站点隔离

站点隔离:因不同站点之间共享内存空间会存在同源策略绕过(Meltdown and Spectre)安全问题：https://blog.csdn.net/wlmnzf/article/details/79319509%22%20/t%20%22_blank 。因此为每个跨网站iframe运行单独的渲染器进程。  

站点隔离难点：从根本上改变iframe的通信方式，包括ctrl+F查找、打开devtools等需在不同渲染器进程访问。【重大版本】。

图片引自Mariko Kosaka的《Inside look at modern web browser》  

三、页面导航过程

1. 浏览器进程运行

多进程架构启动多个进程处理不同的任务。选项卡外部的所有内容都由浏览器进程处理（包含UI线程、网络线程、存储线程）。在地址栏输入url时，由浏览器进程的UI线程处理。

图片引自Mariko Kosaka的《Inside look at modern web browser》  

2. 处理输入

当用户开始输入地址栏时，UI线程需判断是搜索查询还是URL。  

查询：发送到搜索引擎

URL：请求URL的网站

3. 开始导航

用户点击进入时：  

有注册设置Service Worker从缓存加载页面，渲染进程中运行JavaScript代码，从缓存加载页面，无需请求网络

未设置Service Worker时：

1) UI线程启动网络调用以获取站点内容，选项卡加载转圈

2) 网络线程通过DNS查找域名对应IP及建立http连接

3) 网络线程接收处理301重定向头。网络线程与请求重定向的UI线程通信，启动另一个URL请求

Service Worker

Service Worker注册后，保留其范围为参考。当导航时，网络线程根据注册的范围检查域名，若url已注册Service Worker，UI线程找到渲染进程执行ServiceWorker代码，从缓存加载数据或从网络加载新资源。生命周期见：https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle   

导航预加载

如果ServiceWorker最终决定从网络请求数据，浏览器进程与渲染进程间的往返可能导致延时，通过与ServiceWorker启动并行加载资源加速来减少延时，允许标记这些请求，允许服务器决定为这些请求发送不同的内容。

图片引自上面ServiceWorker的生命周期  

4. 读取响应结果

4.1 确定文件MIME类型

网络线程查看流的前几个字节，响应头中Content-Type头确定MIME数据类型。因此数据可能丢失，因此用MIME嗅探方式来查看资源。https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types   

4.2 处理不同MIME文件

响应文件是HTML，则将数据传递给渲染器进程。如果为.zip或其他文件则将数据传递给下载管理器。  

4.3 安全检查

恶意名单检查：如果域和响应数据在恶意站点名单中，则网络线程发出和显示警告页面。

跨域读取检查：CrossOriginReadBlock检查，敏感的跨站点数据不进入渲染器进程

5. 查找渲染进程

所有检查完成后，网络线程告知UI线程数据已准备就绪，UI线程找到渲染进程以继续渲染网页。   由于网络请求可能需要几百毫秒才能得到响应，为加速此过程，在开始导航网络线程发送url请求时，已经主动进行查找、启动渲染进程，数据接收完成后，渲染进程已备用。  

6. 提交导航

现在数据和渲染器进程已准备就绪，IPC将从浏览器进程发送到渲染进程以提交导航。渲染进程确认提交完成，导航完成。文档加载开始。   1、UI更新：地址栏更新、安全指示器、站点设置UI会反映新页面站点信息   2、选项卡的会话历史记录更新(前进/后退)，为便于关闭浏览器后恢复，历史记录到磁盘  

7. 初始化 load complete

提交导航后，渲染器进程将继续加载资源并呈现页面，一旦渲染器进程“完成”（onload事件在所有帧上触发执行完成后）渲染，它就会将IPC发送回浏览器进程。   UI线程停止选项卡的加载转圈。  

8. 导航到其他站点

导航完成后，再次将不同的URL放到地址栏导航，浏览器会检查当前渲染网站的beforeunload事件。如有设置导航或关闭选项卡时发出警报“离开这个网站吗？” 包含JavaScript代码的选项卡内的所有内容都由渲染进程处理。    

渲染进程导航操作   单击链接或客户端JavaScript已运行window.location = “https://newsite.com“ ，过程与流程器进程启动导航过程相同，不同点在于导航请求是从渲染进程启动到浏览器进程。

页面生命周期：https://developers.google.com/web/updates/2018/07/page-lifecycle-api#overview_of_page_lifecycle_states_and_events 

图片引自上面的页面生命周期    

四、页面渲染

1. 渲染进程处理页面内容

渲染进程负责选项卡内发生的所有事情。在渲染器进程中  

主线程：处理您发送给用户的大部分代码。

工作线程：处理WebWorker或ServiceWorker

排版线程：Compositor

栅格线程

图片引自Mariko Kosaka的《Inside look at modern web browser》  

2. 解析

2.1 构建DOM

当渲染进程接收提交的导航消息和HTML数据，主线程开始解析文本串（HTML），使之成为一个DOM。解析中遇到html能优雅容错。  

DOM：浏览器页面内部表示，提供给开发人员通过JS与DOM交互的数据结构和API。

图片引自Mariko Kosaka的《Inside look at modern web browser》  

2.2 子资源加载

网站通常使用图像，CSS和JavaScript等外部资源，需要从网络或缓存加载。在解析构建DOM时，主线程可以逐个请求它们。为了加快速度“预加载扫描器”同时运行。  

2.3 JavaScript阻塞解析

当遇到