浏览器内部工作原理【摘抄概述】

发表于 | 更新于:
字数统计: 2,581 | 阅读时长 ≈ 9

从输入一个网址 google.com 直到您在浏览器屏幕上看到 Google 首页的整个过程中都发生了些什么

一、前置信息

浏览器主要组件

  1. 用户界面 - 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗口显示的您请求的页面外，其他显示的各个部分都属于用户界面。
  2. 浏览器引擎 - 在用户界面和呈现引擎之间传送指令。
  3. 渲染引擎 - 负责显示请求的内容。如果请求的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。
  4. 网络 - 用于网络调用，比如 HTTP 请求。其接口与平台无关，并为所有平台提供底层实现。
  5. 用户界面后端 - 用于绘制基本的窗口小部件，比如组合框和窗口。其公开了与平台无关的通用接口，而在底层使用操作系统的用户界面方法。
  6. JavaScript 解释器。用于解析和执行 JavaScript 代码。
  7. 数据存储。这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie。新的 HTML 规范 (HTML5) 定义了“网络数据库”，这是一个完整（但是轻便）的浏览器内数据库。

和大多数浏览器不同，Chrome 浏览器的每个标签页都分别对应一个渲染引擎实例。每个标签页都是一个独立的进程

渲染引擎

Firefox 使用的是 Gecko，这是 Mozilla 公司“自制”的呈现引擎。而 Safari 和 Chrome 浏览器使用的都是 WebKit。（新版Chrome使用Blink）

二、浏览器渲染

HTML 解析

HTML Parse 同时包含 词法分析器和语法分析器。

  1. 词法分析是将输入内容分割成大量标记的过程。标记是语言中的词汇，即构成内容的单位。在人类语言中，它相当于语言字典中的单词.

  2. 语法分析是应用语言的语法规则的过程

  3. 输出，解析器的输出“解析树”是由 DOM 元素和属性节点构成的树结构。DOM 是文档对象模型 (Document Object Model) 的缩写。
    它是 HTML 文档的对象表示，同时也是外部内容（例如 JavaScript）与 HTML 元素之间的接口。
    解析树的根节点是“Document”对象。

CSS解析器

解析器都会将 CSS 文件解析成 StyleSheet 对象，且每个对象都包含 CSS 规则。CSS 规则对象则包含选择器和声明对象，以及其他与 CSS 语法对应的对象。

处理脚本和样式表的顺序

  1. 脚本
    网络的模型是同步的。网页作者希望解析器遇到<script>标记时立即解析并执行脚本。文档的解析将停止，直到脚本执行完毕。如果脚本是外部的，那么解析过程会停止，直到从网络同步抓取资源完成后再继续。此模型已经使用了多年，也在 HTML4 和 HTML5 规范中进行了指定。作者也可以将脚本标注为“defer”，这样它就不会停止文档解析，而是等到解析结束才执行。HTML5 增加了一个选项，可将脚本标记为异步，以便由其他线程解析和执行。

  2. 预解析
    WebKit 和 Firefox 都进行了这项优化。在执行脚本时，其他线程会解析文档的其余部分，找出并加载需要通过网络加载的其他资源。通过这种方式，资源可以在并行连接上加载，从而提高总体速度。请注意，预解析器不会修改 DOM 树，而是将这项工作交由主解析器处理；预解析器只会解析外部资源（例如外部脚本、样式表和图片）的引用。

  3. 样式表
    另一方面，样式表有着不同的模型。理论上来说，应用样式表不会更改 DOM 树，因此似乎没有必要等待样式表并停止文档解析。但这涉及到一个问题，就是脚本在文档解析阶段会请求样式信息。如果当时还没有加载和解析样式，脚本就会获得错误的回复，这样显然会产生很多问题。这看上去是一个非典型案例，但事实上非常普遍。Firefox 在样式表加载和解析的过程中，会禁止所有脚本。而对于 WebKit 而言，仅当脚本尝试访问的样式属性可能受尚未加载的样式表影响时，它才会禁止该脚本。

渲染树
  1. 渲染树。这是由可视化元素按照其显示顺序而组成的树，也是文档的可视化表示。它的作用是让您按照正确的顺序绘制内容。
  2. Firefox 将渲染树中的元素称为 “Frame”。WebKit 使用的术语是渲染器或渲染对象。 渲染对象知道如何布局并将自身及其子元素绘制出来
  3. 每一个渲染对象都代表了一个矩形的区域，通常对应于相关节点的 CSS 框，这一点在 CSS2 规范中有所描述。它包含诸如宽度、高度和位置等几何信息。 框的类型会受到与节点相关的“display”样式属性的影响
渲染树和 DOM 树的关系
  • 渲染对象是和 DOM 元素相对应的，但并非一一对应。非可视化的 DOM 元素不会插入渲染树中，例如“head”元素。如果元素的 display 属性值为“none”，那么也不会显示在渲染树中（但是 visibility 属性值为“hidden”的元素仍会显示）。
  • 有一些 DOM 元素对应多个可视化对象。它们往往是具有复杂结构的元素，无法用单一的矩形来描述。例如，“select”元素有 3 个渲染对象：一个用于显示区域，一个用于下拉列表框，还有一个用于按钮。如果由于宽度不够，文本无法在一行中显示而分为多行，那么新的行也会作为新的渲染对象而添加
样式计算

存在的难点

  1. 样式数据是一个超大的结构，存储了无数的样式属性，这可能造成内存问题。
  2. 如果不进行优化，为每一个元素查找匹配的规则会造成性能问题。要为每一个元素遍历整个规则列表来寻找匹配规则，这是一项浩大的工程。选择器会具有很复杂的结构，这就会导致某个匹配过程一开始看起来很可能是正确的，但最终发现其实是徒劳的，必须尝试其他匹配路径。
  3. 应用规则涉及到相当复杂的层叠规则（用于定义这些规则的层次）

处理的一些方案

  1. WebKit 节点会引用样式对象 (RenderStyle)。这些对象在某些情况下可以由不同节点共享。这些节点是同级关系。并且满足一些其他条件

    • 这些元素必须处于相同的鼠标状态（例如，不允许其中一个是“:hover”状态，而另一个不是）
    • 任何元素都没有 ID
    • 类属性应匹配
    • 元素中不能有任何 inline 样式属性
    • 等等…
    • 不能使用任何同级选择器。WebCore 在遇到任何同级选择器时，只会引发一个全局开关，并停用整个文档的样式共享（如果存在）。这包括 + 选择器以及 :first-child 和 :last-child 等选择器。(注意这点，有待实践)

  2. Firefox 规则树 …

布局
  1. 渲染对象在创建完成并添加到渲染树时，并不包含位置和大小信息。计算这些值的过程称为布局或重排。
  2. HTML 采用基于流的布局模型，这意味着大多数情况下只要一次遍历就能计算出几何信息。处于流中靠后位置元素通常不会影响靠前位置元素的几何特征，因此布局可以按从左至右、从上至下的顺序遍历文档。但是也有例外情况，比如 HTML 表格的计算就需要不止一次的遍历 (3.5)。
  3. 坐标系是相对于根框架而建立的，使用的是上坐标和左坐标。
  4. 布局是一个递归的过程。它从根渲染对象（对应于 HTML 文档的 元素）开始，然后递归遍历部分或所有的框架层次结构，为每一个需要计算的渲染对象计算几何信息。
  5. 根渲染对象的位置左边是 0,0，其尺寸为视口（也就是浏览器窗口的可见区域）。
  6. 所有的渲染对象都有一个“layout”或者“reflow”方法，每一个渲染对象都会调用其需要进行布局的子代的 layout 方法。
渲染

  1. 在绘制阶段，系统会遍历渲染树，并调用渲染对象的“paint”方法，将渲染对象的内容显示在屏幕上。绘制工作是使用用户界面基础组件完成的。

  2. 全局绘制和增量绘制
    和布局一样，绘制也分为全局（绘制整个渲染树）和增量两种。在增量绘制中，部分渲染对象发生了更改，但是不会影响整个树。更改后的渲染对象将其在屏幕上对应的矩形区域设为无效，这导致 OS 将其视为一块“dirty 区域”，并生成“paint”事件。OS 会很巧妙地将多个区域合并成一个。在 Chrome 浏览器中，情况要更复杂一些，因为 Chrome 浏览器的渲染对象不在主进程上。Chrome 浏览器会在某种程度上模拟 OS 的行为。展示层会侦听这些事件，并将消息委托给呈现根节点。然后遍历渲染树，直到找到相关的渲染对象，该渲染器会重新绘制自己（通常也包括其子代）。

原文链接