不一样内核浏览器的差别以及浏览器渲染简介

时间 2019-11-18

原文原文链接

1、简单介绍一下什么是浏览器内核。

浏览器最重要或者说核心的部分是“Rendering Engine”，可大概译为“解释引擎”，不过咱们通常习惯将之称为“浏览器内核”。负责对网页语法的解释（如HTML、JavaScript）并渲染（显示）网页。因此，一般所谓的浏览器内核也就是浏览器所采用的渲染引擎，渲染引擎决定了浏览器如何显示网页的内容以及页面的格式信息。不一样的浏览器内核对网页编写语法的解释也有不一样，所以同一网页在不一样的内核的浏览器里的渲染（显示）效果也可能不一样，这也是网页编写者须要在不一样内核的浏览器中测试网页显示效果的缘由。php

浏览器内核不少，若是加上全部的几乎没有什么人在用的非商业的免费内核，那么可能大约有10款以上甚至更多，不过一般咱们比较常见的大约只有如下四种，下面先简单介绍一下。

Trident： IE浏览器使用的内核，该内核程序在1997年的IE4中首次被采用，是微软在Mosaic代码的基础之上修
改而来的，并沿用到目前的IE9。Trident其实是一款开放的内核，其接口内核设计的至关成熟，所以才有许多
采用IE内核而非IE的浏览器涌现（如 Maxthon、The World 、TT、GreenBrowser、AvantBrowser等）。此外，
为了方便也有不少人直接简称其为IE内核（固然也不排除有部分人是由于不知道内核名称而只好如此说）。因为IE自己的“垄断性”（虽然名义上IE并不是垄断，但实际上，特别是从Windows 95年代一直到XP初期，就市场占有率来讲IE的确借助Windows的东风处于“垄断”的地位）而使得Trident内核的长期一家独大，微软很长时间都并无更新Trident内核，这致使了两个后果——一是Trident内核曾经几乎与W3C标准脱节（2005年），二是Trident内核的大量 Bug等安全性问题没有获得及时解决，而后加上一些致力于开源的开发者和一些学者们公开本身认为IE浏览器不安全的观点，也有不少用户转向了其余浏览器，Firefox和Opera就是这个时候兴起的。非Trident内核浏览器的市场占有率大幅提升也导致许多网页开发人员开始注意网页标准和非IE浏览器的浏览效果问题。

Gecko： Netscape6开始采用的内核，后来的Mozilla FireFox (火狐浏览器) 也采用了该内核，Gecko的特色
是代码彻底公开，所以，其可开发程度很高，全世界的程序员均可觉得其编写代码，增长功能。由于这是个开源
内核，所以受到许多人的青睐，Gecko内核的浏览器也不少，这也是Geckos内核虽然年轻但市场占有率可以迅速
提升的重要缘由。　　事实上，Gecko引擎的由来跟IE不无关系，前面说过IE没有使用W3C的标准，这致使了微软内部一些开发人员的不满；他们与当时已经中止更新了的 Netscape的一些员工一块儿创办了Mozilla，以当时的Mosaic内核为基础
从新编写内核，因而开发出了Geckos。不过事实上，Gecko 内核的浏览器仍然仍是Firefox (火狐) 用户最多，
因此有时也会被称为Firefox内核。此外Gecko也是一个跨平台内核，能够在Windows、 BSD、Linux和Mac OS X
中使用。

Presto：目前Opera采用的内核，该内核在2003年的Opera7中首次被使用，该款引擎的特色就是渲染速度的优化达到了极致，也是目前公认网页浏览速度最快的浏览器内核，然而代价是牺牲了网页的兼容性。　

　实际上这是一个动态内核，与前面几个内核的最大的区别就在脚本处理上，Presto有着天生的优点，页面的所有或者部分都可以在回应脚本事件时等状况下被从新解析。

此外该内核在执行Javascrīpt的时候有着最快的速度，根据在同等条件下的测试，Presto内核执行同等Javascrīpt所需的时间仅有Trident和Gecko内核的约1/3（Trident内核最慢，不过二者相差没有多大）。
那次测试的时候由于Apple机的硬件条件和普通PC机不一样因此没有测试WebCore内核。只惋惜Presto是商业引擎，使用Presto的除开Opera之外，只剩下NDSBrowser、Wii Internet Channle、Nokia 770网络浏览器等，这很大程度上限制了Presto的发展。

Webkit：苹果公司本身的内核，也是苹果的Safari浏览器使用的内核。 Webkit引擎包含WebCore排版引擎及JavaScriptCore解析引擎，均是从KDE的KHTML及KJS引擎衍生而来，它们都是自由软件，在GPL条约下受权，同时支持BSD系统的开发。
因此Webkit也是自由软件，同时开放源代码。在安全方面不受IE、Firefox的制约，因此Safari浏览器在国内仍是很安全的。

　　限于Mac OS X的使用不普遍和Safari浏览器曾经只是Mac OS X的专属浏览器，这个内核自己应该说市场范围并不大；但彷佛根据最新的浏览器调查代表，该浏览器的市场甚至已经超过了Opera的Presto了——固然这一方面得益于苹果转到x86架构以后的人气暴涨，另外也是由于Safari 3终于推出了Windows版的缘故吧。

Mac下还有OmniWeb、Shiira等人气很高的浏览器。

　　google的chrome也使用webkit做为内核。　

　WebKit 内核在手机上的应用也十分普遍，例如 Google 的手机 Gphone、 Apple 的 iPhone， Nokia’s Series 60 browser 等所使用的 Browser 内核引擎，都是基于 WebKit。

2、浏览器渲染原理（http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html）

Web页面运行在各类各样的浏览器当中，浏览器载入、渲染页面的速度直接影响着用户体验简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。先来大体了解一下浏览器都是怎么干活的：
　　1. 用户输入网址（假设是个html页面，而且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
　　2. 浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；
　　3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
　　4. 浏览器继续载入html中<body>部分的代码，而且CSS文件已经拿到手了，能够开始渲染页面了；
　　5. 浏览器在代码中发现一个<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
　　6. 服务器返回图片文件，因为图片占用了必定面积，影响了后面段落的排布，所以浏览器须要回过头来从新渲染这部分代码；
　　7. 浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；
　　8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个css

（style.display=”none”）。杯具啊，忽然就少了这么一个元素，浏览器不得不从新渲染这部分代码；
　　9. 终于等到了</html>的到来，浏览器泪流满面……
　　10. 等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下<link>标签的CSS路径；
　　11. 浏览器召集了在座的各位

<span><ul><li>们，“大伙儿收拾收拾行李，咱得从新来过……”，浏览器向服务器请
　　求了新的CSS文件，从新渲染页面。

　　浏览器天天就这么来来回回跑着，要知道不一样的人写出来的html和css代码质量良莠不齐，说不定哪天跑着跑着就挂掉了。好在这个世界还有这么一群人——页面重构工程师，平时挺不起眼，也就帮视觉设计师们切切图啊改改字，其实背地里仍是干了很多实事的。html

说到页面为何会慢？那是由于浏览器要花时间、花精力去渲染，尤为是当它发现某个部分发生了点变化影响了布局，须要倒回去从新渲染，内行称这个回退的过程叫reflow。前端

　　 reflow几乎是没法避免的。如今界面上流行的一些效果，好比树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引发浏览器的 reflow。鼠标滑过、点击……只要这些行为引发了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引发它内部、周围甚至整个页面的从新渲染。一般咱们都没法预估浏览器到底会reflow哪一部分的代码，它们都彼此相互影响着。程序员

　　 reflow问题是能够优化的，咱们能够尽可能减小没必要要的reflow。好比开头的例子中的<img>图片载入问题，这其实就是一个能够避免的reflow——给图片设置宽度和高度就能够了。这样浏览器就知道了图片的占位面积，在载入图片前就预留好了位置。web

另外，有个和reflow看上去差很少的术语：repaint，中文叫重绘。若是只是改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引发浏览器repaint。repaint的速度明显快于 reflow（在IE下须要换一下说法，reflow要比repaint 更缓慢）。chrome

3、从浏览器的渲染原理讲CSS性能(http://hi.baidu.com/zhoumm1008/blog/item/03fa88f97fe5ddebfd037f4b.html)后端

平时咱们几乎天天都在和浏览器打交道，写出来的页面颇有可能在不一样的浏览器下显示的不同。苦逼的前端攻城师们为了兼容各个浏览器而不断地去测试和调试，还在脑子中记下各类遇到的BUG及解决方案，而咱们好像并无去主动地关注和了解下浏览器的工做原理。若是咱们对此作一点了解，我想在项目过程当中就能够根据它有效的避免一些问题以及对页面性能作出相应的改进。今天咱们主要根据浏览器的渲染原理对CSS的书写性能作一点改进（固然还有JS本篇文章暂不考虑，后面的文章会作介绍），下面让咱们一块儿来揭开浏览器的渲染原理这一神秘的面纱吧：浏览器

最终决定浏览器表现出来的页面效果的差别是：渲染引擎 Rendering Engine（也叫作排版引擎），也就是咱们一般所说的“浏览器内核”，负责解析网页语法（如HTML、JavaScript）并渲染、展现网页。相同的代码在不一样的浏览器呈现出来的效果不同，那么就颇有多是不一样的浏览器内核致使的。安全

一、解析HTML以重建DOM树（Parsing HTML to construct the DOM tree ）：渲染引擎开始解析HTML文档，转换树中的标签到DOM节点，它被称为“内容树”。

二、构建渲染树（Render tree construction）：解析CSS（包括外部CSS文件和样式元素），根据CSS选择器计算出节点的样式，建立另外一个树 —- 渲染树。

三、布局渲染树（Layout of the render tree）: 从根节点递归调用，计算每个元素的大小、位置等，给每一个节点所应该出如今屏幕上的精确坐标。

四、绘制渲染树（Painting the render tree） : 遍历渲染树，每一个节点将使用UI后端层来绘制。

主要的流程就是：构建一个dom树，页面要显示的各元素都会建立到这个dom树当中，每当一个新元素加入到这个dom树当中，浏览器便会经过css引擎查遍css样式表，找到符合该元素的样式规则应用到这个元素上。

注意了：css引擎查找样式表，对每条规则都按从右到左的顺序去匹配。看以下规则：

1	#nav li {}

看起来很快，实际上很慢，尽管这让人有点费解#_#。咱们中的大多数人，尤为是那些从左到右阅读的人，可能猜测浏览器也是执行从左到右匹配规则的，所以会推测这条规则的开销并不高。在脑海中，咱们想象浏览器会像这样工做：找到惟一的ID为nav的元素，而后把这个样式应用到直系子元素的li元素上。咱们知道有一个ID为nav的元素，而且它只有几个Li子元素，因此这个CSS选择符应该至关高效。

事实上，CSS选择符是从右到左进行匹配的。了解这方面的知识后，咱们知道这个以前看似高效地规则实际开销至关高，浏览器必须遍历页面上每一个li元素并肯定其父元素的id是否为nav。

*{}

额，这种方法我刚写CSS的也写过，却不知这种效率是差到极点的作法，由于*通配符将匹配全部元素，因此浏览器必须去遍历每个元素，这样的计算次数多是上万次！

1	ul#nav{} ul.nav{}

在页面中一个指定的ID只能对应一个元素，因此没有必要添加额外的限定符，并且这会使它更低效。同时也不要用具体的标签限定类选择符，而是要根据实际的状况对类名进行扩展。例如把ul.nav改为.main_nav更好。

1	ul li li li .nav_item{}

对于这样的选择器，以前也写过，最后本身也数不过来有多少后代选择器了，何不用一个类来关联最后的标签元素，如.extra_navitem，这样只须要匹配class为extra_navitem的元素，效率明显提高了

对此，在CSS书写过程当中，总结出以下性能提高的方案：

避免使用通配规则 如 *{} 计算次数惊人！只对须要用到的元素进行选择
尽可能少的去对标签进行选择，而是用class 如：#nav li{},能够为li加上nav_item的类名，以下选择.nav_item{}
不要去用标签限定ID或者类选择符 如：ul#nav,应该简化为#nav
尽可能少的去使用后代选择器，下降选择器的权重值 后代选择器的开销是最高的，尽可能将选择器的深度降到最低，最高不要超过三层，更多的使用类来关联每个标签元素
考虑继承 了解哪些属性是能够经过继承而来的，而后避免对这些属性重复指定规则

选用高效的选择符，能够减小页面的渲染时间，从而有效的提高用户体验（页面越快，用户固然越喜欢^_^）,你能够看一下CSS selectors Test，这个实验的重点是评估复杂选择符和简单选择符的开销。也许当你想让渲染速度最高效时，你可能会给每一个独立的标签配置一个ID，而后用这些ID写样式。那的确会超级快，也超级荒唐！这样的结果是语义极差，后期的维护难到了极点。

但说到底，CSS性能这东西对于小的项目来说可能真的是微乎其微的东西，提高可能也不是很明显，但对于大型的项目确定是有帮助的。并且一个好的CSS书写习惯和方式可以帮助咱们更加严谨的要求本身。