7
7CellOne
7
7
7CellTwo
7
8
那么两个tr共享computedStyle,两个td共享computedStyle。
在内核里,只会计算第一个tr和第一个td的ComputedStyle。
那么如何做到共享computedStyle呢:
该共享的element不能有id属性且CSS中还有该id的StyleRule.哪怕该StyleRule与Element不匹配。
譬如:
viewplaincopytoclipboard
8div#id1{color:
red}
8
8
paragraph1
8paragraph2
[html]viewplaincopy
8div#id1{color:
red}
8
8
paragraph1
8paragraph2
8
可以看到这两个p标签computedStyle本来是一样的,但他们不共享。
8tagName和class属性必须一样。
8mappedAttribute必须相等。
不能有style属性。
哪怕style属性相等,他们也不共享。
例如:
viewplaincopytoclipboard
8red">paragraph1
8red">paragraph2
8
[html]viewplaincopy
8red">paragraph1
8red">paragraph2
8
8
他们并不共享computedStyle。
8不能使用siblingselector,譬如:
first-child,:
last-selector,+selector.
使用idselector非常的高效。
在使用idselector的时候需要注意一点:
因为id是唯一的,所以不需要既指定id又指定tagName。
例如:
viewplaincopytoclipboard
8Bad
8p#id1{color:
red;}
8Good
8#id1{color:
red;}
[html]viewplaincopy
8Bad
8p#id1{color:
red;}
8Good
8#id1{color:
red;}
9
使用classselector的策略与idselector一样。
在内核实现上,idselector与classselector的匹配并没有多大的区别。
如果同一个class需要赋予不同的css,你可以这样做
viewplaincopytoclipboard
9Bad
9p.class1{color:
red;}
9div.class1{color:
black;}
9Good
9p-class1{color:
red;}
9div-class1{color:
black;}
[html]viewplaincopy
9Bad
9p.class1{color:
red;}
9div.class1{color:
black;}
9Good
9p-class1{color:
red;}
9div-class1{color:
black;}
当然这样会造成网页中的className增多。
具体您决定怎么取舍。
有时要选择的node比较深时,我们可以采取如下写法:
viewplaincopytoclipboard
9Bad
9div>div>div>p{color:
red;}
9Good
9p-class{color:
red;}
[html]viewplaincopy
9Bad
9div>div>div>p{color:
red;}
9Good
9p-class{color:
red;}
10
ChildSelector的匹配比较的慢。
不到万不得已,不要使用attributeselector。
例如:
p[att1="val1"]。
这样的匹配非常慢。
更不要这样写:
p[id="id1"]。
这样将idselector退化成attributeselector。
viewplaincopytoclipboard
10Bad
10p[id="id1"]{color:
red;}
10p[class="class1"]{color:
red;}
10Good
10#id1{color:
red;}
10.class1{color:
red;}
[html]viewplaincopy
10Bad
10p[id="id1"]{color:
red;}
10p[class="class1"]{color:
red;}
10Good
10#id1{color:
red;}
10.class1{color:
red;}
11
12依赖继承。
如果某些属性可以继承,那么自然没有必要在写一遍。
13其他的selector在内核实现上很难做出优化,所以如果可以的话尽量不用。
WebkitCSS模块实现
这里我更多的希望分享我实际开发CSS中所碰到的一些问题,透过这些问题来看webkit的设计也许更有体会。
一些名词的解释
有些webkit内核使用的名词这里作下解释,如果对这些名词不理解,那么对研究代码有一定的阻力
∙mappedAttribute:
一些可以影响CSSComputedStyle的html属性。
举个例子:
paragraph
那么属性align="middle"就叫做mappedAttribute。一般大家都知道每个Element有个inlineStyleDeclaration,实际上还有个隐含的Declaration叫MappedStyleDeclaration.他的优先级比普通的CSS高,比inlineStyle要低。
∙renderStyle:
这就是大家熟悉的ComputedStyle在webkit中的表示。
∙bloomfilter:
一种算法。
没接触过的可以网上搜索。
CSS内部数据的组织
这里不想画一些css对象的继承图。
对象继承图可以参考这篇文章。
并且我假设读者已经熟知CSS相关规范,概念。
解析完CSS脚本后,会生成CSSStyleSheetList,他保存在Document对象上。
为了更快的计算样式,必须对这些CSSStyleSheetList进行重新组织。
(思考,你能直接从CSSStyleSheetList上计算样式吗?
)
计算样式就是从CSSStyleSheetList中找出所有匹配相应元素的property-value对。
匹配会通过CSSSelector来验证,同时需要满足层叠规则。
一种简单但效率偏低的组织方式,暂且称之为数组模型。
将所有的declaration中的property组织成一个大的数组。
数组中的每一项纪录了这个property的selector,property的值,权重(层叠规则)。
例如:
viewplaincopytoclipboard
14
15p>a{color:
red;background-color:
black;}
16a{color:
yellow}
17div{margin:
1px;}
18
19
20重新组织之后的数组数据为(weight我只是表示了他们之间的相对大小,并非实际值。
):
21
22selectorpropertyweight
231,acolor:
yellow1
242,p>acolor:
red2
253,p>abackground-color:
black2
264,divmargin:
1px3
27
[html]viewplaincopy
28
29p>a{color:
red;background-color:
black;}
30a{color:
yellow}
31div{margin:
1px;}
32
33
34重新组织之后的数组数据为(weight我只是表示了他们之间的相对大小,并非实际值。
):
35
36selectorpropertyweight
371,acolor:
yellow1
382,p>acolor:
red2
393,p>abackground-color:
black2
404,divmargin:
1px3
41
可以看到每一个property成为数组的一项。
相同的tagName在数组中的位置相邻,譬如selectora和selectorp>a在数组中相邻。
所有的property以selector的tagName顺序存放。
有了这样的数组组织,你可以想想了,该如何计算样式呢?
一种高效的组织方式,暂且称之为hash模型。
webkit使用CSSRuleSet对象来组织这些数据。
CSSRuleSet是这样一个对象:
他内部有4个hash表,分别为idRules,classRules,tagNameRules,universalRules。
这些hash表的定义是这样的:
HashMap
CSSRuleDataList是一个list,其总每一项为CSSRuleData。
CSSRuleData保存了一个css的styleRule,以及这个styleRule的selector的specificity(可以理解成权值)。
在CSSRuleData的constructor中会计算selector的bloomfilter值。
下图为一个粗略的图示,我并没有完整的画出各个类的定义,但已经可以帮助我们理解这些类的关系:
∙将defaultstylesheet,userstylesheet,authorstylesheet存放在不同的CSSRuleSet上。
而数组模型会将所有的stylesheet组织到一个数组中。
不要小瞧这步动作,这已经让我眼前一亮,他关系到后面的匹配算法部分。
每个CSSRuleSet将所有的stylerule分别组织到idRules,classRules,tagNameRules,universalRules。
譬如:
viewplaincopytoclipboard
41#id1{color:
red;}-->存放在idRules中。
41.class1{color:
red;}-->存放在classRules中。
41.class1{color:
red;}-->同上。
41p{color:
red;}-->在tagNameRules中。
41*{color:
red;}-->在universalRules中。
41
[html]viewplaincopy
41#id1{color:
red;}-->存放在idRules中。
41.class1{color:
red;}-->存放在classRules中。
41.class1{color:
red;}-->同上。
41p{color:
red;}-->在tagNameRules中。
41*{color:
red;}-->在universalRules中。
41
∙
∙内核在在当前所有的stylesheet都已经请求结束,CSSparser结束之后进行组织数据这个动作。
计算样式
样式的计算如果设计的不当,直接影响浏览器内核的性能,所以这里的算法值得大家仔细的分析。
数组模型
我们将匹配之后的结果放在一个数组中,这个数组初始size为CSSproperty的个数。
暂且称这个数组为结果数组。
将defaultstylesheet,userstylesheet,authorstylesheet组织成一个大的数组之后。
要匹配一个标签,譬如:
viewplaincopytoclipboard
41
link
41计算标签a的样式:
[html]viewplaincopy
41
link
41计算标签a的样式:
42
因为数组的tagName是顺序的,所以可以使用二分查找法,找到a的开始位置和结束位置,此时为1-->3.
43针对数组的每一项进行checkselector,如果checkselector成功,存放在结果数组中。
44将匹配的结果存放在结果数组中的时候,需要判断结果数组中是否已经有了该property,如果已经存在则需要比较这两个property的权值,如果新的property权重大于老的,那么需要替换数组中的这一项。
45对数组中所有tagName为universaltagName进行匹配。
重复2-3。
总结:
可以看到该算法需要匹配所有tagName相同的项,以及所有universaltagName。
在checkselector成功之后插入结果数组中,还需要判断是否已经存在了该property。
还有一个更严重的问题,该算法在checkselector的时候,没有保存匹配的selector的相关信息,为以后的局部更新带来了非常多的不确定性问题,导致局部排版无法判断是否需要重排。
对比webkit存在非常多的动作来将不确定的因素确定化,来优化排版所需要的动作。
hash模型
在数组模型中,计算的结果存放在一个数组中。
在hash模型中,也是将计算的结果存放在一个数组中:
Vectorm_matchedRules;
46首先判断该element是否存在可以共享的renderStyle。
是否可以共享的条件较多,这里不详述,粗略的可以参看这里。
但这个策略非常非常棒,网页中能共享的标签非常多,所以能极大的提升执行效率!
如果能共享,那就不需要执行匹配算法了,执行效率自然非常高。
我在对的测试中,17864次计算样式,有4764次共享。
将近27%的计算样式的过程不需要进行,意味着此处性能提高约27%左右!
该网站共有9686个node,3412个element。
依次匹配defaultStyleSheet,userStyleSheet,authorStyleSheet,并将结果存放在结果数组中。
并记录各种stylesheet匹配结果在结果数组中的起始位置。
46每一个StyleSheet匹配的算法:
46如果该Element有id属性,那么从CSSRuleSet的idhashtable中取出相应的CSSRuleDataList
46依次测试CSSRuleDataList中的每一项CSSRuleData。
这里首先会利用bloomfilter算法过滤掉不符合条件的CSSStyleRule。
46在checkselector过程中,如果匹配成功将其加入到结果数组中。
46根据权值对结果数组进行排序。
46如果该Element有class属性,那么从CSSRuleSet的classhashtable中取出相应的CSSRuleDataList。
重复执行步骤2-->步骤4
46根据Element的tagName,从CSSRuleSet种取出tagName对应的CSSRuleDataList,重复步骤2-->步骤4.
46对所有universaltagName的CSSRuleDataList重复步骤2-->步骤4.
上述步骤生成结果数组的算法流程图如下:
47得到了所有匹配的stylerule之后,需要根据这个结果生成renderstyle。
算法步骤如下图,请看图的时候注意两个问题:
47如何体现层叠规则中不同样式表的权重。
47如何体现同一个样式表中相同的property,相同的权重,后面的覆盖前面的。
48
一些思考题
在这一篇文档中实在很难将一个内核模块的所有问题阐述清楚,所以我这里列举一些问题供大家讨论学习。
这些问题也是我在实际工具做所碰到一些具体问题,没有实际开发过CSS模块很难体会到这些问题,而且webkit对这些问题处理的很好,给了我很多启发。
49如果style标签写在了body区域,webkit在解析完这个style标签如何做呢?
style标签写在了body区域好吗?
50:
hover伪类在CSS应用很广泛,想想浏览器内核该怎么做?
需要在一个element收到hover状态的时候,重新计算css吗?
51CSS对象粒度小但数目大,大到CSSStyleSheetList,小到一个CSSValue都要使用CSS对象来表示。
而CSS文档又比较大,这样内存会不会碎片太多?
52CSS对象粒度小但数目大,重复分配释放除了碎片大,也很花费时间,想想有什么好办法吗?
考虑自己管理CSS对象的内存?
53CSS对象粒度小但数目大,这些小粒度对象能共享吗?
设计模式里有个Flyweight模式,CSS里有很好体现。
54一个Element的class属性或者id属性变了,需要重新计算renderstyle以看是否需要重排这个Element。
我们知道有siblingselectorp.class1+a那是不是这个改变了属性的Element的所有兄弟都需要重新计算renderstyle或者说重新排版呢?
55有:
first-child伪类,那是不是意味着往父亲节点中插入一个头结点,所有的孩子都需要重排呢?
因为他们可能有:
first-childselector。
webkit怎么做呢?
56cssvalue中有个值为inherit,表示使用他的parent的属性值。
如果他的parent的属性值变了呢,孩子的值如何更新?
57这篇文章对bloomfilter算法在css中应用讲的不多,但这也确实对CSScheckselector进行了不少的优化。
有兴趣的读者可以参考以下三点去看webkit源码:
57在生成CSSRuleData对象的时候,有bloomfilter数据生成。
57在parsehtml的时候,每个element的beginParsingChildren事件中会更新bloomfilter。
57在matchRulesForList的时候,方法fastRejectSelector就是过滤发生的地方。
58注意:
该优化的动作只在新的webkit版本才有,较老的webkit版本没有此动作。
59computedStyle记录了每个Element的所有的property的值,浏览器排版引擎会非常频繁的从computedStyle中取出某个property的值,将computedStyle设计成一个数组可以吗?
webkit使用renderStyle这个对象来表示computedStyle,这个对象在设计上有什么优点?
重点应关注两点:
59这个对象比数组的形式节省了非常多的内存。
59这个对象比数组的形式节省了非常多的检索时间。
总结
CSS引擎做的事情非常少(解析和计算样式),往往被大家忽略,但要设计出灵活高效的CSS引擎确实不易。
通过剖析webkitCSS的实现,经常有些设计的亮点让我激动很久,所以不要忽略webkitcss模块,他会给你惊喜!
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
-
CSS
引擎
分析
![提示](https://static.bdocx.com/images/bang_tan.gif)
冰豆网所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。