当在浏览器键入URL后会发生哪些事情(浏览器篇)?

2019/10/10 92

这是一个面试题,所考察的知识点是非常多了,这篇文章主要收集浏览器做了什么。

浏览器

当用户输完 URL 后,会交由浏览器这个程序来处理,所以第一个必须先说下浏览器。

一个高效的、稳定的程序往往被划分成几个相互独立而彼此又相互配合的模块,浏览器也是如此,以 Chrome 为例,它由多个进程组成,每个进程都有自己的核心职责,它们相互配合完成浏览器的整体功能,每个进程中又包含多个线程,一个进程内的多个线程也会协同工作,配合完成所在进程的职责。

不同的浏览器采用了不同的进程架构,这里并不存在标准,本文已 Chrome 为例进行说明。 Chrome 采用多进程架构,其顶层存在一个 Browser process 用以协调浏览器的其它进程。具体来说,Chrome 的主要进程及职责如下:

Browser Process

Renderer Process

Plugin Process

GPU Process

不同进程负责的浏览器区域示意图

导航过程发生了什么

介绍完了浏览器的基本架构模式,接下来我们看看一个常见的导航过程对浏览器来说究竟发生了什么?

我们知道浏览器 Tab 外的工作主要有 Browser Process 掌控, Browser Process 又对这些工作进一步划分,使用不同线程进行处理:

浏览器主进程中的不同线程

回到我们的问题,当我们在浏览器地址栏中输入文字,并点击回车获得页面内容的过程在浏览器看来可以分为以下几步:

1.处理输入

UI thread 需要判断用户输入的是否输入的是 http/https 协议,如果是 http/https 协议的地址,则分析 Host、Port、Path、Query

2.开始导航

当用户点击回车键,UI thread 通知 network thread 获取网页内容,并控制 tab 上的 spinner(旋转器) 展现,此时就是“正在加载中...”。

network thread 会执行 DNS 查询,随后为请求建立 TLS 连接。

UI thread 通知 Network thread 加载相关信息

如果 network thread 接收到了重定向请求,network thread 会通知 UI thread 服务器要求重定向,之后,会根据 Location Header 的 URL 进行重定向。

3.读取响应

当响应返回后,network thread 会根据 Content-Type 及 MIME Type sniffing 判断响应内容的格式。

判断响应内容的格式

如果响应内容的格式是 HTML,下一步将会将这些数据传递给 renderer process,如果是 zip 等文件,会把相关数据传输给下载器。

Safe Browsing 检查也会在此时触发,如果域名或者请求内容匹配到已知的恶意站点,network thread 会展示一个警告页。此外 CORB 检查也会触发确保敏感数据不会被传递给渲染进程。

读取响应

4.查找渲染进程

当上述所有检查完成,network thread 确信浏览器可以导航到请求网页,network thread 会通知 UI thread 数据已准备好了,UI thread 会查找到一个 renderer process 进行网页的渲染。

收到 Network thread 返回的数据后,UI thread 查找相关的渲染进程

收到 network thread 返回的数据后,UI thread 查找相关的渲染进程

由于网络请求获取响应需要时间,这里其实还存在着一个加速方案。当 UI thread 发送 URL 请求给 network thread 时,浏览器其实已经知道要导航到哪个站点。UI thread 会并行的预先查找和启动一个渲染进程,如果一切正常,当 network thread 接收到数据时,渲染进程已经准备就绪了,但是如果遇到重定向,准备好的进程也许就不需要了,这时候需要重启一个新的渲染进程

5.确认导航

经过了上述过程,数据以及渲染进程都可用了,browser process 会给 renderer process 发送 IPC 消息来确认导航,一旦 browser process 收到 renderer process 的渲染确认消息,导航过程结束,页面加载过程开始。

此时,地址栏会更新,展示出新页面的网页信息。history tab 会更新,可通过返回键返回导航来的页面,为了让关闭 tab 或窗口便于恢复,这些信息会存放在硬盘中。

Browser Process 和 Renderer Process 通过 IPC 通信,请求 Renderer Process 渲染页面

6.额外的步骤

一旦导航被确认,renderer process 会使用相关的资源渲染页面,下文中我们将重点介绍渲染流程。当 renderer process 渲染结束(渲染结束意味着该页面内所有的页面,包括所有的 iframe 都出发了 onload 后),会发送 IPC 信号到 browser process,UI thread 会停止展示 tab 中的 spinner

Renderer Process 发送 IPC 消息通知 browser process 页面已经加载完成。

当然上面的流程知识网页首帧渲染完成,在此之后,客户端依旧可下载额外的资源渲染出新的视图。

在这里我们可以明确一点,所有的 JS 代码知识都由 renderer process 控制的,所以在你浏览网页内容的过程大部分时候不会涉及到其它的进程。不过也许你也曾经监听过 beforeunload 事件,这个事件再次涉及到 browser process 和 renderer process 的交互,当前页面关闭时(关闭 tab,刷新等)browser process 需要通知 renderer process 进行相关的检查,对相关事件进行处理。

浏览器进程发送 IPC 消息给渲染进程,通知要离开当前网站了

如果导航由 renderer process 触发(比如在用户点击某链接,或者 JS 执行了 window.location = "http://newsite.com")renderer process 会首先检查是否有 beforeunload事件处理器,导航请求由 renderer process 传递给 browser process

如果导航到新的网站,会启用一个新的 renderer process 来处理新页面的渲染,老的进程会留下来处理类似unload等事件。

除了上述流程,有些页面还拥有 Service Worker,Service Worker 让开发者对本地缓存及判断何时从网络上获取信息有了更多的控制权,如果 Service Worker 被设置为从本地 cache 中加载数据,那么就没有必要从网上获取更多数据了。

值得注意的是 Service Worker 也是运行在渲染进程中的 JS 代码,因此对于拥有 Service Worker 的页面,上述流程有些许不同。

当有 Service Worker 被注册时,其作用域会被保存,当有导航时,network thread 会在注册过的 Service Worker 的做用户中检查相关域名,如果存在对应的 Service Worker,UI thread 会找到一个 renderer process 来处理相关代码,Service Worker 可能会从 cache 中加载数据,从而终止对网络的请求,也可能从网上请求新的数据。

Service Worker 依据具体情形做处理

如果 Service Worker 最终决定通过网上获取数据,browser process 和 renderer process 的教会其实会延后数据的请求时间。Navigation Preload 是一种与 Service Worker 并行的加速加载资源的机制,服务端通过请求头可以识别这类请求,而做出响应的处理。

渲染进程是如何工作的

渲染进程几乎负责 Tab 内的所有事情,渲染进程的核心目的在于转换 HTML CSS JS 为用户可交互的 web 页面。渲染金钟主要包含以下进程:

渲染进程包含的线程

  1. 主线程 Main thread
  2. 工作线程 Worker thread
  3. 排版线程 Compositor thread
  4. 光栅线程 Raster thread

后文我们将逐步介绍不同线程的职责,在此之前我们先看看渲染进程的流程

1.构建 DOM

当渲染进程收到导航的确认信息后,开始接收 HTML 数据时,主线程会解析文本字符串为 DOM。

渲染 HTML 为 DOM 的方法由 HTML Standard 定义

2.加载次级资源

网页中常常包含诸如图片,CSS,JS等额外的资源,这些资源需要从网络上或者 cache 中获取。主进程可以在构建 DOM 的过程中注意请求它们,为了加速 preload scanner 会同时运行,如果 HTML 中存在 <img/> <link/> 等标签,preload scanner 会把这些请求传递给 browser process 中的 network thread 进行相关资源的下载。

3.JS 的下载与执行

当遇到 <script/> 标签时,渲染进程会停止解析 HTML,而去加载,解析和执行 JS 代码,停止解析 HTML 的原因在于 JS 可能会改变 DOM 结构(注入使用document.write()等API)。

不过开发者其实也有多种方式来告诉浏览器应如何加载某个资源,如果在<script/>标签上添加了asyncdefer等属性,浏览器会异步加载和执行 JS 代码,而不会阻塞渲染。

4.样式计算

仅仅渲染 DOM 还不足以获知页面的具体样子,主进程还会基于 CSS 选择器解析 CSS 获取每一个节点的最终的计算样式值。即使不提供任何 CSS,浏览器对每个元素也会有一个默认的样式。

渲染进程主线程计算每一个元素节点的最终样式值

5.获取布局

想要渲染一个完整的页面,除了获知每个节点的具体样式,还需要获知每一个节点上的页面上的未知,布局其实是找到所有元素的几何关系的过程。其具体过程如下:

通过遍历 DOM 及相关元素的计算样式,主线程会构建出包含每个元素的坐标信息及盒子大小的布局树。布局树和 DOM 树类似,但是其中只包含页面可见的元素,如果一个元素设置了 display:none,这个元素不会出现在布局树上,伪元素虽然在 DOM 树上不可见,但是在布局树上是可见的。

主线程遍历 DOM 及 对应元素的样式,构建出布局树

6.绘制各元素

即使知道了不同元素的位置及样式信息,我们还需要知道不同元素的绘制先后顺序才能正确绘制出整个页面。在绘制阶段,主线程会遍历布局树以创建绘制记录。绘制记录可以看做是记录个元素绘制先后顺序的笔记。

主线程依据布局树构建绘制记录

7.合成帧

熟悉 PS 等绘图软件的童鞋肯定对图层这一概念不陌生,现在 Chrome 其实也利用了这一概念来组合不同的层。

复合是一种分割页面为不同层,并单独栅格化,随后组合为帧的技术。不同层的组合由 compositor 线程(合成器线程)完成。

主线程会遍历布局树来创建层树(layer tree),添加了 will-change CSS 属性的元素,会被看作单独的一层

主线程遍历布局树生成层树

你可能会想给每一个元素都添加上 will-change,不过组合过多的层也许会比在每一帧都栅格化页面中的某个小部分更慢。请合理的使用层。

一旦 layer tree 被创建,渲染顺序被确定,主线程会把这些信息通知给合成器线程,合成器线程会栅格化每一层。有的层可以达到整个页面的大小,因此,合成器线程将它们分成多个磁铁,并将每个此贴发送到栅格线程,栅格线程会栅格化每一个磁铁并存储在 GPU 显存中。

栅格线程会栅格化每一个磁贴并存储在 GPU 显存中

一旦磁铁被栅格化,合成器线程会收集称为绘制四边形的磁铁信息以创建合成帧。

合成帧随后会通过 IPC 消息传递给浏览器进程,由于浏览器的 UI 改变或者其它拓展的渲染进程也可以添加合成帧,这些合成帧会被传递给 GPU 用以展示在屏幕上,如果滚动发生,合成器线程会创建另一个合成帧发送给 GPU。

合成器的优点在于,其工作与主线程无关,合成器线程不需要等待样式计算或者 JS 执行,这就是为什么合成器相关的动画最流畅,如果某个动画涉及到布局或者绘制的调整,就会涉及到主线程的重新计算,自然会慢很多。

摘抄自 知乎专栏

评论