• 者: 阿吉

• 校对&整理: 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浏览器架构

（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 解析。这就是浏览器的多线程架构。

JS async defer

总结一下，多线程的好处就是，高响应度，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 指出修改)

大家也可以关注我的公众号《脑洞前端》获取更多更新鲜的前端硬核文章，带你认识你不知道的前端。

读

目前，在两大主流移动智能操作系统iOS和Android上，默认的浏览器内核都是WebKit，而且分别以Framework的方式推出了UIWebKit和WebView组件，使得第三方开发者可以据此构建自己的浏览器或使用Web技术展现内容的各种复杂应用。

近日，Safari 15.4为WebKit添加了70多个新增功能，其中包含新的Web技术、更新和修复，这也是在2022年推出的第一个大型WebKit版本。Safari 15.4目前适用于macOS Monterey 12.3、iPadOS和iOS 15.4。具体新增特性如下：

HTML

WebKit通过<img>元素的加载（loading）属性添加了对延迟加载图像的支持，为Web开发人员提供了一种简单的方法来指示浏览器延迟加载的某些图像。

经过多年关于可访问性标准化的辩论，如今终于有了解决方案，WebKit增加了对<dialog>元素和：：Background伪元素的支持。<dialog>元素提供了一种强大的方法来创建覆盖和模态。

WebKit还增加了对全局自动聚焦属性的支持，允许开发人员在页面加载或显示<对话框>时指示哪个元素应该是焦点。

CSS

（1）CSS架构的特性

2022年CSS的新增功能为Web开发人员构建代码提供了革命性的新方法，使代码重用、创建设计系统以及与复杂应用程序集成变得更加容易。 首先，登陆Safari，WebKit添加了对:has()伪类的支持。这个选择器满足了人们长期以来对“父选择器”的渴望（这是一种基于元素内容有条件地应用CSS规则的方法）。长期以来，人们一直认为采用这样的选择器是不可能的，但WebKit团队找到了一种高度优化性能的方法，并提供了一种不会降低页面速度的灵活解决方案。 WebKit增加了对级联层（Cascade Layers）的支持，这是一种将样式组织到层中的强大方法，可以在每个层内独立计算特异性。

Web开发人员可以创建一个“框架”层和一个“自定义”层——将所有CSS从第三方框架分配到“框架”层，并在“自定义”层中编写自己的代码。他们可以指定自定义层中的所有内容都应该优于框架层中的所有内容，无论每个层中使用的选择器的特殊性如何。级联层几乎同时出现在所有主要浏览器中，并包含在Interop 2022中，这让它成为未来Web开发人员会重视的工具。

WebKit还通过contains属性添加了对CSS Containment的支持——所有四种类型：大小、布局、样式和绘制。

（2）附加功能

Web开发人员非常需要一种类似于现有视口单元，但能在移动设备上工作得更好的工具，因为在移动设备上，随着用户滑动页面，浏览器视口的尺寸会发生变化。

新的视口单元就是这种解决方案。100svh是指可能的最小视口高度的100%，100lvh是指最大可能视口高度的100%。100dvh指的是动态视口高度的100%——这意味着该值将随着用户滑动移动设备的屏幕而改变。

还有其他新的视口单元——svw、lvw和dvw在宽度方面也有相同的用途。为了涵盖vmin和vmax的小型、大型和动态版本，svmin、svmax、lvmin、lvmax、dvmin和dvmax单元也要实现。为了支持逻辑维度，新的vi和vb在视口内联维度和视口块维度上与现有视口单元类似。svi、svb、lvi、lvb、dvi和dvb为小型、大型和动态版本的内联维度和块维度提供逻辑维度单元。

WebKit增加了对：focus visible伪类的支持，以仅在浏览器呈现焦点指示器时设置其样式。

为了使原生表单控件更具可定制性，accent-color属性为Web开发人员提供了一种更改表单控件用户属性（UI）特定部分颜色的方法。在macOS、iPadOS和iOS上，<input type="checkbox">、<input type="radio">、<progress>、<select>和带有<datalist>的文本输入类型支持强调色。此外，在iPadOS和iOS上，<input type="range">、<button>和<input type="button">支持强调色。

WebKit修复了具有alpha透明度的颜色之间插值的错误，改进了渐变支持。

此外，WebKit还添加了对calc()数学函数的支持，包括sin、cos、tan、e、pi、exp、log、atan、acos、asin和atan2。

（3）排版

Safari15.4中增添的几个新WebKit功能丰富了Web排版的可能性。

WebKit添加了对字体调色板CSS属性和@font-palette-values规则的支持。

font-palette属性为Web开发人员提供了一种方法，可以选择包含在彩色字体中的几个不同的预定义调色板中的一个。例如，声明字体的深色调色板用于网站的深色模式设计。@font-palette-values规则为Web开发人员提供了一种定义自己的自定义调色板的方法，用于重新设置彩色字体的颜色。

用于放大的大写字母的颜色字体是Bradley Initials DJR Web，此处显示的是其默认调色板、由Web开发人员创建的自定义调色板、包含在字体中的替代调色板，并且根据用户的喜好移除了一些颜色。

WebKit添加了对text-decoration-skip-ink的支持，以控制下划线和上划线在通过字形上升和下降时呈现的形式。WebKit之前通过text-decoration-skip支持这一排版功能，但由于尚无其他浏览器支持short-hand，WebKit对long-hand的支持将更容易取消下划线和上划线。

此外，WebKit添加了对ic单元的支持，在排版CJK脚本时很有用。

（4）停用WebKit前缀

为了减少对前缀的依赖，WebKit新支持了几个CSS属性和值，这些属性和值仅在早期形式中可用。带前缀的版本仍然有效，现在别名为无前缀的版本。Safari15.4添加了对以下内容的支持：

外观，包括自动呈现

• mask，以及常用形式mask-image、mask-size、mask-repeat-x、mask-repeat-y、mask-origin
• 背面可见性
• 垂直组合文本
• 打印颜色调整
• text-align属性的父CSS值

WebKit还删除了非标准CSS属性：-WebKit边框拟合、-WebKit页边距折叠、-WebKit页边距顶部折叠、-WebKit页边距底部折叠、-WebKit折叠前页边距、-WebKit折叠后页边距以及-WebKit背景合成。

Web API

Web API是Web的应用程序编程接口，它可以扩展浏览器的功能，简化复杂的功能，为复杂的代码提供简单的语法。所有浏览器都有一组内置的 Web API 来支持复杂的操作，并帮助访问数据。

Safari 15.4包括对WebKit中Web API的许多升级，以帮助Web开发人员提供更好的用户体验。

对BroadcastChannel的支持允许来自源的选项卡、窗口、iframe和Worker相互发送消息。这可以实现跨多个选项卡同步站点的登录状态等体验。

WebKit支持的另一个新机制是Web Locks API，它可以从选项卡、窗口、iFrame和Worker中的源节点作为异步锁定控件来管理对资源的访问。

开发人员还可以使用CSS滚动行为属性或JavaScript中window.scroll()、window.scrollTo()和window.scrollBy()方法中的行为选项来控制元素的滚动行为。

这种新的支持使开发人员能够在立即跳转到视口中的某个位置或平滑地为滚动操作设置动画之间进行选择。

ResizeObserver API更新了对ResizeObserverEntry使用的ResizeObserverSize接口的支持，以帮助开发人员观察元素的元素框大小属性的变化。

StructuredClone(value)的添加提供了一个实用程序，该实用程序使用结构化克隆算法同步执行深度复制，以克隆和传输输入值中的对象。

WebKit对文件系统访问API和Origin Private File System的支持首先在Safari15.2中发布。Safari15.4在FileSystemFileHandle中引入了getFile()方法，可以更方便地从文件系统中读取文件。此外，WebKit更新了WriteableStream以使用文件系统访问API。

JavaScript

此次，JavaScript的新功能和更新为开发人员带来了更多便利。其方便的新数组功能使得使用findLast()和findLastIndex()方法从数组末尾开始搜索变得更好。这些方法可帮助开发人员避免需要首先使用reverse()来改变数组的典型方法。

另外，JavaScript还支持at()方法访问指定整数索引处的条目，特别是支持使用负整数从数组末尾开始。

let list = ['banana','cherry','orange','apple','kiwi'];

// Instead of this:

console.log(list[list.length-2]);

// It's as easy as:

console.log(list.at(-2));

新的语言工具对象Object.hasOwn()简化了检测对象何时具有属性本身，即未继承或不存在的属性。

国际化

随着标准流程定义了更多的国际化特性，WebKit继续定期更新其Intl实现。最新版本包括使用Intl Enumeration API识别本地时区、排序规则、日历、编号系统和货币的支持值。

更新到V2的Intl.Locale公开了新信息，其中包括日历周数据（例如一周的第一天）、文本信息（例如书写方向）以及其他区域相关的默认值（例如日历、12小时或24小时周期），以及编号系统。

WebKit还将Intl.DisplayNames更新到V2，添加了对日历和dateTimeField名称以及语言显示选项的支持。

添加到Intl.PluralRules的selectRange()方法为范围（例如0-1项）提供了区域设置正确的复数形式。Intl.NumberFormat V3更新添加了formatRange()和formatRangetoParts()方法，用于使用区域设置感知约定以及新的useGrouping、roundingPriority、roundingIncrement、trailingZeroDisplay和signDisplay选项来格式化数字范围。

最后，Intl.DateTimeFormat包括对四个新的时区名称选项的支持：shortOffset、longOffset、shortGeneric和longGeneric。

Web应用程序

对Web App Manifest和ServiceWorker的更新，改进了Safari中网站的用户体验，以及iOS和iPadOS上主屏幕上保存的Web应用程序。 Web App Manifest改进包括确保浏览器始终在页面加载期间获取清单文件，而不是在用户从“共享”菜单中选择“添加到主屏幕”。这种方法提高了可靠性，并且还允许清单文件定义Safari中网页的特征。 此外，现在支持在Web应用清单文件中声明图标。当HTML头部中没有定义apple-touch-icon，并且用于声明图标的清单文件代码省略“目的”键或包含“目的”时，Safari和iOS使用清单声明的图标。使用apple-touch-icon定义图标优先于manifest声明的图标，以便为使用此技术为iOS定义特定图标的Web应用程序提供一致的行为，这与其他移动平台不同。 开发人员现在可以在ServiceWorker中启用导航预加载，以提高加载性能，并避免阻塞网络请求的ServiceWorker启动延迟。还有新的支持允许用户下载由ServiceWorker生成的文件。WebKit还提高了使用FormData和通过ServiceWorker的文件使用FormData文件的可靠性。

媒体

WebRTC协商API现在完全符合WebRTC 1.0规范，以支持WebRTC完美协商。这是一种解决在两个远程对等方在协商期间可能发生的潜在同步问题的方法。

WebKit添加了对音频和视频的带内章节轨道的支持。带内文本轨道在容器内为媒体本身提供字幕或章节标记信息，而不是在HTML中声明或注入JavaScript。以前的版本，已经支持像CEA-608这样的带内字幕轨道。现在，带内章节轨道也能获得支持，其中“提示”代表章节的开始时间和标题。

WebKit在<video>上添加了对requestVideoFrameCallback()的支持，当有新的视频帧可供显示时，它允许调用者得到通知，并提供有关该帧的元数据。

隐私

Safari 15.4继续致力于隐私保护，并进一步推动WebKit提出的以保护隐私的方式衡量广告的网络标准，它对隐私点击衡量提供了三个更新：

添加了通过不可链接的令牌来预防转化欺诈，以触发商家网站上的事件。

• 增加了对商户网站上相同站点转换像素的支持，以消除对跨站点像素的依赖。
• 允许测量发布商网站上嵌套的跨站点iframe中的链接。

安全

Safari 15.4中的WebKit改进了对Level 3级别的内容安全策略的支持，增强了对内容加载的安全控制，并帮助Web开发人员降低跨站点脚本和其他漏洞的风险。已经更新内联脚本、内联样式和eval执行的阻止资源冲突报告，以符合Web标准。

对“strict-dynamic”、“unsafe-hashes”和“report-sample”源表达式的新支持为开发人员提供了更大的灵活性。开发人员还可以使用对哈希源表达式的新支持，安全地在其页面中包含外部JavaScript。

该版本还删除了对XSS Auditor的支持，它已被CSP和COEP等现代跨域防御所取代。

WKWebView

使用WKWebView（包括iOS和iPadOS上的第三方浏览器）的开发人员可以利用新的WKPreferences进行额外的用户体验控制。iOS、iPadOS和macOS上的应用现在可以控制允许或阻止web内容使用全屏API。另一个新首选项允许启用或禁用特定于站点的杂项，这是一组旨在提高Web兼容性的特定于站点的行为。 在iPadOS上，使用媒体源扩展的Web内容现在可以在WKWebView中使用。

Safari网络扩展

在WebKit对扩展的跨浏览器互操作模型方面，Safari 15.4增加了对Web扩展的额外支持，包括对manifest_version3和相关API更改的支持。这些新功能包括：

• service_worker后台脚本作为非持久后台页面的替代方案。
• 通过browser.scripting API进行脚本和样式注入。
• 通过browser.declarativeNetRequest API的动态和会话规则。
• 使用externally_connectable:matches的网页到扩展消息。

并解决了几个问题，其中包括：

• 现在对扩展同步存储中的项目大小和数量实施了限制。
• 现在允许在扩展清单的content_security_policy中包含更多指令，例如沙盒指令。
• declarativeNetRequest规则的urlFilter中的特殊匹配字符（*、|、||和^）现在可以处理，而不是被视为正则表达式模式。
• 现在允许从runtime.onMessage侦听器返回的Promise用于消息回复。

Web Inspector

Web Inspector的更新，为在样式面板中处理CSS提供了有用的新工具，包括对级联层和新的@layer规则集的直观支持，从而可以轻松识别在哪个层中定义了规则。 当Flexbox和Grid使用align-content、align-items、align-self、justify-content、justify-items或justify-self时，还有新的CSS对齐控件可以直观地识别和选择理想值。 在样式面板中添加新属性或值时，Web Inspector提供了方便的自动完成选项。最新版本升级了自动完成，可以使用模糊匹配，从而更容易找到正确的选项。 当使用CSS自定义属性或更广为人知的CSS变量时，一种常见的做法是将它们添加到:root或html的选择器规则中。不幸的是，这会导致页面上的每个元素都有一长串继承的CSS变量。Web Inspector可以通过多种方式帮助用户处理此问题。首先，它会自动隐藏未使用的继承CSS变量。然后，当需要查看它们时，可以使用一个按钮将它们全部显示出来。还可以使用过滤器工具来搜索正确的CSS变量，或者可以在计算面板中查看按值类型分组的所有适用CSS变量，从而允许折叠与其任务不相关的组。

WebKit起源史

众所周知，WebKit是一个开源的浏览器排版引擎，其起源最早可追溯到始于1998年的KDE开源桌面环境项目的HTML Widget，后来进一步发展为KDE的标准组件、KHTML排版引擎和KJSJavaScript脚本引擎。

苹果公司为开发自主的Safari浏览器，在对比了Gecko和KHTML之后，毅然选择了后者。原因是相比Gecko的庞大臃肿，KHTML更加轻巧和清晰。苹果公司将KHTML更名为WebCore，KJS更名为JavaScriptCore，两者合起来作为WebKit。

2008年9月，谷歌公司推出了基于WebKit内核的Chrome浏览器，Chrome促成了浏览器技术的持续发展，WebKit也因此逐渐转入更多开发者的视界，影响力和知名度与日俱增。

来源：51CTO技术栈

作者：武穆、李睿