浏览器是如何工作的系列:渲染树的构建
2013-08-10 15:57
666 查看
四、渲染树的构建 当DOM被构建时,浏览器构建另一个渲染树,这棵树上的可视化元素将被按正确的顺序显示。这是文档的可视化表示。 目的在于使可视化元素按他们的顺序渲染他们的内容。 在Firefox中,这些元素在渲染树中称作“帧”,webkit使用术语渲染器或者渲染对象,一个渲染器知道如何去布局和绘制它自己和它的孩子。 Webkits 渲染对象类,基于渲染器的类有以下定义: class RenderObject{ virtual void layout(); virtual void paint(PaintInfo); virtual void rect repaintRect(); Node* node; //the DOM node RenderStyle* style; // the computed style RenderLayer* containgLayer; //the containing z-index layer } 每个渲染一个矩形区域,通常对应一个节点的CSS盒子,也被描述在CSS2.0规则,它包含了几何信息,如宽、高和位置。 盒子的类型受与节点相关的“display”样式属性影响,下面是webkit代码,根据显示属性决定什么类型的渲染器应该创建 一个DOM节点。 RenderObject* RenderObject::createObject(Node* node, RenderStyle* style){ Document* doc = node->document(); RenderArena* arena = doc->renderArena(); ... RenderObject* o = 0; switch (style->display()) { case NONE: break; case INLINE: o = new (arena) RenderInline(node); break; case BLOCK: o = new (arena) RenderBlock(node); break; case INLINE_BLOCK: o = new (arena) RenderBlock(node); break; case LIST_ITEM: o = new (arena) RenderListItem(node); break; ... } return o; } 考虑到元素类型,例如表单控件和表格有特殊的帧。Chrome浏览器中input表单控件,浏览器Computed Style中显示display:inline-block; table->display:table thead->display: table-header-group;tr->display: table-row;tbody->display: table-row-group;th/td->display: table-cell; 在webkit中,如果一个元素想创建一个特殊的渲染器,它将重写“createRender”方法,渲染器指向包含非几何信息的样式对象。 1.渲染树关联到DOM树 渲染器和DOM元素相对应,但是不是一一对应关系,不可见的元素将不会插入到渲染树, 例如“head”元素,该元素的显示属性会设置为“none”,将不会显示到渲染树,(设置visibility:hidden的元素会出现在DOM树)。 有些DOM元素会对应几个可见对象(渲染器),通常这些元素有着复杂的结构,不能被描述成单一的矩形, 例如“select”元素 有三个渲染器——一个显示area,一个下拉框,一个下拉按钮。此外,当文本被分隔成多行时,因为宽度不足显示在一行, 那个新行将作为一个额外的渲染器被添加。 另一个例子,好几个渲染器打破了HTML。根据CSS规范,一个行内元素必须包含唯一的块元素或者仅内联元素,在混合内容的情况下 匿名块渲染器将会被创建并包裹那个内联元素。 一些渲染器对象和一个DOM节点对应,但是不是在树中的同一个地方,浮动和绝对定位的元素是脱离了流,被放置到渲染树 不同的地方,并映射到真实的帧。应该是一个占位符框架。 下图:4.1.1 渲染树和对应的DOM树
2.流构造树 在Firefox中,这个介绍被注册为一个DOM更新监听器。介绍委派帧创建到“FrameConstructor”和构造解析样式(样式计算),并创建了一个框架。 在Webkit,解释样式的过程和创建一个渲染器被称为“attachment”.每一个DOM节点有一个“attach”方法,attachment是同步的, 节点插入到DOM树会调用该新节点的“attach”方法。 在渲染树根节点,HTML和body 标签处理结果,根渲染队形对应到CSS规范中叫做包含块——包含所有的其他块的最顶端块。 它的尺寸是视口-在浏览器窗口的显示区域尺寸。火狐称它为ViewPortFrame、Webkit称为RenderView。这是该文档节点的渲染对象。其余的构造树作为一个DOM节点插入。 关于这个主题,请参阅CSS2 - http://www.w3.org/TR/CSS21/intro.html处理模型 3.样式计算 构建渲染树需要去计算每个可见渲染对象的属性,即计算每个元素的样式属性。样式包括来自各种样式表、内联样式 和可见属性在HTML标签中的,后来被翻译成匹配的CSS样式属性。 样式表的起源是浏览器的默认的样式表,风格表的页面作者和用户样式表提供 - 这些样式表提供用户的浏览器 (浏览器让你定义自己喜欢的风格。在Firefox中,例如,这是通过放置一个样式表在“火狐配置文件”文件夹)中。 样式计算带来了一些困难: a)样式数据是一个非常大的结构,列举多种样式属性,这可能会导致内存问题。 b)查找每个元素的匹配规则可能会导致性能问题,如果它不优化。遍历整个规则列表中的每个元素找到匹配的是一个沉重 的任务。选择器可以有复杂的结构,可能会导致匹配过程开始于一个看似前途的道路被证明是徒劳的,必须尝试另一条路径。 例如-这种混合选择器: div div div div{ ... } 这意味着规则应用到三个div的后代div元素,选择树上一条特定的路径去检查,这可能需要遍历节点树,最后却发现它只是两个div的后代, 并不使用该规则,然后则需要沿着另一条路径去尝试 c)应用规则涉及到相当复杂的级联规则,规则定义的规则的层次。 让我们来看看浏览器是如何面对这些问题: 1)共享样式数据 webkit节点引用样式对象(渲染样式),某些情况下,这些对象可以被节点间共享,这些节点需要是兄弟或是表兄弟节点,并且: 这些元素必须处于相同的鼠标状态(比如不能一个处于hover,而另一个不是) 不能有元素具有id 标签名必须匹配 class属性必须匹配 对应的属性必须相同 链接状态必须匹配 焦点状态必须匹配 不能有元素被属性选择器影响 元素不能有行内样式属性 不能有生效的兄弟选择器,webcore在任何兄弟选择器相遇时只是简单的抛出一个全局转换, 并且在它们显示时使整个文档的样式共享失效,这些包括+选择器和类似:first-child和:last-child这样的选择器。 2)Firefox的规则树 Firefox用两个树用来简化样式计算-规则树和样式上下文树,webkit也有样式对象, 但它们并没有存储在类似样式上下文树这样的树中,只是由Dom节点指向其相关的样式。 如下图:4.3.2 Firefox样式上下文
样式上下文包含最终值,这些值是通过以正确顺序应用所有匹配的规则,并将它们由逻辑值转换为具体的值, 例如,如果逻辑值为屏幕的百分比,则通过计算将其转化为绝对单位。样式树的使用确实很巧妙, 它使得在节点中共享的这些值不需要被多次计算,同时也节省了存储空间。 所有匹配的规则都存储在规则树中,一条路径中的底层节点拥有最高的优先级,这棵树包含了所找到的 所有规则匹配的路径(译注:可以取巧理解为每条路径对应一个节点,路径上包含了该节点所匹配的所有规则)。 规则树并不是一开始就为所有节点进行计算,而是 在某个节点需要计算样式时,才进行相应的计算并将计算后的路径添加到树中。 我们将树上的路径看成辞典中的单词,假如已经计算出了如下的规则树:如图4.3.2.1
假如需要为内容树中的另一个节点匹配规则,现在知道匹配的规则(以正确的顺序)为B-E-I,因为我们已经计算出了路径A-B-E-I-L, 所以树上已经存在了这条路径,剩下的工作就很少了。 现在来看一下树如何保存。 a)结构化 样式上下文按结构划分,这些结构包括类似border或color这样的特定分类的样式信息。一个结构中的所有特性不是继承的就是非继承的,对继承的特性, 除非元素自身有定义,否则就从它的parent继承。非继承的特性(称为reset特性)如果没有定义,则使用默认的值。 样式上下文树缓存完整的结构(包括计算后的值),这样,如果底层节点没有为一个结构提供定义,则使用上层节点缓存的结构。 b)使用规则树计算样式上下文 当为一个特定的元素计算样式时,首先计算出规则树中的一条路径,或是使用已经存在的一条,然后使 用路径中的规则去填充新的样式上下文, 从样式的底层节点开始,它具有最高优先级(通常是最特定的选择器),遍历规则树,直到填满结构。如果在那个规则节点 没有定义所需的结构规则,则沿着路径向上,直到找到该结构规则。 如果最终没有找到该结构的任何规则定义,那么如果这个结构是继承型的,则找到其在内容树中的parent的结构, 这种情况下,我们也成功的共享了结构;如果这个结构是reset型的,则使用默认的值。 如果特定的节点添加了值,那么需要做一些额外的计算以将其转换为实际值,然后在树上的节点缓存该值,使它的children可以使用。 当一个元素和它的一个兄弟元素指向同一个树节点时,完整的样式上下文可以被它们共享。 来看一个例子:假设有下面这段html <html> <body> <div class="err" id="div1"> <p> this is a <span class="big"> big error </span> this is also a <span class="big"> very big error</span> error </p> </div> <div class="err" id="div2">another error</div> </body> </html> 以及下面的规则: 1. div {margin:5px;color:black} 2. .err {color:red} 3. .big {margin-top:3px} 4. div span {margin-bottom:4px} 5. #div1 {color:blue} 6. #div2 {color:green} 简化下问题,我们只填充两个结构——color和margin,color结构只包含一个成员-颜色,margin结构包含四边。 如下图4.3.2.2,生成的规则树,.3.2.3 上下文树
假设我们解析html,遇到第二个div标签,我们需要为这个节点创建样式上下文,并填充它的样式结构。 我们进行规则匹配,找到这个div匹配的规则为1、2、6,我们发现规则树上已经存在了一条我们可以使用的 路径1、2,我们只需为规则6新增一个节点添加到下面(就是规则树中的F)。 然后创建一个样式上下文并将其放到上下文树中,新的样式上下文将指向规则树中的节点F。 现在我们需要填充这个样式上下文,先从填充margin结构开始,既然最后一个规则节点没有添加margin结构, 沿着路径向上,直到找到缓存的前面插入节点计算出的结构,我们发现B是最近的指定margin值的节点。 因为已经有了color结构的定义,所以不能使用缓存的结构,既然color只有一个属性,也就不需要沿着路径向上填充其他属性。 计算出最终值(将字符串转换为RGB等),并缓存计算后的结构。 第二个span元素更简单,进行规则匹配后发现它指向规则G,和前一个span一样,既然有兄弟节点指向同一个节点, 就可以共享完整的样式上下文,只需指向前一个span的上下文。 因为结构中包含继承自parent的规则,上下文树做了缓存(color特性是继承来的,但Firefox将其视为reset并在规则树中缓存)。 例如,如果我们为一个paragraph的文字添加规则: p {font-family:Verdana;font size:10px;font-weight:bold} 那么这个p在内容树中的子节点div,会共享和它parent一样的font结构,这种情况发生在没有为这个div指定font规则时。 Webkit中,并没有规则树,匹配的声明会被遍历四次,先是应用非important的高优先级属性(之所以先应用这些属性, 是因为其他的依赖于它们-比如display),其次是高优先级important的,接着是一般优先级非important的,最后是一般优先级important的规则。 这样,出现多次的属性将被按照正确的级联顺序进行处理,最后一个生效。 总结一下,共享样式对象(结构中完整或部分内容)解决了问题1和3,Firefox的规则树帮助以正确的顺序应用规则。 3)对规则进行处理以简化匹配过程 样式规则有几个来源: · 外部样式表或style标签内的css规则 p {color:blue} · 行内样式属性 <p bgcolor="blue" /> · html可视化属性(映射为相应的样式规则) 后面两个很容易匹配到元素,因为它们所拥有的样式属性和html属性可以将元素作为key进行映射。 就像前面问题2所提到的,css的规则匹配可能很狡猾,为了解决这个问题,可以先对规则进行处理,以使其更容易被访问。 解析完样式表之后,规则会根据选择符添加一些hash映射,映射可以是根据id、class、标签名或是任何不属于这些分类的综合映射。 如果选择符为id,规则将被添加到id映射,如果是class,则被添加到class映射,等等。 这个处理是匹配规则更容易,不需要查看每个声明,我们能从映射中找到一个元素的相关规则,这个优化使在进行规则匹配时减少了95+%的工作量。 来看下面的样式规则: p.error {color:red} #messageDiv {height:50px} div {margin:5px} 第一条规则将被插入class映射,第二条插入id映射,第三条是标签映射。 下面这个html片段: <p class="error">an error occurred </p> <div id=" messageDiv">this is a message</div> 我们首先找到p元素对应的规则,class映射将包含一个“error”的key,找到p.error的规则,div在id映射和标签映射中都有相关的规则, 剩下的工作就是找出这些由key对应的规则中哪些确实是正确匹配的。 例如,如果div的规则是table div {margin:5px} 这也是标签映射产生的,因为key是最右边的选择符,但它并不匹配这里的div元素,因为这里的div没有table祖先。 Webkit和Firefox都会做这个处理。 4)在正确的级联顺序应用规则 样式对象拥有对应所有可见属性的属性,如果特性没有被任何匹配的规则所定义,那么一些特性可以从parent的样式对象中继承,另外一些使用默认值。 这个问题的产生是因为存在不止一处的定义,这里用级联顺序解决这个问题。 a)样式表的级联顺序 一个样式属性的声明可能在几个样式表中出现,或是在一个样式表中出现多次, 因此,应用规则的顺序至关重要,这个顺序就是级联顺序。根据css2的规范,级联顺序为(从低到高): 1. 浏览器声明 2. 用户声明 3. 作者的一般声明 4. 作者的important声明 5. 用户important声明 浏览器声明是最不重要的,用户只有在声明被标记为important时才会覆盖作者的声明。 具有同等级别的声明将根据specifity以及它们被定义时的顺序进行排序。 Html可视化属性将被转换为匹配的css声明,它们被视为最低优先级的作者规则。 b)Specifity Css2规范中定义的选择符specifity如下: · 如果声明来自style属性,而不是一个选择器的规则,则计1,否则计0(=a) · 计算选择器中id属性的数量(=b) · 计算选择器中class及伪类的数量(=c) · 计算选择器中元素名及伪元素的数量(=d) 连接a-b-c-d四个数量(用一个大基数的计算系统)将得到specifity。这里使用的基数由分类中最高的基数定义。 例如,如果a为14,可以使用16进制。不同情况下,a为17时,则需要使用阿拉伯数字17作为基数, 这种情况可能在这个选择符时发生html body div div …(选择符中有17个标签,一般不太可能)。 * {} /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */ li {} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */ li:first-line {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */ ul li {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */ ul ol+li {} /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */ h1 + *[rel=up]{} /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */ ul ol li.red {} /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */ li.red.level {} /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */ #x34y {} /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */ style="" /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */ c)排序规则 规则匹配后,需要根据级联顺序对规则进行排序,webkit先将小列表用冒泡排序, 再将它们合并为一个大列表,webkit通过为规则复写“>”操作来执行排序: static bool operator >(CSSRuleData& r1, CSSRuleData& r2) { int spec1 = r1.selector()->specificity(); int spec2 = r2.selector()->specificity(); return (spec1 == spec2) : r1.position() > r2.position() : spec1 > spec2; } 4.循序渐进的过程 webkit使用一个标志位标识所有顶层样式表都已加载,如果在attch时样式没有完全加载, 则放置占位符,并在文档中标记,一旦样式表完成加载就重新进行计算。
相关文章推荐
- 浏览器是如何工作的系列:解析和DOM树的构建
- 浏览器是如何工作的系列:渲染引擎
- 浏览器是如何工作的系列:渲染引擎
- 了解浏览器如何工作—渲染引擎
- 浏览器渲染原理|绘制|展现|解析|如何工作
- 浏览器是如何工作的系列:绘制
- WEB前端底层知识之浏览器是如何工作的(2)--渲染引擎
- 浏览器是如何工作的系列:页面布局
- 浏览器工作原理(六):渲染树构建
- 浏览器是如何工作的系列:CSS2可视化模型
- 浏览器是如何工作的系列:绘制
- 浏览器是如何工作的系列:页面布局
- 了解浏览器如何工作—渲染引擎
- WEB前端底层知识之浏览器是如何工作的(2)--渲染引擎
- 浏览器是如何工作的系列:基本介绍
- 了解浏览器如何工作—渲染引擎
- 浏览器工作原理4-渲染树构建
- WEB前端底层知识之浏览器是如何工作的(2)--渲染引擎
- 了解浏览器如何工作―渲染引擎
- 【转载】WEB前端底层知识之浏览器是如何工作的(2)--渲染引擎