［学习笔记］浏览器渲染原理

一.浏览器的工作过程

1.资源下载html文件

http库
客户端
请求
网络流
html解析

外部文件（何时下载，端口、网速有限，如何下载最优？）

1. chrome有限下载head标签，下载完成才会解析body（重要）

2. 服务器端 flush。

串行解析服务器送来的东西。因此可以分成几部分。如微博，服务器并行处理，先处理完先渲染。因此加载顺序不定。

3. new Image().src = …..

    不加入dom树就可发起请求（唯一元素），打日志。

    Imag标签可能被回收，请求就会断掉。因为是垃圾，没有变量没有加入dom中。

    有三个事件onload   onerror   处理（垃圾回收）

4. defer VS async

    延迟 dom ready前一段时间 一定执行

    异步 不知道什么时候执行完

5. script标签

6. document.Write

 

资源优先级

1. script                  2.Object／img／iframe               3.link［rel＝prefetch］预加载

 

脚本依赖

1. 下载阻塞
2. 执行阻塞 一次6－8个请求，为了减轻服务器负担

 

Socket 重用

三次握手，三次网络延时，少握手

    1．connection： keep－alive 不断掉之前的路

    2.content－length： 告诉浏览器传了多少，浏览器知道是多少拿多少。

3.Transfer－encoding：如果文件太大不好计算大小的话，一部分一部分的给，当有一次是0时，就没有了

 

正确性保证

content－md5: 但是现在浏览器不用，即使不对也会渲染，除非自己做一些软件。

          断点续传

                            accept－range： 知道有2－8

                            content－range： 服务器给1-5， 自己拼 拼完再要 再拼

 BS的精髓——缓存

验证型缓存：告诉服务器现在的版本，如果是最新，会返回304。  如果不是，服务器会给最新的

Last－Modified&If－modified－since／If－Unmodified－since

非验证型缓存：只存一次，再也不问服务器。但可能会造成服务器与客户端版本错位。解决办法：设置时间定时更新

       Cache－Control

       Expires

缓存失效

       Vary／Via／

面试题：max－age＝0VSno－cache

无非验证型缓存，有验证型。要求浏览器向服务器验证缓存

所有的都失效，要求浏览器向服务器验证全新内容

2.Html解析 (Dom)

获取数据流，变成浏览器识别，js可操作的格式——dom

1.    序列化数据

2.    转义处理

3.    标签匹配为树

dom操作回溯至标签匹配

用document.write会毁掉之前的html流，回溯至序列化（避免）

3.Css计算（渲染树）

元素－匹配样式

选择器匹配是从右到左解析的

1.    省内存，匹配效率优化

（java 对字符串是对象共享的）

a.    Webkit  不精确

样式共享，循环输出的元素样式是一样的。

两个元素要符合很多条件：

无id

鼠标状态相同

b.    Firefox  精确，但算法很复杂

Rule tree＋stylecontext tree

样式树与dom树结合形成第三种树

 

2.    计算

dom树      渲染树

a.    元素没有渲染对象

b.    一个元素多个渲染对象 li html select inputfile

c.     通过css改变渲染对象 displaynone       ：after

  

3.布局

a.    流布局

inline-block是内联元素
float clear
position

b.    html三条流

文档、浮动、定位

c.     其他

list－item，run－in

d.    table布局

 

流式布局 VS table布局

a．        坐标系左上00，右下正坐标，做地图转换坐标很复杂

b．        布局是递归

c．         流布局，自左向右，自上而下。后面的不会影响前面的

d．        table布局需要回溯，知道每个单元格大小才能完成整个布局。复杂度太高，性能很低。

现在性能已经提高，建议：该用table要用，如果实现一个布局需要用div、float、position很烦，但是table很快就用table。

全局Reflow

a．        整个rendertree全部重新计算布局

b．        全局布局样式变更如全部字体颜色变化

c．         窗口大小变化

局部Reflow

a．        仅标识为needlayout的渲染元素计算布局

同步reflow

a．        全局的同步进行，会卡

b．        读取offsetWidth等属性（因此要尽量减少次数）

异步reflow

a．        局部的异步

b．        firefox 任务进入线程队列，调度器执行

c．         webkit 定时遍历rendertree布局所有needlayout元素

reflow任务可合并，多个样式修改只作一次，但有阈值，不能太多。

 

父元素确定大小，坐标

遍历子元素， x／y属性，layout函数

累计子元素width padding

 

5.渲染

transform 代替left  right属性 提高性能

visibility 比display好

渲染顺序 

ff  display list

二.浏览器对细节的具体优化手段

1.    Firefox

2.    Webkit／Chrome