对浏览器内核的一点认识（无废话版）
两大流派1、IE 的Trident
2、Firefox 的Gecko
浏览器的内核大类
1、Trident
2、Gecko//Gecko核心设计成熟，由于其本身OpenSource，是目前开发程度最好的浏览器。
3、Presto//Oprera的Presto
4、WebCore//WebCore和khtml没有本地Window版本，不过，由于khtml本身不大，在移动设备上存在市场机会。
浏览器开发的两大领域
1、浏览器的外壳开发
2、浏览器的内核开发
难度VS:
相对而言内核开发更简单一些，因为其用户需求简单而明确，面对的使用者也都是程序员；
外壳开发要面对最终用户，要考虑适应不同的用户使用习惯，特别是还要和各种弹出广告的网站做斗争。
其实内核开发和外壳开发很多地方是相通的，外壳开发者可以在非常短的时间内成为Gecko内核的开发者。
特点VS：内核开发和外壳开发还是有很多不同的，其中最大的区别在于引擎的可信程度，
在外壳开发时，可以假设完全信任渲染引擎，假设其没有Bug；
浏览器内核开发时，这些假设不存在。
对于程序员的要求也有很大的不同，特别是浏览器的DOM、插件、Layout和JavaScript模块，这些模块的部分代码对于性能的要求非常严格。
在发行代码中多写了一句调试用的printf可能会导致CPU占有率增加了接近30%。而同样的问题，在外壳开发中则很少会遇到。
在外壳开发中的鼠标手势、广告过滤和书签管理等功能在内核开发中根本不会遇到，
结论：虽然外壳和内核都是浏览器开发，但实际上是截然不同的两种软件。
Gecko多说一点
缺点：系统各部分和JavaScirpt绑定的太紧，导致很难加入对新的脚本语言的支持。
Gecko内核的浏览器两大流派
1\以Mozilla Firefox为代表的，用XUL作为界面描述语言的浏览器：
这类浏览器往往继承了Firefox扩展性好的优点，早前的Madfox和Albatross就是这一类型的浏览器。
其中，Win32平台上相对比较好的是Orca Browser，其实现了对应于IE平台的浏览器 Avant Browser 90％以上的功能。
2\是使用本地图形库作为界面的Gecko内核的浏览器：
其中有Linux平台上epiphany、Galeon等；在win32上由Orca Browser、K-Meleon等。
采用本地图形库的浏览器资源占用较少、速度相对较快，这一点和IE外壳浏览器一样，不过缺少了采用XUL作界面带来的扩展性。
由于Mozilla的嵌入接口提供的对外接口相对有限，导致目前使用Gecko做内核的采用本地图形库的浏览器的功能都相对有限。
基于Firefox 的特点再多说一点
1\最大的优势，全部源代码开放
2\渲染方面的优势，由于Firefox使用了动态布局引擎，其显示网页内容的速度比IE 快的多。
3\安全方面，不认为Firefox会比IE好多少，就其实现上，也并没有为安全做特别的设计。如果FF有IE一样的用户基数，也会有同样多的漏洞。不过，由于开源的原因，用户基数的增加同时也会带来开发者的增加，考虑到这些因素，总体而言Firefox将更安全。
与IE的对比
在内核层面，在同样都有源码的前提下，Firefox对DOM对象的扩展没有IE方便，
在JavaScript方面，Firefox比IE强大，早期的Albatross其中有一部分IE特性的支持就是通过脚本来实现的。
前瞻
未来浏览器终将消失，扮演和.net平台和JavaVM类似的角色。
开发浏览器的素质
开发浏览器内核并不难，一个有中等c++开发经验的程序员学习1-2个月就可以上手。
开发Firefox浏览器外壳（做扩展）则相对简单一些，有一定的网页制作基础就可以了。
大虫要强调的是数学和基础知识在程序开发中的重要性 本帖最后由 faunus 于 2008-12-20 16:50 编辑
再说说浏览器的五大
1、Microsoft
//排版引擎
Trident
Tasman//Internet Explorer forMac
//流览器
InternetExplorer
//JavaScript引擎
...
2、Mozilla
//排版引擎
Gecko
/*
Firefox2及以上、K-Meleon
Gecko 1.9 使用跨平台的 Cairo 渲染框架，
对 SVG 的巨大改进简化了代码并引入一些非常 Cool的功能，
如全页缩放，同时，重构的 reflow 算法，让 Gecko 通过 Acid 2 测试成为可能。
Mozilla还非常显著地降低了对内存的占用，甚至超越了 Safari 和 Opera。
*/
//流览器
Firefox
//JavaScript引擎
SpiderMonkey//
/*
是由C语言操作的JavaScript引擎，它支持JS1.4和ECMAScript-262规范。
*/
tracemonkey//firefox 3.1bpre
/*firefox的tracemonkey已经在很多运算方面超过了强大的v8，
只是在字符串的拼接方面的运算稍逊一筹，两者的结果已经很接近，
几乎是一个等级的javascript引擎了。
*/
3、Apple
//排版引擎
WebKit
/*
Webkit 是一个开源的HTML 渲染引擎，由苹果公司基于 KDE 的 KHTML 项目开发而成。
*/
//流览器
Safari
//JavaScript引擎
...
4、OperaSAS
//排版引擎
Presto//Opera 7.0及以上使用
//流览器
Opera
//JavaScript引擎
...
5、Google
//排版引擎
Webkit
//流览器
chrome
//JavaScript引擎
V8 我更喜欢外观的开发。小而有用。 MARK一下
CHROME|FIREFOX|IE浏览器观察
http://www.iechrome.com/ 本帖最后由 faunus 于 2008-12-20 15:30 编辑
关于javascrip引擎的一点认识
1、Rhino
Rhino是一个开源的JavaScript实现，它完全使用Java语言开发，可以用于嵌入到Java应用程序中以向终端用户提供脚本功能。Rhino通过分析Javascript语法，并加以执行，执行后的结果可以通过它提供的API接口取得。
对于需要使用自定义脚本的应用，Rhino不愧是一个好的选择。因为：
- 相对于自定义脚本然后通过自定义解释器来说，Rhino可以解释现成的Javascript语法并加以执行，为我们节省大量时间和精力。
- Javascript本身比较成熟稳定。
- Rhino支持JavaScript 1.6标准
- 允许直接在Java代码中嵌入script。
- 其它很多功能。
J2SE 6已经将Rhino作为默认的Javascript引擎。
2、SpiderMonkey
SpiderMonkey, 是 Mozilla 项目的一部分（也是Firefox中的JavaScript引擎）, 是一个执行JavaScript脚本的引擎. 它用 C 实现。还有一个叫做Rhino的Java版本。此外.Net 下也有 SpiderMonkeyDotNet，不过目前还不太成熟。
3、 如何使用引擎
JS引擎一般作为共享库使用，应用程序调用引擎提供的API函数。引擎API函数大致分为以下几种：数据类型操作、RunTime控制、类与对象的创建和维护、函数与脚本执行、字符串操作、错误处理、安全控制、Debug支持。一般情况下，在你的应用程序中只需使用某几类函数。例如，在进行JS调用之前你必须调用JS_NewRuntime函数来创建并初始化JS引擎。有些类型的函数，象安全控制类，提供可选择的特征。
从概念上讲，JS引擎是你系统上的一个共享资源。通过将引擎API调用嵌入到应用程序中（包含jsapi.h文件），你可以请求JS引擎进行操作。接下来，引擎处理你的请求，并将结果或状态信息返回给你的应用程序。
例如，假定你在使用JS引擎自动化应用程序，脚本应用程序鉴别用户并设置权限。首先，应用程序创建JS对象，该对象描述用户信息，包括姓名、ID、权限和可用的函数列表。在这种情况下，应用程序首先调用JS_NewObject创建对象。当JS引擎创建对象后，返回一个指针给应用程序。应用程序再调用JS引擎执行脚本。在创建用户对象后，应用程序即刻传递脚本给JS_EvaluateScript以便编译和运行。脚本或许取得并效验用户信息，然后建立用户存取的权利。
JS引擎收到初始化请求后，给JSRunTime分配内存，应用程序使用的变量、对象和上下文（上下文）都保存在RunTime中。一个上下文是脚本的执行状态（JS引擎使用的）。每个同时存在的脚本或线程都必须有自己的上下文。单个的JSRunTime可以包含多个上下文、对象和变量。几乎所有的JS引擎调用都需要一个上下文变量，应用程序在创建RunTime后，首先应调用至少一次JS_NewContext来创建一个上下文。上下文的实际数量依赖于程序中同时使用的脚本数。程序中每个同时存在的脚本都需要一个上下文。另一方面，如果某个时刻只有一个脚本编译和运行，那么你只需一个上下文给每个脚本重复使用即可。
在创建上下文后，要调用JS_InitStandardClasses初始化引擎中的内置JS对象，包括Array、Boolean、Date、Math、Number和String。即使在创建对象时传递一个特定的上下文给JS引擎，这个对象在RunTime中也是独立于上下文。任意脚本能与任意上下文建立联系以便存取任意对象。脚本、上下文相互之间完全独立，即使它们存取同样的对象。在给定的RunTime中，应用程序能用未指定的上下文存取任意对象。你可以创建独立的RunTime，一个用于共享上下文和对象，其余的用于私有上下文和对象。但注意，某个时刻只有一个线程能存取特定的上下文。要让应用程序能识别JS，嵌入适当的引擎调用到你的程序中。大致有以下几个方面：
[*]程序中包含jsapi.h。[*]程序中提供结构和变量声明。例如，如果你计划传递一个脚本给JS引擎，提供一个脚本字符串变量。用jsapi.h中定义的JS数据类型来声明变量。[*]使用JavaScript的脚本应用对象。通常这些对象与C程序中的结构和方法相对应。[*]将JS引擎API函数调用和变量引用插入到程序中，包括初始化内置JS对象、创建并配置用户自定义对象。[*]大多数JS引擎调用返回一个值。如果该值是NULL，一般表示错误发生。如果非NULL，表示成功，返回值一般是指针，程序需要使用或留到将来使用。应用程序应检查JS引擎调用的返回值。要让应用程序能解释JavaScript，你必须遵循某些JSAPI嵌入习惯。下面的例子简要说明需要嵌入到你的应用程序中去的一些API调用函数。大部分情况下，这些函数的插入顺序是很重要的。例如，在调用其他JS API之前必须初始化JS RunTime，同样在终止程序之前必须释放JS RunTime。
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
/* 包含JS引擎的API头文件 */
#include "jsapi.h"
.
.
.
//主程序声明全局JS变量，包括RunTime、一个Context和一个全局对象，然后初始化JS RunTime、创建一个Context。
int main(int argc, char **argv)
{
int c, i;
/*声明全局JS变量，包括全局和自定义对象*/
JSVersion version;
JSRuntime *rt;
JSContext *cx;
JSObject *glob, *it;
JSBool builtins;
/* 初始化JS RunTime，返回结果给rt */
rt = JS_NewRuntime(8L * 1024L * 1024L);
/* 如果rt为空，程序终止 */
if (!rt)
return 1;
/* 创建一个Context，并将其与JS RunTime关联起来 */
cx = JS_NewContext(rt, 8192);
/* 如果cx为空，程序终止 */
if (cx == NULL)
return 1;
/* 创建全局对象 */
glob = JS_NewObject(cx, clasp, NULL, NULL);
/* 实例化内置对象和全局对象*/
builtins = JS_InitStandardClasses(cx, glob);
.
.
.
return 0;
}
如上面这个例子所示，调用JS引擎的应用程序必须首先创建JSRunTime，而且在终止程序之前要释放这个RunTime。在实例化RunTime后，即可创建自己的JS对象模型。对象模型决定了JS对象之间的关系，JS对象本质上是一种层次结构。缺省情况下，所有的JS对象都与全局对象相关联，它们都是全局对象的后代。当初始化标准的JS类时，你自动地得到一个全局对象：
builtins = JS_InitStandardClasses(cx, glob);
这个全局对象创建了一些基本的、被其它对象所继承的性质和方法。当你创建自定义对象时，它们自动使用全局对象所定义的性质和方法。你可以在自定义对象上重新定义这些性质和方法，从而重载这些缺省的性质和方法。当然，你也可以接受这些缺省的分配。你可以在内置JS对象或其它自定义对象的基础上创建自己的对象。无论哪种情况，你所创建的对象都继承了层次链中父对象、一直上溯到全局对象的全部性质和方法。 ECMAScript的世界，你认识几个？
CMAScript，这个从JavaScript和JScript演变而来的标准，现在已经进化为第三版，而这棵大树已经繁衍了好多枝叶了。看看这张由jQuery的创始人 John Resig建立的ECMAScript族谱，你会惊讶的发现原来好多都不知道啊，呵呵。
原文：http://ejohn.org/blog/the-world-of-ecmascript/
原文作者：John Resig
以下是对原文的翻译：
我做了一些搜索和挖掘工作，并把找到的资料联系起来，得出的结果很有趣，我把它叫做"ECMAScript的世界".
(授权方式：GPL v2 )
这是一个关于ECMAScript的世界地图，包括所有ECMAScript标准的实现及其衍生品，包括JavaScript、 ActionScript和JScript这些最著名的实现。这里我只展示了那些可以用于开发的东西（编程语言、引擎、浏览器和服务器等），不包括面向客户的Web应用程序，那个数量不是这个地图可以承担的，太多了。
这个图表从ActionScript、Tamarin、 ActionMonkey和SpiderMonkey的关系入手，从这些关系有扩展出很多额外的关系，这时候关系已经变得很复杂，有点超出我的控制范围了。我被ECMASCript这个生态系统给迷住了，数量和广度都超过了我开始的估计。（而且这还不是全部，我确定自己肯定遗漏了很多）
下面是上图对应的各种信息的链接
语言:
* JScript
* JScript.NET
* DMDScript
* QtScript
* InScript
* ExtendScript
* ActionScript
* JavaScript
引擎:
* Spidermonkey
* ActionMonkey
* Presto
* JScript
* .NET Framework
* DMD
* QSA
* iCab
* KJS
* JSCore
* Tamarin
* Narcissus
* Rhino
* ruby-spidermonkey
* python-spidermonkey
* JavaScript::Spidermonkey
应用:
* Camino
* Firefox
* Opera
* Internet Explorer
* iCab
* Konquerer
* Flash
* Photoshop
* AIR
* WebKit
* Safari
* Android
* HD DVD
* Apache
* Helma
* Phobos
* Tomcat
钩子/转换器:
* mod_js
* mod_jk
* mod_gcj
* mod_perl
* Ruby2JS
* RubyJS
* GWT
* Flash on C++
公司:
* Mozilla
* Opera
* Microsoft
* Adobe
* Apple
实现以上所有内容所使用的语言:
* JavaScript
* C/C++
* Java
* Ruby
* Python
* Perl
如果你发现我遗漏了什么一定要告诉我，我会酌情把他们加入到这个地图，为什么不是肯定加进去呢？主要是考虑把一些半成品拒之门外，再有就是这个需要手动添加，总要给我点时间吧。
11 月15日凌晨3点更新：去掉了WebKit（多余的），增加了Silverlight、IronPython和IronRuby，把PDF联系到SpiderMonkey上，修正了Konqueror的拼写错误。Presto不是Opera的JavaScript引擎，但我现在不确定它的 JavaScript引擎叫什么。去掉了PNGs，增加了一个SVG下载。
11月15日下午5点更新：把JavaScript放到表示语言的标识里，增加了ParenScript、YHC/JavaScript、Haxe 和Scheme2JS。增加了CouchDB。Silverlight现在链接到JScript后面。明确了Opera的两个JavaScript引擎（futhark和linear_b）。增加了Flex，修改QSA为QT Toolkit。 再看清楚一点 主流浏览器引擎简介
当前主流浏览器的引擎及浏览器：
Trident：IE4及以上、外核浏览器Maxthon、腾讯TT、世界之窗TheWorld
Presto：Opera7及以上
Gecko：Firefox2及以上、K-Meleon
KHTML：Safari、Konqueror
一、Trident
图形接口的排版引擎：Trident – Windows版的Internet Explorer
Trident （又称为MSHTML），是微软的窗口操作系统（Windows）搭载的网页浏览器—Internet Explorer的排版引擎的名称，它的第一个版本随着1997年10月Internet Explorer第四版释出，之后不断的加入新的技术并随着新版本的Internet Explorer释出。在最新的Internet Explorer第七版中，微软将对Trident排版引擎做了重大的变动，除了加入新的技术之外，并增加对网页标准的支持。尽管这些变动已经在相当大的程度上落后了其它的排版引擎，如Gecko、WebCore、KHTML及Presto。
Trident引擎被设计成一个软件组件（模块），使得其它软件开发人员很容易的将网页浏览的功能加到他们自行开发的应用程序里。微软提出了一个称为组件对象模型（COM）的软件接口架构。供其它支持的组件对象模型开发环境的应用程序（如：C++及.NET）存取及编辑网页。例如，由C++所撰写的程序可以加入浏览器控件里，并透过Trident引擎存取当前显示在浏览器上的网页内容及网页的各种元素的值，从浏览器控件触发的事件亦可被程序撷取并进行处理。Trident引擎所提供的所有函式库可以透过与 mshtml.dll这个档案的连结而达成撰写程序时所需要的功能。
除此之外，微软还有另一个网页浏览器排版引擎，称为Tasman，它是使用在「Internet Explorer for Mac」的排版引擎。相较于Trident，Tasman引擎对网页标准有较佳的支持。与普遍的看法相反的是，微软已经停止了Mac计算机版本的 Internet Explorer的开发，但Tasman的开发仍旧持续, 新版本的Tasman引擎仍被应用在一些微软产品上，如：麦金塔计算机版本的Microsoft Office。
二、Tasman
图形接口的排版引擎：Tasman – Macintosh版的Internet Explorer
Tasman，是微软的Internet Explorer for Mac浏览器所使用的排版引擎，也是为尝试支持W3C所制定的网页标准而设计的。在Tasman推出时，一度是最切合HTML及CSS等标准的排版引擎。现时微软方面也停止为Internet Explorer for Mac提供支持，但新版本的Tasman引擎仍被应用在一些微软产品上。
三、Presto
Presto是一个由Opera Software开发的浏览器排版引擎，供Opera 7.0及以上使用。
Presto取代了旧版Opera 4至6版本使用的Elektra排版引擎，包括加入动态功能，例如网页或其部分可随着DOM及Script语法的事件而重新排版。Presto在推出后不断有更新版本推出，使不少错误得以修正，以及阅读Javascript效能得以最佳化，并成为速度最快的引擎。
四、Gecko
于1997年，网景收购了DigitalStyle。当时，网景浏览器在各方面的表现已经比不上她的主要竞争对手Internet Explorer。这包括程式的执行速度、对W3C标准的支援度等等。网景开始研发下一代的排版引擎，并期望把新的排版引擎应用于下一版本的网景浏览器上。
1998年初，Mozilla计划开始执行。这个新的排版引擎名为Raptor，以开发源码的方式发放于互联网上。后来，因为商标问题，Raptor改外为NGLayout（即next generation layout之意）。而最后NGLayout就被网景重新命名为Gecko。但由于Gecko为网景的商标，所以有一段时期Mozilla组织（属于网景的非正式组织，亦为Mozilla基金会的前身）以NGLayout来称呼这个新的排版引擎，而在该时，Gecko这字亦指XPFE（cross- platform front-end），一个以XML为基础的使用者接口。不过，现时Gecko这字只用于排版引擎。
1998年10月，网景公布下一版的浏览器将会使用这个排版引擎，而该浏览器亦需要被大幅度重写。对于致力推动网上标准的人，这是一个令人振奋的消息。然而，对于网景开发者而言，这是一个长达六个月的大工程，而他们在网景5.0上（包括Mariner排版引擎）所花的心血亦被白白浪费。结果，网景6.0在 2000年11月才被正式发布。
随着Gecko的开发，越来越多应用程式开始利用她。AOL作为网景的母公司，终于在CompuServe 7.0和AOL for Mac OS X上使用Gecko。可惜，Windows版的AOL浏览器始终没有利用过Gecko。
2003年7月15日时代华纳解散了网景公司，大部分开发者被解雇。而Mozilla基金会亦在当天成立，继续推动着Gecko的发展。时至今天，Gecko仍继续由Mozilla的雇员和义工所维护和发展。
Gecko将会继续支持更多的网络标准，例如XForms和SVG。Mozilla基金会作为WHATWG的一份子，Gecko和其他排版引擎将会率先支援WHATWG所定下的规格，例如可供绘画的canvas。
Gecko的绘画元件在1.9版将会有重大的改变。她将会使用跨平台的Cairo元件来代替作业平台的绘画接口。这个改变将会令Gecko拥有更佳的绘图能力。而加上Glitz的话，更可利用3D硬件加速。而所有多媒体内容（如HTML/CSS、canvas、SVG等）将可使用同一管道作出渲染， SVG的特效亦可以应用于HTML上。因为使用Cairo的关系，图像亦可以被输出作PNG和PDF，“另存本页为PDF”等作业将变得有可能。
1.兼容的标准
Gecko引擎支持下列标准：
* HTML 4.01
* XML 1.0
* XHTML 1.1
* MathML
* CSS Level 1（支援部份CSS 2和3）
* DOM Level 1和2（支援部份DOM 3）
* RDF
* JavaScript 1.7
* E4X
* SVG（支援部份SVG 1.1）
2 .使用KHTML的产品
网页浏览器
* Mozilla Application Suite *
* Mozilla Firefox *
* AOL for Mac OS X
* Aphrodite *
* Beonex Communicator *
* Camino
* CompuServe 7.0
* DocZilla
* Epiphany
* Galeon
* IBM Web Browser
* K-Meleon
* Kazehakase
* ManyOne *
* Maxthon(本身并不支持,需要使用插件)
* Minimo
* Netscape 6.0和以上 *
* Salamander
* SeaMonkey *
* Skipstone
* Flock *
其他应用程式
* ActiveState Komodo *
* Liferea
* Mozilla ActiveX Control
* Mozilla Calendar *
* Mozilla Thunderbird *
* Nvu *
* GRE for Gecko-Sharp *
MediaCoder
* 使用Gecko来渲染基于XUL的用户界面。
五、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加入新功能及加快其排版速度。
1.兼容的标准
KHTML引擎支持下列标准：
* HTML 4.01
* CSS 1
* CSS 2.1 （paged media除外）
* CSS 3 选择符（selector）及部分其他功能
* PNG, MNG, JPEG, GIF 图形格式
* DOM 1, 2 及部分的 DOM 3
* ECMA-262/JavaScript 1.5
* 部分 SVG
2 .使用KHTML的产品
* KDE Konqueror - KDE的网页浏览器及档案管理员
* Safari - 苹果电脑的网页浏览器
* Embedded Konqueror - PDA上的网页浏览器
* SkyKruzer - SkyOS上的网页浏览器
* ABrowse - Syllable操作系统上的网页浏览器
* Nokia Series 60 移动电话的浏览器
六、WebCore
WebCore是苹果公司开发的排版引擎，它是在另外一个排版引擎“KHTML”的基础上而来的。苹果电脑于2002年采纳了KHTML，作为开发 Safari浏览器之用，并发布所修改的最新及过去版本源代码。后来发表了开放源代码的WebCore及WebKit引擎，它们均是KHTML的衍生产品。
使用WebCore的主要有Safari，此外还有OmniWeb、Shiira、Swift等。
七、WebKit
WebKit 是一个开源浏览器网页排版引擎，与之相应的引擎有Gecko（Mozilla，Firefox 等使用的排版引擎）和Trident（也称为MSHTML，IE 使用的排版引擎）。同时WebKit 也是苹果Mac OS X 系统引擎框架版本的名称，主要用于Safari，Dashboard，Mail 和其他一些Mac OS X 程序。WebKit 所包含的 WebCore 排版引擎和 JSCore 引擎来自于 KDE 的 KHTML 和 KJS，当年苹果比较了 Gecko 和 KHTML 后，仍然选择了后者，就因为它拥有清晰的源码结构、极快的渲染速度。
目前使用WebKit 引擎的浏览器主要有：Safari，Midori，Epiphany 等。 为什么 Mozilla 要固守 Gecko 内核而苹果抵制
随着 Google 推出 WebKit 内核的 Chrome 浏览器，一些技术狂热分子开始盘算 Mozilla 的 Gecko内核是否即将走到尽头。然而尽管 WebKit 日渐流行，那些熟悉 WebKit 与 Gecko 的差异，并对 Gecko大加赞赏的人还是认为，Mozilla 在未来版本的 Firefox 中使用 WebKit 内核的可能性尚无从谈起。
Webkit 的优势
Webkit 是一个开源的HTML 渲染引擎，由苹果公司基于 KDE 的 KHTML 项目开发而成。我们从 Chrome的评测中已经看Webkit 是一个非常轻量的渲染引擎，因其紧凑干净的代码基础，出色的标准支持，以及很小的内存占用而备受赞誉。这些品质使得Webkit 成为众多浏览器的热选内核。
Webkit 主要用于苹果的 Safari 浏览器与 iPhone，但一些重要的厂商如 Adobe，Nokia, Trolltech也使用这个核心。Webkit 的用户中还包括一些不太知名的浏览器，包括 iCab, Omniweb, Shiira, 以及Epiphany。在一些二线操作系统，如 Haiku, Syllable, 甚至 Amiga，Webkit 也大行其道。越来越多的开发者，使用Webkit 开发富 Internte 应用（rich Internet applications）。Google在对众多内核进行评估之后，为 Android 移动浏览器，以及 Chrome 桌面浏览器选择了 WebKit。
开发者对 Webkit 公认的评价是：这是一个非常出色的渲染引擎，可以用于众多场合，它的吸引力让很多开发者开始怀疑 Mozilla 的 Gecko 内核是否还有市场。
苹果为什么抵制 Gecko
Gecko 源自 Netscape，并早于 KHTML，Gecko 因庞大与复杂的代码基础而频遭诟病。Gecko 非常强大，但代价高昂，复杂，高内存占用。因此，在很多场合 Gecko 的众多功能反而成了负担。
Gecko 内核过于复杂的原因是 Gecko 意图提供除了 HTML 渲染之外的更多功能。Mozilla早期的野心很大，Mozilla 最早的应用套件包括浏览器，邮件和新闻组程序，Web 设计工具，IRC 聊天工具。除了渲染 HTML，Gecko还要提供一种应用广泛的，基于 XML 的用户界面生成引擎，XUL。XUL 被用在所有这些程序中。XUL 现在仍用在 Firefox中，用来生成用户界面，因此造就了 Firefox 最有价值的重多扩展应用。
Gecko 过于复杂的另外一个原因是 XPCOM，一个强大的组件系统。虽然 XPCOM 为 Gecko带来很多激动人心的功能，让这个渲染引擎实现组件化，然而，这个功能被一些开发者滥用，当 Ars Technica 2004年采访 Mozilla开发者 Scott Collins 的时候，Scott Collins 说，对 XPCOM 的滥用是 Mozilla 犯的几个主要错误之一。
鉴于 XUL 和 XPCOM 所带来的复杂性，苹果自然要考虑为 Safari 选择一种更轻量的内核。苹果要设计一款可以和 Mac 操作系统紧密结合的浏览器，他们还预见到，这个引擎应该支持移动设备，他们因此认识到 KHTML 比 Gecko 更合适。
2003年，当苹果决定在 Safari 中使用 KHTML 的时候，Mozilla 的 Mike Shaver 曾在博客中承认 Gecko 的缺点。他同时预言，苹果会成为他们推广 Web 标准的联盟。他写道，
“小而精练曾是我们的苦苦追寻的目标，Gecko 的庞大与臃肿在各种评测中拉了我们的分数，如果我不得不写一个新浏览器，我会考虑Mozilla 之外的选择。我希望 Mozilla 向 Safari/KHTML 学习，因为它们用 1/10 的代码实现了非常棒的功能。”
Gecko 洗心革面带来 Firefox 3 的火爆
2003年以来，发生了很多变化。Gecko 代码基础已经发展了很久，Gecko 依然复杂，然而它的很多历史遗留的缺陷正被一一攻破，Gecko 为 Firefox 3 带来众多革新，为整个 Web 浏览体验带来非常显著的改善。
Gecko 1.9 使用跨平台的 Cairo 渲染框架，对 SVG 的巨大改进简化了代码并引入一些非常 Cool的功能，如全页缩放，同时，重构的 reflow 算法，让 Gecko 通过 Acid 2 测试成为可能。Mozilla还非常显著地降低了对内存的占用，甚至超越了 Safari 和 Opera。
对 XPCOM 的使用被大大减少，XPCOM 对资源的占用通过一个新的循环回收器得到减低。这个工作仍在继续，Mozilla 将在Firefox 4 中进一步减低 XPCOM 的负担。Gecko 的其它缺陷也在新的开发中被一一正视，比如，Firefox 3.1 的Alpha 版中就已经加入对 CSS 3 的支持，另外一些性能的改进会让 Gecko 更具竞争性。Mozilla 的 TraceMonkey引擎将可能包含在 Firefox 3.1 中，这将显著地提高 JavaScript 性能。
从技术的角度，Gecko 现在非常稳固，丝毫不比 Webkit 差。一些证据显示，Gecko 正在进军移动领域，这在不久前还是不可能的事。Mozilla 拥有资源，开发经验以及社区支持，这将引导 Gecko 进入任何 Webkit 所能进入的地盘。
页:
[1]
2