前端知识体系（1）--浏览器篇

初衷

从学前端到现在也有差不多三年了，一直感觉自己对于这个行业的知识有些杂乱，所以希望通过这个机会梳理一下做个连接，形成自己的知识体系。希望对其他前端er也有所帮助。

浏览器的组成

界面控件 - 除浏览器主窗口外的其他部分，包括地址栏，前进后退按钮等都属于浏览器的界面控件
浏览器引擎 - 将用户界面的之类传递给渲染引擎
渲染引擎 - 负责解析CSS和HTLML页面显示在浏览器窗口
网络请求 - 用户的的网络请求，如HTTP请求。
UI后端 - 绘制基础元件，如组合框与窗口。
JS解析器 - 用于解析执行JavaScript代码。
数据存储 - 持久层，如sessionStorage，cookie，localStorage以及浏览器内置的数据库。

注意：chrome浏览器与其他浏览器不同，chrome使用多个渲染引擎实例，每个Tab页一个，即每个Tab都是一个独立进程。

浏览器中的进程和线程

GUI渲染线程
JavaScript引擎线程
定时器触发线程
事件触发线程
异步HTTP请求线程

以上浏览器的线程都是我们作为前端需要去了解的部分。

浏览器渲染的过程

渲染流程有四个主要步骤：

解析HTML生成DOM树 - 渲染引擎首先解析HTML文档，生成DOM树
构建Render树 - 解析CSS样式不管是内联式，外联式还是嵌入式引入的CSS样式都会被解析生成CSSOM树，根据DOM树与CSSOM树对应合并生成另一棵用于渲染的树-渲染树（Render Tree）
布局Render树 - 确定Render树每个节点在页面上显示的位置
绘制Render树 - 遍历渲染树并用UI后端层将对应节点绘制出来

以上步骤是一个渐进的过程，为了提高用户体验，渲染引擎试图尽可能快的把结果显示给最终用户。它不会等到所有HTML都被解析完才创建并布局渲染树。它会在从网络层获取文档内容的同时把已经接收到的局部内容先展示出来。

1.解析HTML生成DOM树

DOM树的构建式一个深度遍历的过程：当前节点的所以子节点都构建完成后才会去构建当前节点的下一个兄弟节点。 DOM树的构建过程可能会被CSS和JS的加载执行阻塞。

关于CSS加载的阻塞情况：

<!DOCTYPE html>
<html lang='en'>
  <head>
    <title>css阻塞</title>
    <meta charset='UTF-8'>
    <meta name='viewport' content='width=device-width, initial-scale=1'>
    <style>
      h1 {
        color: red !important
      }
    </style>
    <script>
      function h () {
        console.log(document.querySelectorAll('h1'))
      }
      setTimeout(h, 0)
    </script>
    <link href='https://cdn.bootcss.com/bootstrap/4.0.0-alpha.6/css/bootstrap.css' rel='stylesheet'>
  </head>
  <body>
    <h1>这是红色的</h1>
  </body>
</html>

上面这个代码在css还未加载完成前，控制台就打印出了DOM元素h1，但是页面还是空白，等到css加载完毕页面才出现，说明css加载不会阻塞DOM树的解析但是会阻塞DOM树的渲染。

<head>
  <link rel='stylesheet' href='/main.css' />
  <script>
    console.log('我执行了')
  </script>
</head>

以上代码在css加载未完成的情况下，控制台没有打印出信息，等css加载完成后才有信息输出，说明css加载会阻塞后面js语句的执行。通过以上代码我们可以得出以下结论：

css加载不会阻塞DOM树的解析
css加载会阻塞DOM树的渲染
css加载会阻塞后面js语句的执行

在没有js的理想情况下，html与css会并行解析，分别生成DOM与CSSOM，然后合并成Render Tree，进入Rendering Pipeline；但如果有js，css加载会阻塞后面js语句的执行，而（同步）js脚本执行会阻塞其后的DOM解析（所以通常会把css放在头部，js放在body尾）

关于JS加载的阻塞情况：

在解析DOM树前遇到外部的script脚本，如果没有async，defer属性，则会阻塞文档加载，等待脚本加载完成后继续解析文档；如果脚本有async，defer属性，浏览器会另外创建线程来加载脚本，对于async属性的脚本，加载完成后会立即执行。
DOM解析完之后，document.readyState = 'interactive'，此时defer属性的脚本开始顺序执行，执行完毕后触发了DOMContentLoaded事件，标志着程序执行从同步脚本执行阶段转换为事件驱动阶段。
async属性脚本加载完就会执行，不论是在HTML解析阶段还是在DOMContentLoaded之后执行，async属性脚本会阻塞load事件，当所有的async脚本执行完毕，以及img等资源加载完毕，document.readyState = 'complete'，window对象会触发load事件。

2.生成Render树

生成DOM树的同时会生成样式结构体CSSOM（CSS Object Model）Tree，再根据CSSOM和DOM树构造渲染树Render Tree，渲染树包含带有颜色，尺寸等显示属性的矩形，这些矩形的顺序与显示顺序基本一致。

3.布局与绘制

上面确定了renderer的样式规则后，然后就是重要的显示元素布局了。当renderer构造出来并添加到Render树上之后，它并没有位置跟大小信息，为它确定这些信息的过程，接下来是布局(layout)。

4.回流与重绘

回流(reflow): 当浏览器发现某个部分发生了点变化影响了布局，需要倒回去重新渲染。reflow 会从 <html>这个 root frame 开始递归往下，依次计算所有的结点几何尺寸和位置。reflow 几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。通常我们都无法预估浏览器到底会 reflow 哪一部分的代码，它们都彼此相互影响着。 重绘(repaint): 改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性时，屏幕的一部分要重画，但是元素的几何尺寸没有变。

触发回流一定会触发重绘，但是重绘却不一定会触发回流

性能影响

回流的代价比重绘更高
现代浏览器会对频繁的回流和重绘操作进行优化，即会将所有的回流或重绘的操作放入一个队列，然后进行一起操作，避免多次进行回流和重绘

前端知识体系（1）--浏览器篇