Inside the-browser

Inside the Browser浏览器渲染原理

WHY?HTML布局无处不在已经不局限与浏览器

Summary浏览器的工作过程资源下载HTML解析CSS计算布局渲染浏览器对细节的具体优化手段FirefoxWebkit / Chrome

下载一个HTTP库能够搞定？DNSClientWebRequestNetworkStreamHTMLParser够了吗？不仅仅一个文件！<script src…<link href…<imgsrc…<iframesrc…何时开始下载它们？

下载<head>中的<script>和<link>服务器端Response.Flush()<body>中的<script>document.writenew Image().src = …defer VS async

下载资源优先级link[rel=stylesheet] / scriptobject / img / iframelink[rel=prefetch]脚本依赖下载阻塞 VS 执行阻塞并行度服务器压力 VS 客户端效率http://www.otakustay.com/browser-strategy-loading-external-resource/

下载Socket重用Connection: keep-aliveContent-LengthTransfer-Encoding: chucked正确性保证Content-MD5断点续传Accept-RangeContent-Range

下载BS的精髓 – 缓存验证型缓存Last-Modified & If-Modified-Since / If-Unmodified-SinceETag &If-Match / If-None-MatchIf-Range非验证型缓存Cache-ControlExpires缓存失效Vary/ Via / Date / Agehttp://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

下载缓存年龄计算age_value – Age响应头的值date_value – Date响应头的值request_time – 发起请求的本地时间response_time – 收到响应的本地时间now – 当前本地时间apparent_age = max(0, response_time - date_value);corrected_received_age = max(apparent_age, age_value);response_delay = response_time - request_time;corrected_initial_age = corrected_received_age + response_delay;resident_time = now - response_time;current_age = corrected_initial_age + resident_time;

下载缓存过期计算freshness_lifetime = 使用max-age时为max-age的秒数使用Expires时为(Expires - Date)response_is_fresh= (freshness_lifetime > current_age)max-age=0 VS no-cachemax-age=0 – 要求浏览器向服务器验证缓存no-cache– 要求浏览器向服务器请求全新内容

下载输入 – 资源URI输出 –HTML字符流HTTP的超链接特性注定资源之间有关联的依赖外部资源位置、类型不同影响下载时机Response.Flush对下载的影响缓存机制复杂但完善

解析只有这些？document.writeTokenizerTree ConstructScriptDOM Tree

解析输入 – HTML字符流输出 – DOM TreeHTML无法用自顶向下或自底向上的方法解析过程 – 序列化 -> 转义处理 -> 标签匹配脚本执行会增加解析的回溯DOM操作回溯至标签匹配过程document.write回溯至序列化过程

CSS计算元素 – 匹配样式div>div>div>div>div…>div { color: red; }dom.parentNodeistanceofHTMLDivElement && div.parentNode.parentNodeinstanceofHTMLDivElement && div.parentNode.parentNode.parentNodeinstanceof …问题样式表很大，对内存造成压力每个元素生成一个StyleObject浪费内存查找元素匹配的样式消耗时间和CPU如果是div div div div … div呢？

CSS计算Webkit – 特定条件下样式共享鼠标状态（:hover / down / clicked）相同没有id标签名相同class名称相同attribute均相同链接状态（:link / :visited）相同聚集状态（:active / :focus）相同不能匹配属性选择器没有内联样式没有兄弟选择器（+ / :first-child / :last-child / …）

CSS计算FirefoxRule Tree + Style Context TreeDEMOhttps://developer.mozilla.org/en/Style_System_Overview

CSS计算Map{ string: [ selector, selector, … ] }以最右选择器为依据匹配查找id map查找class map查找general map确定selector完全匹配遍历general map

CSS计算#title { … }p.error { … }input[type=radio] { … }＃navli~li a { … }.fix-clear * { … }<div class=“fix-clear”><span id=“title” class=“error”>Erorr Occurred!</span></div>

CSS计算CSS层级（优先级）来源层级浏览器UA样式用户样式作者样式用户样式 + !important作者样式 + !important样式层级1,1,1,1算法inline(0/1), count(id), count(attribute), count(tag)ul#navolli.red

CSS计算DOM TreeRender Treehttps://developer.mozilla.org/en/Mozilla_Style_System_Documentation

CSS计算元素没有渲染对象head / meta / script元素有多个渲染对象html / liselect / input[type=file]通过CSS改变渲染对象display: none::before / ::after

CSS计算输入–DOMTree输出 –Render Tree目标– 内存优化、匹配效率优化方法– 样式共享、选择器索引DOM Tree !== Render Tree

布局流布局display:　ｉｎｌｉｎｅ　/　ｉｎｌｉｎｅ－ｂｌｏｃｋ　/　ｂｌｏｃｋfloat: left / rightclear:　left　/ right / bothposition: static / relative / absolute / fixedHTML三条流文档流、浮云流、定位流其它因素display: list-itemdisplay: run-inhttp://www.w3.org/TR/css3-box/#the-lsquo

布局table布局display: table / inline-table / table-row-group / table-header-group / table-footer-group / table-row / table-column-group / table-column / table-cell / table-captiondiv VS table – 流布局 VS table布局

布局坐标系 – 左上角为0,0点，右|下为正坐标布局是递归过程流布局可自左向右、自上而下进行，流中靠后的元素不会影响流中靠前的元素的布局（无回溯）table布局需要回溯才能够完成（知道每一个单元格的大小，才能完成整个布局）反对table布局的原因– 回溯对渲染的影响DEMO

布局全局Reflow整个RenderTree全部重新计算布局全局布局样式变更 – body { font-size: 12px; }/ 添加新样式表窗口大小变化局部Reflow仅标识为needLayout的渲染元素计算布局Render Tree中插入新的渲染元素渲染元素属性变化Reflow会引起另一个Reflow – Reflow导致滚动条位置变化

布局同步Reflow全局Reflow通常同步进行读取offsetWidth/offsetHeight等属性异步Reflow局部Reflow通常异步进行FireFox：Reflow任务进入线程Queue，任务调度器负责执行Webkit：定时器定时遍历RenderTree，布局所有needLayout对象Reflow任务可合并，一次脚本执行过程中多个样式修改仅做一次Reflow，但是有阀值DEMO

布局父元素确定自己的宽度开始遍历子元素指定子元素渲染器的x/y属性判断子元素是否需要布局，调用layout函数累计所有子元素的width/padding/border/margin，计算自己的宽度同时考虑availWidth / sizing-box / min-width / max-width将needLayout改为false

布局文字布局text-align: justifiedwhite-space: nowrap/ pre / pre-wrapoverflow: hidden / visible换行计算每行一个line-box负责渲染当需要换行时，通知父元素，父元素创建新的line-box并重新布局换行算法与文化相关英文单词不能断开中文标点不能在行首

布局有流式布局和table布局2种table布局需要回溯，流式布局通常不需要Reflow的分类触发类型上 – 全局和局部执行类型上 – 同步和异步布局过程递归进行坐标系为左上角0,0点，右、下为正方向

渲染transform / filter / z-index / color / visibility…Reflow VS Repaint – display: none VS visibility: hidden渲染顺序(CSS2)：background colorbackground imageborderchildrenoutlinehttp://www.w3.org/TR/CSS21/zindex.html

渲染Firefox – display list找到Render Tree中在指定Repaint区域内的渲染对象Render Tree的渲染对象经Stacking Order排序后生成[background(A), border(A), border(B), outline(A)]避免多次遍历Render Tree[background(A, B), border(A, B), outline(A, B)]完全不可见的元素不可被加到displaylist中display: none;opacity: 0;

渲染Webkit– rectangle storageRepaint前先将原有矩形内容保存为位图计算重绘后的矩形内容的位图比对2个位图，仅绘制差异部分Chrome的Repaint在独立进程中进程间通过事件进行传递和响应绘制监听器负责监听重绘事件，把事件委托给Render Tree的根Repaint永远从Render Tree的根开始，遍历并找到需要重绘的节点，对节点调用重绘（递归至子节点）

Inside the-browser

Recommended

More Related Content

What's hot (14)

Viewers also liked (20)

Similar to Inside the-browser (20)

Inside the-browser

Editor's Notes