瀏览器的渲染原理简介.docxVIP

　浏览器工作大流程　从上面这个图中，我们可以看到那么几个事：　1）浏览器会解析三个东西：一个是 HTML/SVG/XHTML，事实上，Webkit 有三个 C++ 的类对应这三类文档。解析这三种文件会产生一个 DOM Tree。CSS，解析 CSS 会产生 CSS 规则树。Javascript，脚本，主要是通过 DOM API 和 CSSOM API 来操作 DOM Tree 和 CSS Rule Tree.　2）解析完成后，浏览器引擎会通过 DOM Tree 和 CSS Rule Tree 来构造 Rendering Tree。注意：Rendering Tree 渲染树并不等同于 DOM 树，因为一些像 Header 或 display:none 的东西就没必要放在渲染树中了。CSS 的 Rule Tree 主要是为了完成匹配并把 CSS Rule 附加上 Rendering Tree 上的每个 Element。也就是 DOM 结点。也就是所谓的 Frame。然后，计算每个 Frame（也就是每个 Element）的位置，这又叫 layout 和 reflow 过程。　3）最后通过调用操作系统 Native GUI 的 API 绘制。　DOM 解析　HTML 的 DOM Tree 解析如下：htmlhead　titleWeb page parsing/title/headbody　div　h1Web page parsing/h1　pThis is an example Web page./p　/div/body/html　上面这段 HTML 会解析成这样：　下面是另一个有 SVG 标签的情况。　CSS 解析　CSS 的解析大概是下面这个样子（下面主要说的是 Gecko 也就是 Firefox 的玩法），假设我们有下面的 HTML 文档：doctitleA few quotes/titleparaFranklin said that quoteA penny saved is a penny earned./quote/paraparaFDR said quoteWe have nothing to fear but spanfear itself./span/quote/para/doc　于是 DOM Tree 是这个样子：　然后我们的 CSS 文档是这样的：/* rule 1 */ doc { display: block; text-indent: 1em; }/* rule 2 */ title { display: block; font-size: 3em; }/* rule 3 */ para { display: block; }/* rule 4 */ [] { font-style: italic; }　于是我们的 CSS Rule Tree 会是这个样子：　注意，图中的第 4 条规则出现了两次，一次是独立的，一次是在规则 3 的子结点。所以，我们可以知道，建立 CSS Rule Tree 是需要比照着 DOM Tree 来的。CSS 匹配 DOM Tree 主要是从右到左解析 CSS 的 Selector，好多人以为这个事会比较快，其实并不一定。关键还看我们的 CSS 的 Selector 怎么写了。　注意：CSS 匹配 HTML 元素是一个相当复杂和有性能问题的事情。所以，你就会在N多地方看到很多人都告诉你，DOM 树要小，CSS 尽量用 id 和 class，千万不要过渡层叠下去，……　通过这两个树，我们可以得到一个叫 Style Context Tree，也就是下面这样（把 CSS Rule 结点 Attach 到 DOM Tree 上）：　所以，Firefox 基本上来说是通过 CSS 解析生成 CSS Rule Tree，然后，通过比对 DOM 生成 Style Context Tree，然后 Firefox 通过把 Style Context Tree 和其 Render Tree（Frame Tree）关联上，就完成了。注意：Render Tree 会把一些不可见的结点去除掉。而?Firefox 中所谓的 Frame 就是一个 DOM 结点，不要被其名字所迷惑了。　注：Webkit 不像 Firefox 要用两个树来干这个，Webkit 也有 Style 对象，它直接把这个 Style 对象存在了相应的 DOM 结点上了。　渲染　渲染的流程基本上如下（黄色的四个步骤）：计算 CSS 样式构建 Render TreeLayout – 定位坐标和大小，是否换行，各种 position, overflow， z-index 属性 ……正式开画　注意：上图流程中有很多连接线，这表示了 Javasc