关于javascript:web浏览器的工作原理

6次阅读

共计 7807 个字符，预计需要花费 20 分钟才能阅读完成。

中央处理器 (CPU)，中央处理器能够被认为是计算机的大脑。
图形处理单元 (GPU) 是计算机的另一部分。与 CPU 不同，GPU 善于解决简略的工作，但同时跨多个核。顾名思义，它最后是为解决图形而开发的。这就是为什么在图形环境中，“应用 GPU”或“反对 GPU”与疾速渲染和平滑交互相干。近年来，随着 GPU 减速计算，越来越多的计算能够独自应用 GPU 进行。

一个好的程序经常被划分为几个互相独立又彼此配合的模块，浏览器也是如此，以 Chrome 为例，它由多个过程组成，每个过程都有本人外围的职责，它们相互配合实现浏览器的整体性能，每个过程中又蕴含多个线程，一个过程内的多个线程也会协同工作，配合实现所在过程的职责。

过程就像是一个有边界的生产厂间，而线程就像是厂间内的一个个员工，能够本人做本人的事件，也能够相互配合做同一件事件。

当咱们启动一个利用，计算机会创立一个过程，操作系统会为过程调配一部分内存，利用的所有状态都会保留在这块内存中，利用兴许还会创立多个线程来辅助工作，这些线程能够共享这部分内存中的数据。如果利用敞开，过程会被终结，操作系统会开释相干内存。

过程能够要求操作系统启动另一个过程来运行不同的工作。当这种状况产生时，将为新过程分配内存的不同局部。如果两个过程须要通信，它们能够通过应用过程间通信 IPC(Inter Process Communication)来实现。许多应用程序都会设计成这样工作，这样当一个工作过程失去响应时，它能够重新启动，而不会进行运行应用程序的不同局部的其余过程工作。

不同浏览器的架构模型
不同浏览器采纳了不同的架构模式，这里并不存在规范，本文以 Chrome 为例进行阐明：
Chrome 采纳多过程架构，其顶层存在一个 Browser process 用以协调浏览器的其它过程。

1、Browser Process：~~~~

负责包含地址栏，书签栏，后退后退按钮等局部的工作；
负责解决浏览器的一些不可见的底层操作，比方网络申请和文件拜访；

2、Renderer Process：

负责一个 tab 内对于网页出现的所有事件

3、Plugin Process：

负责管制一个网页用到的所有插件，如 flash

4、GPU Process

负责解决 GPU 相干的工作

咱们晓得浏览器 Tab 外的工作次要由 Browser Process 掌控，Browser Process 又对这些工作进一步划分，应用不同线程进行解决：

UI thread：管制浏览器上的按钮及输入框；
network thread: 解决网络申请，从网上获取数据；
会执行 DNS 查问，随后为申请建设 TLS 连贯
storage thread: 管制文件等的拜访；

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

回到咱们的问题，当咱们在浏览器地址栏中输出文字，并点击回车取得页面内容的过程在浏览器看来能够分为以下几步：

解决输出

UI thread 须要判断用户输出的是 URL 还是 query；

2. 开始导航

当用户点击回车键，UI thread 告诉 network thread 获取网页内容，并管制 tab 上的 spinner 展示，示意正在加载中。

network thread 会执行 DNS 查问，随后为申请建设 TLS 连贯

UI thread 告诉 Network thread 加载相干信息

如果 network thread 接管到了重定向申请头如 301，network thread 会告诉 UI thread 服务器要求重定向，之后，另外一个 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 查找相干的渲染过程

因为网络申请获取响应须要工夫，这里其实还存在着一个减速计划。当 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](https://link.zhihu.com/?target=http%3A//newsite.com/)" ）renderer process 会首先查看是否有 beforeunload 事件处理器，导航申请由 renderer process 传递给 Browser process

如果导航到新的网站，会启用一个新的 render process 来解决新页面的渲染，老的过程会留下来解决相似 unload 等事件。

对于页面的生命周期，更多内容可参考 Page Lifecycle API。

浏览器过程发送 IPC 音讯到新的渲染过程告诉渲染新的页面，同时告诉旧的渲染过程卸载

除了上述流程，有些页面还领有 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 的更多内容可参考 The Service Worker Lifecycle

如果 Service Worker 最终决定通过网上获取数据，Browser 过程和 renderer 过程的交互其实会延后数据的申请工夫。Navigation Preload 是一种与 Service Worker 并行的减速加载资源的机制，服务端通过申请头能够辨认这类申请，而做出相应的解决。

渲染过程简直负责 Tab 内的所有事件，渲染过程的外围目标在于转换 HTML CSS JS 为用户可交互的 web 页面。渲染过程中次要蕴含以下线程：

渲染过程蕴含的线程
主线程 Main thread
工作线程 Worker thread
排版线程 Compositor thread
光栅线程 Raster thread
后文咱们将逐渐介绍不同线程的职责，在此之前咱们先看看渲染的流程

构建 DOM
当渲染过程接管到导航的确认信息，开始承受 HTML 数据时，主线程会解析文本字符串为 DOM。

渲染 html 为 DOM 的办法由 HTML Standard 定义。

加载次级的资源

网页中经常蕴含诸如图片，CSS，JS 等额定的资源，这些资源须要从网络上或者 cache 中获取。主过程能够在构建 DOM 的过程中会逐个申请它们，为了减速 preload scanner 会同时运行，如果在 html 中存在 <img> <link> 等标签，preload scanner 会把这些申请传递给 Browser process 中的 network thread 进行相干资源的下载。

JS 的下载与执行

当遇到 <script> 标签时，渲染过程会进行解析 HTML，而去加载，解析和执行 JS 代码，进行解析 html 的起因在于 JS 可能会扭转 DOM 的构造（应用诸如 document.write()等 API）。

不过开发者其实也有多种形式来告知浏览器应答如何应答某个资源，比如说如果在<script> 标签上增加了 async 或 defer 等属性，浏览器会异步的加载和执行 JS 代码，而不会阻塞渲染。更多的办法可参考 Resource Prioritization – Getting the Browser to Help You

款式计算

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

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

获取布局

想要渲染一个残缺的页面，除了获知每个节点的具体款式，还须要获知每一个节点在页面上的地位，布局其实是找到所有元素的几何关系的过程。其具体过程如下：

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

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

绘制各元素

即便晓得了不同元素的地位及款式信息，咱们还须要晓得不同元素的绘制先后顺序能力正确绘制出整个页面。在绘制阶段，主线程会遍历布局树以创立绘制记录。绘制记录能够看做是记录各元素绘制先后顺序的笔记。

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

合成帧

相熟 PS 等绘图软件的童鞋必定对图层这一概念不生疏，古代 Chrome 其实利用了这一概念来组合不同的层。

复合是一种宰割页面为不同的层，并独自栅格化，随后组合为帧的技术。不同层的组合由 compositor 线程（合成器线程）实现。

主线程会遍历布局树来创立层树（layer tree），增加了 will-change CSS 属性的元素，会被看做独自的一层，

主线程遍历布局树生成层树
你可能会想给每一个元素都增加上 will-change，不过组合过多的层兴许会比在每一帧都栅格化页面中的某些小局部更慢。为了更正当的应用层，可参考保持仅合成器的属性和管理层计数。

一旦层树被创立，渲染程序被确定，主线程会把这些信息告诉给合成器线程，合成器线程会栅格化每一层。有的层的能够达到整个页面的大小，因而，合成器线程将它们分成多个磁贴，并将每个磁贴发送到栅格线程，栅格线程会栅格化每一个磁贴并存储在 GPU 显存中。

栅格线程会栅格化每一个磁贴并存储在 GPU 显存中
一旦磁贴被光栅化，合成器线程会收集称为绘制四边形的磁贴信息以创立合成帧。

合成帧随后会通过 IPC 消息传递给浏览器过程，因为浏览器的 UI 扭转或者其它拓展的渲染过程也能够增加合成帧，这些合成帧会被传递给 GPU 用以展现在屏幕上，如果滚动产生，合成器线程会创立另一个合成帧发送给 GPU。

合成器线程会发送合成帧给 GPU 渲染
合成器的长处在于，其工作无关主线程，合成器线程不须要期待款式计算或者 JS 执行，这就是为什么合成器相干的动画最晦涩，如果某个动画波及到布局或者绘制的调整，就会波及到主线程的从新计算，天然会慢很多。

浏览器通过对不同事件的解决来满足各种交互需要，这一部分咱们一起看看从浏览器的视角，事件是什么，在此咱们先次要思考鼠标事件。

在浏览器的看来，用户的所有手势都是输出，鼠标滚动，悬置，点击等等都是。

当用户在屏幕上触发诸如 touch 等手势时，首先收到手势信息的是 Browser process，不过 Browser process 只会感知到在哪里产生了手势，对 tab 内内容的解决是还是由渲染过程管制的。

事件产生时，浏览器过程会发送事件类型及相应的坐标给渲染过程，渲染过程随后找到事件对象并执行所有绑定在其上的相干事件处理函数。

事件从浏览器过程传送给渲染过程

前文中，咱们提到过合成器能够独立于主线程之外通过合成栅格化层平滑的解决滚动。如果页面中没有绑定相干事件，组合器线程能够独立于主线程创立组合帧。如果页面绑定了相干事件处理器，主线程就不得不进去工作了。这时候合成器线程会怎么解决呢？

这里波及到一个专业名词「了解非疾速滚动区域（non-fast scrollable region）」因为执行 JS 是主线程的工作，当页面合成时，合成器线程会标记页面中绑定有事件处理器的区域为 non-fast scrollable region，如果存在这个标注，合成器线程会把产生在此处的事件发送给主线程，如果事件不是产生在这些区域，合成器线程则会间接合成新的帧而不必等到主线程的响应。

波及 non-fast scrollable region 的事件，合成器线程会告诉主线程进行相干解决

web 开发中罕用的事件处理模式是事件委托，基于事件冒泡，咱们经常在最顶层绑定事件：

document.body.addEventListener('touchstart',  event => {if (event.target === area) {event.preventDefault();
    }
} );

上述做法很常见，然而如果从浏览器的角度看，整个页面都成了 non-fast scrollable region 了。

这意味着即便操作的是页面无绑定事件处理器的区域，每次输出时，合成器线程也须要和主线程通信并期待反馈，晦涩的合成器独立解决合成帧的模式就生效了。

因为事件绑定在最顶部，整个页面都成为了 non-fast scrollable region

为了避免这种状况，咱们能够为事件处理器传递 passive: true 做为参数，这样写就能让浏览器即监听相干事件，又让组合器线程在等等主线程响应前构建新的组合帧。

document.body.addEventListener('touchstart',  event => {if (event.target === area) {event.preventDefault()
    }
 }, {passive: true} );

不过上述写法可能又会带来另外一个问题，假如某个区域你只想要程度滚动，应用 passive: true 能够实现平滑滚动，然而垂直方向的滚动可能会先于 event.preventDefault() 产生，此时能够通过 event.cancelable 来避免这种状况。

document.body.addEventListener('pointermove', event => {if (event.cancelable) {event.preventDefault(); // block the native scroll         /*
 *  do what you want the application to do here */
    } 
}, {passive: true});

也能够应用 css 属性 touch-action 来齐全打消事件处理器的影响，如：

#area {touch-action: pan-x;}

查找到事件对象

当组合器线程发送输出事件给主线程时，主线程首先会进行命中测试（hit test）来查找对应的事件指标，命中测试会基于渲染过程中生成的绘制记录（paint records）查找事件产生坐标下存在的元素。

主线程根据绘制记录查找事件相干元素

事件的优化

个别咱们屏幕的刷新速率为 60fps，然而某些事件的触发量会不止这个值，出于优化的目标，Chrome 会合并间断的事件(如 wheel, mousewheel, mousemove, pointermove, touchmove)，并提早到下一帧渲染时候执行。

而如 keydown, keyup, mouseup, mousedown, touchstart, 和 touchend 等非连续性事件则会立刻被触发。

Chrome 会合并间断事件到下一帧触发

合并事件尽管能提示性能，然而如果你的利用是绘画等，则很难绘制一条平滑的曲线了，此时能够应用 getCoalescedEvents API 来获取组合的事件。示例代码如下：

window.addEventListener('pointermove', event => {const events = event.getCoalescedEvents();
    for (let event of events) {
        const x = event.pageX;
        const y = event.pageY;
        // draw a line using x and y coordinates.     }
});

通过 getCoalescedEvents API 获取到每一个事件

Inside look at modern web browser

图解浏览器的根本工作原理

JavaScript 中的事件循环与音讯队列

正文完

javascript

发表至： javascript

2021-03-23

0

关于javascript:为什么那么多前端都选择用-Vuejs框架

Vue原理响应式原理-白话版

关于javascript:SAP-UI5-batch-请求的响应解析流程分析

javascript的call apply和new原理剖析 [手写]

关于python:SkipList跳表

关于javascript:web浏览器的工作原理

CPU、GPU、内存、多过程架构

1、CPU 和 GPU

2、浏览器的多过程架构

过程（process）和线程（thread）

浏览器的架构

在浏览器中输出 URL

渲染过程是如何工作的

浏览器对事件的解决

参考链接

站内搜索