Skip to main content

概览

现代浏览器（以 Chrome 为例）早已不再是单进程架构，为了解决早期的不稳定（一个标签页崩溃导致整个浏览器挂掉）、不流畅（JS 执行阻塞页面渲染）以及不安全（恶意插件获取系统权限）等问题，Chrome 演进出了复杂的多进程架构。

多进程架构模型​

  • 浏览器主进程 (Browser Process)：大脑。负责界面展示（地址栏、前进后退）、用户交互、子进程管理，同时提供文件存储等功能。
  • 渲染进程 (Renderer Process)：心脏。核心任务是将 HTML/CSS/JS 转换为用户可以交互的网页。每个 Tab 标签页通常会创建一个独立的渲染进程（但如果从一个页面打开了同一站点的新页面，它们会复用同一个渲染进程，即 process-per-site-instance 策略）。出于安全考虑，渲染进程运行在沙箱（Sandbox）模式下，无法直接访问系统底层资源。
  • GPU 进程：初衷是为了实现 3D CSS 的硬件加速，后来 Chrome 的 UI 界面也都交给 GPU 来绘制了。
  • 网络进程 (Network Process)：负责页面的网络资源加载。之前是作为一个模块运行在浏览器主进程中，后来独立出来。
  • 插件进程：负责运行浏览器插件，同样运行在沙箱中，防止插件崩溃影响浏览器。

面试追问：渲染进程里有哪些核心线程？

  1. GUI 渲染线程：负责解析 HTML/CSS、构建 DOM 树和 Render 树、布局和绘制。与 JS 引擎线程互斥（当 JS 执行时，GUI 会被挂起，这也是产生 Long Task 导致页面卡顿的根本原因）。
  2. JS 引擎线程：大名鼎鼎的 V8 引擎就运行在这里，负责解析和执行 JavaScript 脚本。
  3. 事件触发线程：控制事件循环（Event Loop）。当遇到 setTimeout、Ajax 异步请求或 DOM 交互事件时，会将相应的回调函数放入任务队列，等待 JS 引擎空闲时执行。
  4. 定时触发器线程：setTimeout 和 setInterval 所在的线程。因为 JS 是单线程的，如果用 JS 引擎计时可能会因为阻塞导致不准，所以由单独的线程来计时并触发。
  5. 异步 HTTP 请求线程：XMLHttpRequest 或 fetch 请求发起后交由该线程处理。状态变更后，将回调推入事件队列。

浏览器渲染流水线​

这就是典型的面试题 "从输入 URL 到页面渲染发生了什么？"

输入 url 到响应发生了什么​

主要流程如下（高级前端必备，建议倒背如流并能扩展底层细节）：

  1. 输入解析与进程间通信 (IPC)
    • 浏览器主进程判断输入是搜索关键字还是 URL。
    • 组装协议（如果没有 https:// 则补全）。
    • 浏览器主进程通过 IPC 将 URL 传给 网络进程 发起请求。
  2. 缓存检查
    • 网络进程首先检查本地是否有强缓存（Cache-Control / Expires）。如果命中强缓存且未过期，直接返回 200 并从内存/磁盘读取资源，阻断后续网络请求。
  3. DNS 解析
    • 依次查询浏览器缓存、操作系统缓存（hosts）、路由器缓存、ISP DNS 服务器。
    • 递归查询与迭代查询，最终将域名解析为对应的 IP 地址。
    • 加分项：DNS Prefetching（<link rel="dns-prefetch">）可以提前解析提升性能。
  4. 建立 TCP 连接（三次握手）
    • 客户端发送 SYN，服务端返回 SYN+ACK，客户端返回 ACK。
    • 如果是 HTTPS，还需要在 TCP 握手之后进行 TLS 握手（非对称加密交换密钥，生成对称密钥用于后续通信）。
    • 加分项：HTTP/3 使用 UDP（QUIC 协议），直接合并了握手过程（0-RTT），彻底解决了 TCP 队头阻塞。
  5. 发送 HTTP 请求
    • 构建请求行、请求头、请求体，发送给服务器。
    • 如果携带 Cookie，会一并发送（受跨域和 SameSite 策略限制）。
  6. 服务器处理与响应
    • 服务器（或网关如 Nginx）接收请求，转发给后端应用处理，返回 HTTP 响应。
    • 状态码 301/302/304 拦截：如果是 304（协商缓存命中），读取本地缓存；如果是 301/302，根据 Location 重新发起请求。
  7. 准备渲染进程与提交文档
    • 网络进程解析响应头，如果是 text/html，浏览器主进程会通知渲染进程“准备接客”。
    • 渲染进程和网络进程建立传输数据的管道。
    • 文档数据传输完成后，渲染进程返回“确认提交”消息，浏览器界面更新安全状态、地址栏和历史记录。
  8. 渲染进程解析与绘制页面（关键渲染路径）
    • 构建 DOM 树：HTML 解析器将字节流转化为字符流，经过词法分析生成 Token，进而构建出 DOM 树。（遇到 <script> 会阻塞 DOM 解析，除非有 defer/async）
    • 构建 CSSOM 树：解析 CSS，将属性值标准化（如 em 转 px，red 转 rgb），生成 CSSOM 树。
    • 样式计算与构建渲染树 (Render Tree)：合并 DOM 和 CSSOM，剔除不可见元素（如 display: none、head 标签），计算每个节点的最终样式。
    • 布局 (Layout)：计算渲染树中每个节点的几何位置和尺寸。
    • 分层 (Layering)：为拥有复杂层叠上下文的元素（如 z-index、transform、will-change、opacity）生成独立的图层。
    • 绘制 (Paint)：为每个图层生成绘制指令列表。
    • 栅格化 (Raster) 与合成 (Composite)：合成线程将图层划分为图块（Tile），利用 GPU 将图块转换为位图。最后由浏览器主进程显示在屏幕上。
    • 加分项：避免重排（Reflow）和重绘（Repaint），尽量使用 CSS3 硬件加速（GPU 参与合成，不触发布局和绘制）。
  9. 断开连接（四次挥手）
    • 客户端发 FIN，服务端 ACK；服务端发 FIN，客户端 ACK（通常有 Connection: keep-alive 会保持一段时间长连接）。

重排重绘​

  • 重排（Reflow / Layout）：当修改了元素的几何属性（宽、高、位置、display: none）或者读取了某些特定的属性（如 offsetHeight、getComputedStyle，这会强制浏览器清空渲染队列并立刻计算最新布局），浏览器需要重新计算元素的几何位置，这个过程非常昂贵。
  • 重绘（Repaint / Paint）：修改了不影响布局的属性（如 color、background-color），浏览器只需重新绘制该元素。
  • 合成（Composite / 硬件加速）：性能最高的渲染路径。如果你只修改了 transform 或 opacity，浏览器会跳过重排和重绘，直接在合成线程中交由 GPU 处理（这也是为什么复杂动画一定要用 transform 实现的原因）。
  • 回流一定会包括重绘，所以回流会更影响性能，在实际操作中，要尽量减少回流。