构建对象模型_对象模型的创建-优快云博客

这篇博客详细介绍了浏览器如何将HTML和CSS转换成可视的网页。首先，HTML字节转化为字符，再通过令牌化和词法分析构建DOM树。同时，CSS内容形成CSSOM树。当DOM和CSSOM合并后，形成渲染树，接着进行布局计算每个元素的位置和大小，最后绘制到屏幕上。渲染过程中，不可见或隐藏的节点将被忽略，而复杂的样式会影响绘制速度。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

概述

字节 -> 字符 -> 令牌 -> 节点 -> 对象模型
HTML 标记转换成文档对象模型 (DOM)；CSS 标记转换成 CSS 对象模型 (CSSOM)
DOM 和 CSSOM 是独立的数据结构

文档对象模型（DOM）

<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <link href="style.css" rel="stylesheet">
    <title>Critical Path</title>
  </head>
  <body>
    <p>Hello <span>web performance</span> students!</p>
    <div><img src="awesome-photo.jpg"></div>
  </body>
</html>

过程

在这里插入图片描述

转换：浏览器从磁盘或网络读取 HTML 的原始字节，并根据文件的指定编码（例如 UTF-8）将它们转换成各个字符
令牌化：浏览器将字符串转换成 W3C HTML5 标准规定的各种令牌，例如，“<html>”、“<body>”，以及其他尖括号内的字符串。每个令牌都具有特殊含义和一组规则
词法分析：发出的令牌转换成定义其属性和规则的“对象”
DOM 构建：由于 HTML 标记定义不同标记之间的关系（一些标记包含在其他标记内），创建的对象链接在一个树数据结构内，此结构也会捕获原始标记中定义的父项-子项关系: HTML 对象是 body 对象的父项，body 是 paragraph 对象的父项，依此类推
DOM 树捕获文档标记的属性和关系，但并未告诉我们元素在渲染后呈现的外观。那是 CSSOM 的责任

CSS 对象模型 (CSSOM)

在浏览器构建我们这个简单页面的 DOM 时，在文档的 head 部分遇到了一个 link 标记，该标记引用一个外部 CSS 样式表: style.css。由于预见到需要利用该资源来渲染页面，它会立即发出对该资源的请求，并返回以下内容
```
body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }
```
我们本可以直接在 HTML 标记内声明样式（内联），但让 CSS 独立于 HTML 有利于我们将内容和设计作为独立关注点进行处理: 设计人员负责处理 CSS，开发者侧重于 HTML，等等
与处理 HTML 时一样，我们需要将收到的 CSS 规则转换成某种浏览器能够理解和处理的东西。因此，我们会重复 HTML 过程，不过是为 CSS 而不是 HTML
CSS 字节转换成字符，接着转换成令牌和节点，最后链接到一个称为“CSS 对象模型”(CSSOM) 的树结构内
还请注意，以上树并非完整的 CSSOM 树，它只显示了我们决定在样式表中替换的样式。每个浏览器都提供一组默认样式（也称为“User Agent 样式”），即我们不提供任何自定义样式时所看到的样式，我们的样式只是替换这些默认样式

渲染树构建、布局及绘制

概述：

页面在解析到body起始标签时开始渲染
DOM 树与 CSSOM 树合并后形成渲染树
渲染树只包含渲染网页所需的节点
布局计算每个对象的精确位置和大小
最后一步是绘制，使用最终渲染树将像素渲染到屏幕上

Render Tree

从 DOM 树的根节点开始遍历每个可见节点
某些节点不可见（例如脚本标记、元标记等），因为它们不会体现在渲染输出中，所以会被忽略
某些节点通过 CSS 隐藏，因此在渲染树中也会被忽略，例如，上例中的 span 节点—不会出现在渲染树中，—因为有一个显式规则在该节点上设置了“display: none”属性
对于每个可见节点，为其找到适配的 CSSOM 规则并应用它们
发射可见节点，连同其内容和计算的样式

在这里插入图片描述

Layout

有了渲染树，我们就可以进入“布局”阶段
到目前为止，我们计算了哪些节点应该是可见的以及它们的计算样式，但我们尚未计算它们在设备视口内的确切位置和大小—这就是“布局”阶段，也称为“自动重排”
为弄清每个对象在网页上的确切大小和位置，浏览器从渲染树的根节点开始进行遍历。让我们考虑下面这样一个简单的实例
```
<!DOCTYPE html>
<html>
  <head>
    <meta name="viewport" content="width=device-width,initial-scale=1">
    <title>Critial Path: Hello world!</title>
  </head>
  <body>
    <div style="width: 50%">
      <div style="width: 50%">Hello world!</div>
    </div>
  </body>
</html>
```
布局流程的输出是一个“盒模型”，它会精确地捕获每个元素在视口内的确切位置和尺寸: 所有相对测量值都转换为屏幕上的绝对像素

paint

最后，既然我们知道了哪些节点可见、它们的计算样式以及几何信息，我们终于可以将这些信息传递给最后一个阶段: 将渲染树中的每个节点转换成屏幕上的实际像素。这一步通常称为“绘制”或“栅格化”
布局完成后，浏览器会立即发出“Paint Setup”和“Paint”事件，将渲染树转换成屏幕上的像素
执行渲染树构建、布局和绘制所需的时间将取决于文档大小、应用的样式，以及运行文档的设备: 文档越大，浏览器需要完成的工作就越多；样式越复杂，绘制需要的时间就越长（例如，单色的绘制开销“较小”，而阴影的计算和渲染开销则要“大得多”）