浏览器内核的解析和对比

出处：http://www.qdfuns.com/notes/16583/cae477c1b5500ba9e21ab94bc17cc771.html

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

内核分类
Trident(IE内核)：该内核程序在1997年的IE4中首次被采用，是微软在Mosaic代码的基础之上修改而来的，并沿用到IE11，也被普遍称作”IE内核”。Trident实际上是一款开放的内核，其接口内核设计的相当成熟，因此才有许多采用IE内核而非IE的浏览器(壳浏览器)涌现。
由于IE本身的“垄断性”（虽然名义上IE并非垄断，但实际上，特别是从Windows 95年代一直到XP初期，就市场占有率来说IE的确借助Windows的东风处于“垄断”的地位）而使得Trident内核的长期一家独大，微软很长时间都并没有更新Trident内核，这导致了两个后果——一是Trident内核曾经几乎与W3C标准脱节（2005年），二是Trident内核的大量 Bug等安全性问题没有得到及时解决，然后加上一些致力于开源的开发者和一些学者们公开自己认为IE浏览器不安全的观点，也有很多用户转向了其他浏览器，Firefox和Opera就是这个时候兴起的。非Trident内核浏览器的市场占有率大幅提高也致使许多网页开发人员开始注意网页标准和非IE浏览器的浏览效果问题。
补充：IE从版本11开始，初步支持WebGL技术。IE8的JavaScript引擎是Jscript，IE9开始用Chakra，这两个版本区别很大，Chakra无论是速度和标准化方面都很出色。
Trident内核的常见浏览器有：[1] 　IE6、IE7、IE8（Trident 4.0）、IE9（Trident 5.0）、IE10（Trident 6.0）；[1] 360安全浏览器（1.0-5.0为Trident，6.0为Trident+Webkit，7.0为Trident+Blink）360极速浏览器（7.5之前为Trident+Webkit,7.5为Trident+Blink）猎豹安全浏览器（1.0-4.2版本为Trident+Webkit，4.3版本为Trident+Blink）傲游浏览器（傲游1.x、2.x为IE内核，3.x为IE与Webkit双核）、百度浏览器（早期版本）、世界之窗浏览器[2] （最初为IE内核，2013年采用Chrome+IE内核）、2345浏览器、腾讯TT、淘宝浏览器、采编读浏览器、搜狗高速浏览器（1.x为Trident，2.0及以后版本为Trident+Webkit）、阿云浏览器（早期版本）、瑞星安全浏览器、Slim Browser、 GreenBrowser、爱帆浏览器（12 之前版本）、115浏览器、155浏览器、闪游浏览器、N氧化碳浏览器、糖果浏览器、彩虹浏览器、瑞影浏览器、勇者无疆浏览器、114浏览器、蚂蚁浏览器、飞腾浏览器、速达浏览器、佐罗浏览器、海豚浏览器（iPhone/iPad/Android）、UC浏览器（Blink内核+Trident内核）等。
其中部分浏览器的新版本是“双核”甚至是“多核”，其中一个内核是Trident，然后再增加一个其他内核。国内的厂商一般把其他内核叫做“高速浏览模式”，而Trident则是“兼容浏览模式”，用户可以来回切换。

Gecko(Firefox内核)：Netscape6开始采用的内核，后来的Mozilla FireFox(火狐浏览器) 也采用了该内核，Gecko的特点是代码完全公开，因此，其可开发程度很高，全世界的程序员都可以为其编写代码，增加功能。因为这是个开源内核，因此受到许多人的青睐，Gecko内核的浏览器也很多，这也是Gecko内核虽然年轻但市场占有率能够迅速提高的重要原因。
事实上，Gecko引擎的由来跟IE不无关系，前面说过IE没有使用W3C的标准，这导致了微软内部一些开发人员的不满；他们与当时已经停止更新了的 Netscape的一些员工一起创办了Mozilla，以当时的Mosaic内核为基础重新编写内核，于是开发出了Gecko。不过事实上，Gecko 内核的浏览器仍然还是Firefox (火狐) 用户最多，所以有时也会被称为Firefox内核。此外Gecko也是一个跨平台内核，可以在Windows、 BSD、Linux和Mac OS X中使用。
补充：JavaScript引擎是SpiderMonkey。
Gecko内核常见的浏览器：[1] Mozilla Firefox、Mozilla SeaMonkey、Epiphany（早期版本）、Flock（早期版本）、K-Meleon

Presto(Opera前内核) (已废弃)： Opera12.17及更早版本曾经采用的内核，现已停止开发并废弃，该内核在2003年的Opera7中首次被使用，该款引擎的特点就是渲染速度的优化达到了极致，然而代价是牺牲了网页的兼容性。
实际上这是一个动态内核，与前面几个内核的最大的区别就在脚本处理上，Presto有着天生的优势，页面的全部或者部分都能够在回应脚本事件时等情况下被重新解析。此外该内核在执行Javascrīpt的时候有着最快的速度，根据在同等条件下的测试，Presto内核执行同等Javascrīpt所需的时间仅有Trident和Gecko内核的约1/3（Trident内核最慢，不过两者相差没有多大），本文的其中一个修改者认为上述测试信息过于老旧且不完整，因为他曾做过的小测试显示Presto部分快部分慢，各内核总体相当。那次测试的时候因为Apple机的硬件条件和普通PC机不同所以没有测试WebCore内核。只可惜Presto是商业引擎，使用Presto的除开Opera以外，只剩下NDSBrowser、Wii Internet Channle、Nokia 770网络浏览器等，这很大程度上限制了Presto的发展。
Opera现已改用Google Chrome的Blink内核。

Webkit(Safari内核,Chrome内核原型,开源):它是苹果公司自己的内核，也是苹果的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、360极速浏览器以及搜狗浏览器高速模式也使用webkit作为内核(在脚本理解方面，Chrome使用自己研发的V8引擎)。WebKit 内核在手机上的应用也十分广泛，例如 Google 的手机 Gphone、 Apple 的iPhone， Nokia’s Series 60 browser 等所使用的 Browser 内核引擎，都是基于 WebKit。
WebKit内核常见的浏览器：[1] Apple Safari (Win/Mac/iPhone/iPad)、Symbian手机浏览器、Android 默认浏览器，

排版引擎

WebCore是苹果公司开发的排版引擎，它是在另外一个排版引擎“KHTML”的基础上而来的。使用WebCore的主要有Safari，此外还有OmniWeb、Shiira、Swift等。Safari现支持Windows，但效果不如iOS上的。
KHTML

KHTML，是HTML网页排版引擎之一，由KDE所开发。
KDE系统自KDE2版起，在档案及网页浏览器使用了KHTML引擎。该引擎以C++编程语言所写，并以LGPL授权，支援大多数网页浏览标准。由于微软的Internet Explorer的占有率相当高，不少以FrontPage制作的网页均包含只有IE才能读取的非标准语法，为了使KHTML引擎可呈现的网页达到最多，部分IE专属的语法也一并支援。
KHTML拥有速度快捷的优点，但对错误语法的容忍度则比Mozilla产品所使用的Gecko引擎小。
苹果电脑于2002年采纳了KHTML，作为开发Safari浏览器之用，并发布所修改的最新及过去版本源代码。后来发表了开放源代码的WebCore及WebKit引擎，它们均是KHTML的衍生产品，在开发网站列出引擎改变内容，并会传回至KDE计划。由于两个衍生产品各走不同路线，使两者源代码偏离，在与KDE交换更新会出现困难。其中一个原因，是苹果在对外公开源代码之前，以一年时间编修他们的KHTML。另外，苹果传送更新至KDE计划的方式，多是一口气把大量改动一起传送，KDE在整理资料也出现一定的困难，及后苹果表示会以CVS格式来传送。再者，苹果所作出的改动包括Mac OS X系统独有的事物，如Objective-C、KWQ等，在Linux及KHTML是没有的。但KDE方面仍透过这些改动，为KHTML加入新功能及加快其排版速度。
基于KHTML内核的内核：WebKit、WebCore。

js引擎
不同浏览器有不同的JS引擎：
WebKit , Safari浏览器       ->SquirrelFish Extreme，
Firefox                                  àTraceMonkey引擎
Google Chrome                   àV8引擎，（C++）
Opera                                  -> Carakan
Mozilla                         ->SpiderMonkey(C语言)
Mozilla                               à Rhino( Java)
Mozilla                         ->JaegerMonkey

SEE (Simple ECMAScript Engine) C语言开发的轻量级的 ECMAScript (JavaScript) 解析器和实时运行环境

(1)javascript 解析引擎 V8（C++）

http://www.oschina.net/p/v8
V8 是 Google 发布的开源 JavaScript 引擎，采用 C++ 编写，在 Google 的 Chrome 浏览器中被使用。V8 引擎可以独立运行，也可以用来嵌入到 C++ 应用程序中执行。\

(2)javascript 脚本引擎 SpiderMonkey (c语言)

http://www.oschina.net/p/spidermonkey
SpiderMonkey是Mozilla项目的一部分，是一个用C语言实现的JavaScript脚本引擎，另外还有一个叫做Rhino的Java版本。
为了在SpiderMonkey中运行JavaScript代码，应用程序必须有三个要素：JSRuntime，JSContext和全局对象。
运行时环境

JSRuntime，为其中的JavaScript变量、对象、脚本和应用程序中使用的上下文分配空间。每个JSContext和脚本中的每个对象都生活在一个 JSRuntime中。他们不能转移到其他运行时上或在与其它运行时共享。一般来说大多数应用程序只需要一个运行时环境。
JSContext，就像是一台小机器，它涉及JavaScript代码和对象的很多东西。它可以编译和执行脚本、获取和设置对象属性、调用 JavaScript函数、一种类型转换为另一种JavaScript数据、创建对象，等等。几乎所有JSAPI函数都要一个JSContext*作为其第一个参数，就像<stdio.h>中的大多数函数都需要FILE*一样.
全局对象包含所有可以在JavaScript代码中使用的类、函数和变量。
当JavaScript代码要做一些事时，比如window.open("http://www.mozilla.org/")，实际上它是在访问一个全局属性（全局对象的属性），在这里是window。
脚本能看到的全局属性完全由应用程序控制。应用程序首先创建一个对象并加入JavaScript标准类，如Array和Object。然后加入任何程序想加入的自定义的类、函数和变量（象这里的window）。应用程序每次运行js脚本（例如使用JS_EvaluateScript）时提供了该脚本使用的全局对象。至于脚本，它也可以创建自己全局函数和变量。所有的这些函数、类和变量都作为属性存储在全局对象中。

(3)JS 解析器 rhino(Java)
http://www.oschina.net/p/rhino
Rhino是用纯Java写成的JavaScript的开放源代码实现。它最常被用于嵌入Java应用程序，以便为终端用户提供脚本的能力。

（4）JavaScript 解析引擎 Simple ECMAScript Engine(C语言)
http://www.oschina.net/p/SEE
SEE(Simple ECMAScript Engine) 是一个用C语言开发的轻量级的 ECMAScript (JavaScript) 解析器和实时运行环境。支持ECMAScript Edition 3, JavaScript 1.5 。
(5) JavaScript引擎 SquirrelFish Extreme
http://www.oschina.net/p/squirrelfish+extreme
几周前 Google Chrome 发布之后，因其创新的 UI 以及出色的 JavaScript 执行效率而备受赞誉。最近，作为 Safari 与 Chrome 浏览器内核的 WebKit 发布了一个新 JavaScript 引擎，SquirrelFish Extreme，经过测试，该引擎的在执行速度上明显超过 Chrome 的 V8。下图是性能的比较
(6) JavaScript引擎 Carakan
http://www.oschina.net/p/carakan
Opera全新JS引擎Carakan，目前数度是其他已存在JavaScript引擎（基于SunSpider）的2.5倍。其在转化为本地机器代码时专门针对正则表达式做了优化，有意思的是，Chrome浏览器也刚刚宣布了此点。
Carakan引擎的三个显著新特性：
1.基于寄存器的字节码：之前的引擎“ECMAScript”使用的是基于堆栈字节码指令集，这种基于对堆栈存取的方法对于生成字节码是比较简单的。
在新的引擎里，我们采用了基于寄存器的字节码指令集，这种方式采用了固定大小的寄存器，每次操作都可以访问任意的寄存器，更少的指令被执行并且不会拷贝大量的数据。
2.本地代码生成：我们将整个或部分“ECMAScript”引擎编译到本地代码中以达到更快的执行速度。
3.自动对象分类：在新的引擎中每个对象都是被封装成类以存取不同的数据，这些类的划分是与原型保持一致的。
每个浏览器的JS引擎都不一样吗？
现在每个浏览器基本上都有自己的JS引擎（非浏览器引擎）了，如Firefox浏览器的TraceMonkey引擎，Google Chrome浏览器的V8引擎，Safari浏览器有SquirrelFish Extreme，目前又增加了Opera的Carakan。

(7) 新一代JavaScript引擎 TraceMonkey
http://www.oschina.net/p/tracemonkey
TraceMonkey是套开放源代码、以C++语言所编写的新一代JavaScript引擎，于2008年8月23日正式发布。目前为Mozilla的Firefox网页浏览器3.5、3.6版本所使用。
TraceMonkey采用了尔湾加州大学团队Andreas Gal、Michael Bebenita、Mason Chang和Gregor Wagner所贡献的“Tracing”技术，Andreas Gal目前为TraceMonkey的项目领导人、以及Mozilla和Adobe所合作的Tamarin计划所开发的“Nanojit”技术。

(8) JavaScript引擎 JaegerMonkey
http://www.oschina.net/p/jaegermonkey
Mozilla预计将在9月1日发布JaegerMonkey引擎，因此JaegerMonkey将被整合到Firefox 4.0。
V8基准测试显示，JaegerMonkey引擎积分为6829 ms，TraceMonkey引擎积分为6841 ms。Sunspider测试显示，JaegerMonkey引擎仍然要落后于TraceMonkey引擎——754 ms vs. 718 ms，而且JaegerMonkey引擎运行速度仍然落后于Webkit浏览器，Chrome和Safari的积分都要低于400 ms，Chrome浏览器的积分甚至逼近300 ms。Opera的积分也低于300s。
JaegerMonkey引擎在今年初发布是，其目标是突破Sunspider测试的500 ms大关。当然，这已经无法满足一般用户的需求了，毕竟连IE9开发版积分都已经低于500 ms。Mozilla还表示，JaegerMonkey引擎的目标是要超越竞争浏览器，这就意味着Mozilla的目标是300ms以下。
Mozilla称，JaegerMonkey是重新编写的，过去8周的时间JaegerMonkey已经有很大的改进。在下面6周的时间，Mozilla将完善JaegerMonkey引擎，为9月1日顺利发布做好充分地准备。
Mozilla宣传，JaegerMonkey引擎的运行速度是竞争浏览器10多倍。

(9) Web浏览器引擎 WebKit
http://www.oschina.net/p/webkit
WebKit是开源的Web浏览器引擎，苹果的Safari、谷歌的Chrome浏览器都是基于这个框架来开发的。WebKit 还支持移动设备和手机，包括iPhone和Android手机都是使用WebKit做为浏览器的核心。

（10）WebKitGTK＋
http://www.oschina.net/p/webkitgtk
WebKitGTK＋是可移植渲染引擎WebKit在GTK+平台下的接口。

浏览器渲染原理

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脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个

（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
　　9. 终于等到了</html>的到来，浏览器泪流满面……
　　10. 等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下<link>标签的CSS路径；
　　11. 浏览器召集了在座的各位
<span><ul><li>们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请
　　求了新的CSS文件，重新渲染页面。
浏览器每天就这么来来回回跑着，要知道不同的人写出来的html和css代码质量参差不齐，说不定哪天跑着跑着就挂掉了。好在这个世界还有这么一群人——页面重构工程师，平时挺不起眼，也就帮视觉设计师们切切图啊改改字，其实背地里还是干了不少实事的。

说到页面为什么会慢？那是因为浏览器要花时间、花精力去渲染，尤其是当它发现某个部分发生了点变化影响了布局，需要倒回去重新渲染，内行称这个回退的过程叫reflow。
reflow几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。通常我们都无法预估浏览器到底会reflow哪一部分的代码，它们都彼此相互影响着。

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

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

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

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

最终决定浏览器表现出来的页面效果的差异是：渲染引擎 Rendering Engine（也叫做排版引擎），也就是我们通常所说的“浏览器内核”，负责解析网页语法（如HTML、JavaScript）并渲染、展示网页。相同的代码在不同的浏览器呈现出来的效果不一样，那么就很有可能是不同的浏览器内核导致的。

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

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

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

4、绘制渲染树（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。

1 *{}
额，这种方法我刚写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书写习惯和方式能够帮助我们更加严谨的要求自己。

浏览器内核的优缺点

Trident：这种浏览器内核是IE浏览器用的内核，因为在早期IE占有大量的市场份额，所以这种内核比较流行，以前有很多网页也是根据这个内核的标准来编写的，但是实际上这个内核对真正的网页标准支持不是很好，甚至在2005年，与网页标准制定组织(W3C理事会)所制定的标准发生了脱节，同时 Trident 内核本身的BUG比较多，对一些符合W3C标准的网页代码支持不是很好，这在早期的IE版本中比较明显，比如IE5.5以前(包括IE5.5)，其实IE6对W3C标准的支持也不是很好，而我们现在很多人都在使用IE6，事实上它也属于一个比较早的版本。

但是由于IE的高市场占有率，微软也很长时间没有更新Trident内核，这导致了二个结果
1，Trident内核和W3C标准脱节。
2，Trident内核的大量Bug等安全问题没有得到解决，加上一些专家学者公开自己认为IE浏览器不安全的观点，使很多用户开始转向其他浏览器，FF,Opera就是这时期兴起的。
Gecko：这是Firefox 和 Flock 所采用内核，这个内核的优点就是功能强大、丰富，可以支持很多复杂网页效果和浏览器扩展接口，但是代价是也显而易见就是要消耗很多的资源，比如内存。
Presto：Opera 采用的是 Presto内核，Presto内核被称为公认的浏览网页速度最快的内核，这得益于它在开发时的天生优势，在处理JS脚本等脚本语言时，会比其他的内核快3倍左右，缺点就是为了达到很快的速度而丢掉了一部分网页兼容性。

Webkit：Webkit 是 Safari 采用的内核，不过 Safari 是苹果系统下的浏览器(虽然也有windows版，但是比较少)，所以只简单介绍一下这个内核的优点和缺点，优点就是网页浏览速度较快，虽然不及 Presto 但是也胜于 Gecko 和 Trident，缺点是对于网页代码的容错性不高，也就是说对网页代码的兼容性较低，会使一些编写不标准的网页无法正确显示。

浏览器内核的解析和对比相关推荐

JavaScript重难点解析5（对象高级、浏览器内核与事件循环模型（js异步机制））
JavaScript重难点解析5(对象高级.浏览器内核与事件循环模型(js异步机制) 对象高级对象创建模式 Object构造函数模式对象字面量模式工厂模式自定义构造函数模式构造函数+原型的组 ...
http协议与https协议+UDP协议和TCP协议+WebSocket协议下服务端主动去发送信息+对称加密与非对称加密+get和post请求方式区别详解+浏览器内核以及jsj解析引擎
TCP和UDP协议是TCP/IP协议的核心. 在TCP/IP网络体系结构中,TCP(传输控制协议,Transport Control Protocol).UDP(用户数据报协议,User Data P ...
腾讯QQ手机浏览器内核开放
腾讯QQ手机浏览器X5内核面向移动App开放,为内置浏览服务的APP开发者提供加速和安全解决方案.据悉, 腾讯X5浏览服务由X5内核和相关云服务组成,基于Webkit优化和X5内核包含的web引擎技术 ...
[科普文] 关于浏览器内核的一些小知识，明明白白选浏览器！（转）
原文出处:http://www.iplaysoft.com/browsers-engine.html 浏览器是我们每天几乎都必须使用的软件产品,可是对于自己每天都接触的浏览器,很多同学其实对其一无所知 ...
关于浏览器内核你不得不了解的事
导读浏览器是我们每天几乎都必须使用的软件产品,可是对于自己每天都接触的浏览器,很多同学其实对其一无所知.今天就跟大家说说关于浏览器内核的一些事儿吧,好让你了解多一点稍微内在的东西. 接下来主要介绍一 ...
通过QQ浏览器内核看browser性能优化
内容来源:2017年6月24日,腾讯前端高级工程师凌实在"腾讯Web前端大会 TFC 2017 "进行<从浏览器内核看性能优化>演讲分享.IT大咖说作为独家视频合作方, ...
关于浏览器内核的一些小知识，明明白白选浏览器！
浏览器是我们每天几乎都必须使用的软件产品,可是对于自己每天都接触的浏览器,很多同学其实对其一无所知.今天异次元就跟大家说说关于浏览器内核的一些事儿吧,好让你了解多一点稍微内在的东西. 在下面的文章中主 ...
【浏览器】众浏览器内核区别
浏览器是我们每天几乎都必须使用的软件产品,可是对于自己每天都接触的浏览器,很多同学其实对其一无所知.今天异次元就跟大家说说关于浏览器内核的一些事儿吧,好让你了解多一点稍微内在的东西. 在下面的文章中主 ...
浏览器内核-渲染引擎、js引擎
一个完整的浏览器包含浏览器内核和浏览器的外壳(shell).浏览器核心--内核分成两部分:渲染引擎和js引擎.由于js引擎越来越独立,内核就倾向于只指渲染引擎. 1 浏览器组成结构浏览器一般由七个模 ...
浏览器内核和性能优化总结
浏览器内核和性能优化总结对于当下主流浏览器,很多人并不清楚它们内核具体是什么,有何特点:有的人编写html和CSS代码时,乱写一通,殊不知错误的写法会消耗浏览器更多的性能,导致加载变慢. 我从网上找 ...

浏览器内核的解析和对比

浏览器内核的解析和对比相关推荐

最新文章

热门文章