整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
浏览器的内核是指支持浏览器运行的最核心的程序，分为两个部分的，一是渲染引擎，另一个是 JS 引擎。渲染引擎在不同的浏览器中也不是都相同的。目前市面上常见的浏览器内核可以分为这四种：Trident（IE）、Gecko（火狐）、Blink（Chrome、Opera）、Webkit（Safari）。这里面大家最耳熟能详的可能就是 Webkit 内核了，Webkit 内核是当下浏览器世界真正的霸主。
本文我们就以 Webkit 为例，对现代浏览器的渲染过程进行一个深度的剖析。
想阅读更多优质文章请猛戳GitHub 博客。
在介绍浏览器渲染过程之前，我们简明扼要介绍下页面的加载过程，有助于更好理解后续渲染过程。
要点如下：
例如在浏览器输入https://juejin.im/timeline，然后经过 DNS 解析，juejin.im对应的 IP 是36.248.217.149（不同时间、地点对应的 IP 可能会不同）。然后浏览器向该 IP 发送 HTTP 请求。
服务端接收到 HTTP 请求，然后经过计算（向不同的用户推送不同的内容），返回 HTTP 请求，返回的内容如下：
其实就是一堆 HMTL 格式的字符串，因为只有 HTML 格式浏览器才能正确解析，这是 W3C 标准的要求。接下来就是浏览器的渲染过程。
浏览器渲染过程大体分为如下三部分：
1）浏览器会解析三个东西：
一是 HTML/SVG/XHTML，HTML 字符串描述了一个页面的结构，浏览器会把 HTML 结构字符串解析转换 DOM 树形结构。
二是 CSS，解析 CSS 会产生 CSS 规则树，它和 DOM 结构比较像。
三是 Javascript 脚本，等到 Javascript 脚本文件加载后， 通过 DOM API 和 CSSOM API 来操作 DOM Tree 和 CSS Rule Tree。
2）解析完成后，浏览器引擎会通过 DOM Tree 和 CSS Rule Tree 来构造 Rendering Tree。
3）最后通过调用操作系统 Native GUI 的 API 绘制。
接下来我们针对这其中所经历的重要步骤详细阐述
浏览器会遵守一套步骤将 HTML 文件转换为 DOM 树。宏观上，可以分为几个步骤：
浏览器从磁盘或网络读取 HTML 的原始字节，并根据文件的指定编码（例如 UTF-8）将它们转换成字符串。
在网络中传输的内容其实都是 0 和 1 这些字节数据。当浏览器接收到这些字节数据以后，它会将这些字节数据转换为字符串，也就是我们写的代码。
将字符串转换成 Token，例如：<html>、<body>等。Token 中会标识出当前 Token 是“开始标签”或是“结束标签”亦或是“文本”等信息。
这时候你一定会有疑问，节点与节点之间的关系如何维护？
事实上，这就是 Token 要标识“起始标签”和“结束标签”等标识的作用。例如“title”Token 的起始标签和结束标签之间的节点肯定是属于“head”的子节点。
上图给出了节点之间的关系，例如：“Hello”Token 位于“title”开始标签与“title”结束标签之间，表明“Hello”Token 是“title”Token 的子节点。同理“title”Token 是“head”Token 的子节点。
事实上，构建 DOM 的过程中，不是等所有 Token 都转换完成后再去生成节点对象，而是一边生成 Token 一边消耗 Token 来生成节点对象。换句话说，每个 Token 被生成后，会立刻消耗这个 Token 创建出节点对象。注意：带有结束标签标识的 Token 不会创建节点对象。
接下来我们举个例子，假设有段 HTML 文本：
复制代码
<html> <head> <title>Web page parsing</title> </head> <body> <div> <h1>Web page parsing</h1> <p>This is an example Web page.</p> </div> </body> </html>
上面这段 HTML 会解析成这样：
DOM 会捕获页面的内容，但浏览器还需要知道页面如何展示，所以需要构建 CSSOM。
构建 CSSOM 的过程与构建 DOM 的过程非常相似，当浏览器接收到一段 CSS，浏览器首先要做的是识别出 Token，然后构建节点并生成 CSSOM。
在这一过程中，浏览器会确定下每一个节点的样式到底是什么，并且这一过程其实是很消耗资源的。因为样式你可以自行设置给某个节点，也可以通过继承获得。在这一过程中，浏览器得递归 CSSOM 树，然后确定具体的元素到底是什么样式。
注意：CSS 匹配 HTML 元素是一个相当复杂和有性能问题的事情。所以，DOM 树要小，CSS 尽量用 id 和 class，千万不要过渡层叠下去。
当我们生成 DOM 树和 CSSOM 树以后，就需要将这两棵树组合为渲染树。
在这一过程中，不是简单的将两者合并就行了。渲染树只会包括需要显示的节点和这些节点的样式信息，如果某个节点是 display: none 的，那么就不会在渲染树中显示。
我们或许有个疑惑：浏览器如果渲染过程中遇到 JS 文件怎么处理？
渲染过程中，如果遇到<script>就停止渲染，执行 JS 代码。因为浏览器有 GUI 渲染线程与 JS 引擎线程，为了防止渲染出现不可预期的结果，这两个线程是互斥的关系。JavaScript 的加载、解析与执行会阻塞 DOM 的构建，也就是说，在构建 DOM 时，HTML 解析器若遇到了 JavaScript，那么它会暂停构建 DOM，将控制权移交给 JavaScript 引擎，等 JavaScript 引擎运行完毕，浏览器再从中断的地方恢复 DOM 构建。
也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件，这也是都建议将 script 标签放在 body 标签底部的原因。当然在当下，并不是说 script 标签必须放在底部，因为你可以给 script 标签添加 defer 或者 async 属性（下文会介绍这两者的区别）。
JS 文件不只是阻塞 DOM 的构建，它会导致 CSSOM 也阻塞 DOM 的构建。
原本 DOM 和 CSSOM 的构建是互不影响，井水不犯河水，但是一旦引入了 JavaScript，CSSOM 也开始阻塞 DOM 的构建，只有 CSSOM 构建完毕后，DOM 再恢复 DOM 构建。
这是什么情况？
这是因为 JavaScript 不只是可以改 DOM，它还可以更改样式，也就是它可以更改 CSSOM。因为不完整的 CSSOM 是无法使用的，如果 JavaScript 想访问 CSSOM 并更改它，那么在执行 JavaScript 时，必须要能拿到完整的 CSSOM。所以就导致了一个现象，如果浏览器尚未完成 CSSOM 的下载和构建，而我们却想在此时运行脚本，那么浏览器将延迟脚本执行和 DOM 构建，直至其完成 CSSOM 的下载和构建。也就是说，在这种情况下，浏览器会先下载和构建 CSSOM，然后再执行 JavaScript，最后在继续构建 DOM。
当浏览器生成渲染树以后，就会根据渲染树来进行布局（也可以叫做回流）。这一阶段浏览器要做的事情是要弄清楚各个节点在页面中的确切位置和大小。通常这一行为也被称为“自动重排”。
布局流程的输出是一个“盒模型”，它会精确地捕获每个元素在视口内的确切位置和尺寸，所有相对测量值都将转换为屏幕上的绝对像素。
布局完成后，浏览器会立即发出“Paint Setup”和“Paint”事件，将渲染树转换成屏幕上的像素。
以上我们详细介绍了浏览器工作流程中的重要步骤，接下来我们讨论几个相关的问题：
1.async 和 defer 的作用是什么？有什么区别?
接下来我们对比下 defer 和 async 属性的区别：
其中蓝色线代表 JavaScript 加载；红色线代表 JavaScript 执行；绿色线代表 HTML 解析。
1）情况 1<script src="script.js"></script>
没有 defer 或 async，浏览器会立即加载并执行指定的脚本，也就是说不等待后续载入的文档元素，读到就加载并执行。
2）情况 2<script async src="script.js"></script> (异步下载)
async 属性表示异步执行引入的 JavaScript，与 defer 的区别在于，如果已经加载好，就会开始执行——无论此刻是 HTML 解析阶段还是 DOMContentLoaded 触发之后。需要注意的是，这种方式加载的 JavaScript 依然会阻塞 load 事件。换句话说，async-script 可能在 DOMContentLoaded 触发之前或之后执行，但一定在 load 触发之前执行。
3）情况 3 <script defer src="script.js"></script>(延迟执行)
defer 属性表示延迟执行引入的 JavaScript，即这段 JavaScript 加载时 HTML 并未停止解析，这两个过程是并行的。整个 document 解析完毕且 defer-script 也加载完成之后（这两件事情的顺序无关），会执行所有由 defer-script 加载的 JavaScript 代码，然后触发 DOMContentLoaded 事件。
defer 与相比普通 script，有两点区别：载入 JavaScript 文件时不阻塞 HTML 的解析，执行阶段被放到 HTML 标签解析完成之后。
在加载多个 JS 脚本的时候，async 是无顺序的加载，而 defer 是有顺序的加载。
2. 为什么操作 DOM 慢？
把 DOM 和 JavaScript 各自想象成一个岛屿，它们之间用收费桥梁连接。——《高性能 JavaScript》
JS 是很快的，在 JS 中修改 DOM 对象也是很快的。在 JS 的世界里，一切是简单的、迅速的。但 DOM 操作并非 JS 一个人的独舞，而是两个模块之间的协作。
因为 DOM 是属于渲染引擎中的东西，而 JS 又是 JS 引擎中的东西。当我们用 JS 去操作 DOM 时，本质上是 JS 引擎和渲染引擎之间进行了“跨界交流”。这个“跨界交流”的实现并不简单，它依赖了桥接接口作为“桥梁”（如下图）。
过“桥”要收费——这个开销本身就是不可忽略的。我们每操作一次 DOM（不管是为了修改还是仅仅为了访问其值），都要过一次“桥”。过“桥”的次数一多，就会产生比较明显的性能问题。因此“减少 DOM 操作”的建议，并非空穴来风。
3. 你真的了解回流和重绘吗？
渲染的流程基本上是这样（如下图黄色的四个步骤）：
1. 计算 CSS 样式
2. 构建 Render Tree
3.Layout – 定位坐标和大小
4. 正式开画
注意：上图流程中有很多连接线，这表示了 Javascript 动态修改了 DOM 属性或是 CSS 属性会导致重新 Layout，但有些改变不会重新 Layout，就是上图中那些指到天上的箭头，比如修改后的 CSS rule 没有被匹配到元素。
这里重要要说两个概念，一个是 Reflow，另一个是 Repaint
重绘：当我们对 DOM 的修改导致了样式的变化、却并未影响其几何属性（比如修改了颜色或背景色）时，浏览器不需重新计算元素的几何属性、直接为该元素绘制新的样式（跳过了上图所示的回流环节）。
回流：当我们对 DOM 的修改引发了 DOM 几何尺寸的变化（比如修改元素的宽、高或隐藏元素等）时，浏览器需要重新计算元素的几何属性（其他元素的几何属性和位置也会因此受到影响），然后再将计算的结果绘制出来，这个过程就是回流（也叫重排）。
我们知道，当网页生成的时候，至少会渲染一次。在用户访问的过程中，还会不断重新渲染。重新渲染会重复回流 + 重绘或者只有重绘。
回流必定会发生重绘，重绘不一定会引发回流。重绘和回流会在我们设置节点样式时频繁出现，同时也会很大程度上影响性能。回流所需的成本比重绘高的多，改变父节点里的子节点很可能会导致父节点的一系列回流。
1）常见引起回流属性和方法
任何会改变元素几何信息 (元素的位置和尺寸大小) 的操作，都会触发回流，
2）常见引起重绘属性和方法
3）如何减少回流、重绘
复制代码
for(let i = 0; i < 1000; i++) {
// 获取 offsetTop 会导致回流，因为需要去获取正确的值
console.log(document.querySelector('.test').style.offsetTop)
}
基于上面介绍的浏览器渲染原理，DOM 和 CSSOM 结构构建顺序，初始化可以对页面渲染做些优化，提升页面性能。
综上所述，我们得出这样的结论：
参考文章
更多内容，请关注前端之巅。
今天课堂笔记主要讲的是HTML5零基础需要学习和掌握的知识点，我们一起来看主要培训课程内容：
1)CSS Bug:CSS样式在各浏览器中解析不一致的情况，或者说CSS样式在浏览器中不能正确显示的问题称为CSS bug.
2)CSS Hack: CSS中，Hack是指一种兼容CSS在不同浏览器中正确显示的技巧方法，因为它们都属于个人对CSS代码的非官方的修改，或非官方的补丁。有些人更喜欢使用patch(补丁)来描述这种行为。
3)Filter:表示过滤器的意思，它是一种对特定的浏览器或浏览器组显示或隐藏规则或声明的方法。本质上讲，Filter是一种用来过滤不同浏览器的Hack类型。
*使用Hack带来的一些副作用
降低了CSS代码的可读性，增加了代码的负担。
*设计CSS Hack和 Filter通常有两种方法
1)一种是利用浏览器自身的Bug，来隐藏或显示样式或声明;
2)另一种是利用浏览器对CSS支持的不完善，如对某些规则或语法还没有形成支持，来隐藏或显示样式。
IE6常见CSS解析Bug及hack
1)图片间隙
A)在元素中直接插入图片时，图片下方会产生约3像素的间隙(该bug出现在IE6及更低版本中)
hack1:将
#FormatImgID_0#转为块状元素，给#FormatImgID_1#添加声明：display:block;
hack2:将img设置vertical-align:top/middle/bottom;只要不为baseline
2) 双倍浮向(双倍边距)
描述：当Ie6及更低版本浏览器在解析浮动元素时，会错误地把浮向边边界加倍显示。
hack:给浮动元素添加声明：display:inline;
3)默认高度(IE6)
描述：在IE6及以下版本中，部分块元素拥有默认高度(低于16px高度)
hack1:给元素添加声明：font-size:0;
hack2：给元素添加声明：overflow:hidden;
4)百分比bug
描述：在IE6及以下版本中在解析百分比时，会按四舍五入方式计算从而导致50%加50%大于100%的情况。
hack:给右面的浮动元素添加声明：clear:right; 意思：清除右浮动。
5)表单元素高度及对齐方式不一致(IE,MOZ,C,O,S)
描述：表单元素行高对齐方式不一致
hack:给表单元素添加声明：float:left;或vertical-align:top;
2)表单元素中按钮的解析是按怪异盒模型解析的。
3)直接去掉表单控件的边框时用border:0;border:none;不能兼容ie7以下浏览器。
*透明写法
1.opacity:0~1;IE8以上的浏览器
2.filter:alpha(opacity=1~100); IE9及IE9以下的浏览器
6)列表阶梯BUG(IE6及更低版本的浏览器中)
bug1:在给的子元素中使用了Float:left;父元素中没有设置浮动属性，li阶梯状效果。
hack:给父元素设置浮动便能解决此问题
bug2:当给LI里的A转成块元素，并设置了固定高度时，且给父元素写了浮动后在IE6及更低的版本浏览器里会出现垂直显示。
hack:给a也设置左浮动便可解决。
8)鼠标指针bug
描述：cursor属性的hand属性值只有IE浏览器识别，其它浏览器不识别该声明，cursor属性的pointer属性值IE6.0以上版本及其它内核浏览器都识别该声明。
hack:如统一某元素鼠标指针形状为手型，应添加声明：cursor:pointer;
扩展内容：
鼠标指针
cursor:crosshair(十字架)
pointer(手形)
move(移动)
e-resize(左右方向)
ne-resize(向右及向上移动)
nw-resize(向上及向左移动)
n-resize(向上移动)
se-resize(向下及向右)
sw-resize(向下及向左)
s-resize(向下移动)
w-resize(向左移动)
text(文本)
wait(等待状态)
help(帮助)
浏览器大战
第一次浏览器大战发生在上个世纪90年代，微软发布了它的IE浏览器，和网景公司的Netscape Navigator浏览器大打出手。
第二次浏览器大战发生在20世纪。
战争产物：Internet Explorer 9
元老级内核之一，由微软开发，并于1997年10月首次在ie 4.0中使用，凭借其windows垄断优势，Trident市场占有率一直很高。然而垄断并非，没有竞争就没有进步，长期以往，Trident内核一度停滞不前，更新缓慢，甚至一度与W3C标准脱节。2011年，从ie 9开始，Trident开始支持HTML5和CSS 3，因此我们也经常会看到有些网站在浏览时会提示用户（在Internet Explorer 9.0+以上浏览效果最佳）。前端程序员做浏览器兼容一般也不再会考虑ie 8之前的浏览器了。
元老级内核之一，由Netscape公司Mozilla组织开发。1998年，Netscape在于IE浏览器竞争失利之后，成立了非正式组织Mozilla，由其开发新一代内核，后命名为“Gecko”。FireFox也是这班人开发出来了，因此这也就是Mozilla一直使用的内核。 Gecko的特点是代码完全公开，因此其开发程度很高，全世界的程序员都可以为其编写代码，增加功能。
这是苹果公司开发的内核，也是其旗下产品Ssfari浏览器使用的内核。Webkit引擎包含了WebCode排版引擎和JavaScriptCode解析引擎，分别是从KDE的KHTML和KJS衍生而来，它们都是自由软件，在GPL条约下授权，同时支持BSD系统开发。 Chrome、360极速浏览器以及搜狗高速浏览器也使用Webkit作为内核（在脚本理解方面，Chorome使用自己研发的V8引擎）。
这是由Google和Opera Software开发的浏览器排版引擎，Google计算将这个渲染引擎作为Chromium计划的一部分，并且在2013年4月公布了这一消息。这一渲染引擎是开源引擎Webkit中WebCore组件的一个分支，并且在Chrome（28及往后版本）、Opera（15及往后版本）和Yandex浏览器中使用
由于各大主流浏览器由不同的厂家开发，所用的核心架构和代码也很难重和，这就为各种莫名其妙的Bug(代码错误）提供了温床。再加上各大厂商出于自身利益考虑而设置的种种技术壁垒，都让CSS应用起来比想象得要麻烦。浏览器的兼容问题是我们必须去克服的。
1)图片有边框BUG
当图片加<a href=“#”></a>在IE上会出现边框
Hack:给图片加border:0;或者border:0 none;
2)图片间隙
div中的图片间隙BUG
描述：在div中插入图片时，图片会将div下方撑大大约三像素。
hack1:将</div>与<img>写在一行上；
hack2:将<img>转为块状元素，给<img>添加声明：display:block;
3) 双倍浮向（双倍边距）（只有IE6出现）
描述：当Ie6及更低版本浏览器在解析浮动元素时，会错误地把浮向边边界（margin）加倍显示。
hack:给浮动元素添加声明：display:inline;
4)默认高度（IE6、IE7）
描述：在IE6及以下版本中，部分块元素拥有默认高度（在16px左右；）
hack1:给元素添加声明：font-size:0;
hack2：给元素添加声明：overflow:hidden;
5)表单元素对齐不一致
描述：表单元素行高对齐方式不一致
hack:给表单元素添加声明：float:left;
6)按钮元素默认大小不一
描述：各浏览器中按钮元素大小不一致
hack1： 统一大小/（用a标记模拟）
hack2:input外边套一个标签，在这个标签里写按钮的样式，把input的边框去掉。
hack3:如果这个按钮是一个图片，直接把图片作为按钮的背景图即可。
7)鼠标指针bug
描述：cursor属性的hand属性值只有IE9以下浏览器识别，其它浏览器不识别该声明，cursor属性的pointer属性值IE6.0以上版本及其它内核浏览器都识别该声明。
hack: 如统一某元素鼠标指针形状为手型，
应添加声明：cursor:pointer cursor: ;
auto默认
crosshair加号
text文本
wait等待
help帮助
progress过程
inherit继承
move移动
ne-resize向上或向右移动
pointer手形
8)透明属性
兼容其他浏览器写法：opacity:value;(value的取值范围0-1; 例：opacity:0.5;)
IE浏览器写法：filter:alpha(opacity=value);取值范围 1-100(整数)
1.下划线属性过滤器
当在一个属性前面增加了一个下划线后，由于符合标准的浏览器不能识别带有下划线的属性而忽略了这个声明，但是在IE6及更低版本浏览器中会继续解析这个规则。
语法：选择符{_属性：属性值；}
2. !important
关键字过滤器 它表示所附加的声明具有最高优先级的意思。但由于IE6及更低版本不能识别它， 我们可以利用IE6的这个Bug作为过滤器来兼容ＩＥ６和其它标准浏览器。
语法：选择符{属性：属性值!important;}
3. *属性过滤器
当在一个属性前面增加了*后，该属性只能被IE7浏览器识别，其它浏览器混略该属 性的作用。
语法：选择符{*属性：属性值；}
4. ：IE版本识别；其它浏览器都不识别
语法：选择符{属性：属性值;}
5. >5. \0 : IE8 及以上版本识别；其它浏览器都不识别
*请认真填写需求信息，我们会在24小时内与您取得联系。
