八大Webkit内核浏览器

列举出时下最流行的Webkit内核浏览器，所以我们并不会做出评测和对比。
PS：本文列举的浏览器有一部分为IE+Webkit双核浏览器，如果您对其他IE内核浏览器很感兴趣《抛弃数据！用体验和感觉告诉你什么才是最好用的浏览器！》一文可能会对你有所帮助。
尖端技术的Webkit内核
WebKit 是一个开源的浏览器引擎，与之相对应的引擎有Gecko（Mozilla Firefox 等使用）和Trident（也称MSHTML，IE 使用）。
同时WebKit 也是苹果Mac OS X 系统引擎框架版本的名称，主要用于Safari，Dashboard，Mail 和其他一些Mac OS X 程序。
WebKit 前身是 KDE 小组的 KHTML，WebKit 所包含的 WebCore 排版引擎和 JSCore 引擎来自于 KDE 的 KHTML 和 KJS，当年苹果比较了 Gecko 和 KHTML 后，仍然选择了后者，就因为它拥有清晰的源码结构、极快的渲染速度。Apple将 KHTML 发扬光大，推出了装备 KHTML 改进型 WebKit 引擎的浏览器 Safari。

1.Google Chrome 谷歌浏览器
2 亿活跃用户，全球成长最快，来自 Google 的新型浏览器。
Chrome谷歌浏览器下载：http://www.jisuxz.com/down/533.html
官方网站：http://www.google.cn/chrome

2.Safari浏览器
它的创新功能将改进你浏览网页的方式。功能强大的新工具能够帮助开发人员提升用户的浏览体验，令其更具个性化。
Safari浏览器下载：http://www.jisuxz.com/down/598.html
官方网站：http://www.apple.com.cn/safari/

3.搜狗高速浏览器
以快速作为主打的国产双核浏览器，搜狗浏览器做的很不错，3.1版本也升级了Webkit内核。
搜狗高速浏览器下载：http://www.jisuxz.com/down/598.html
官方网站：http://ie.sogou.com/

4.傲游浏览器3
搭载独立浏览核心，上网速度全面提升。专为国人习惯优化，更高效，更安全，更私密！
傲游浏览器3下载：http://www.jisuxz.com/down/2077.html
官方网站：http://www.maxthon.cn/mx3/

5.QQ浏览器
QQ系列的新一代双核浏览器产品，更多对QQ产品的支持。
QQ浏览器下载：http://www.jisuxz.com/down/210.html
官方网站：http://browser.qq.com/

6.360极速浏览器

360极速浏览器采用了最新的Webkit内核技术，速度更上一层楼。
360极速浏览器下载：http://www.jisuxz.com/down/2094.html
官方网站：http://chrome.360.cn/

7.世界之窗浏览器(极速版)
世界之窗浏览器极速版基于 Chromium 浏览器开源项目开发，是此开源项目的一个并行分支。凤凰工作室将逐渐参与到 Chromium 开源项目中，这样既可以打造更适合国内用户使用习惯的优秀浏览器，也为互联网发展做出自己的贡献。
世界之窗浏览器(极速版)下载：http://www.jisuxz.com/down/7382.html
官方网站：http://chrome.theworld.cn/

8.阿里云浏览器
阿里巴巴自主开发的阿里云浏览器浮出水面。产品包括PC端和手机端浏览器。近来，各大互联网巨头都开始研发自有浏览器，阿里巴巴在浏览器的布局，有利于巩固阿里巴巴的用户入口，在整个“大阿里”的内循环中起到数据保护的作用。
阿里云浏览器下载：http://www.jisuxz.com/down/6930.html
官方网站：http://browser.aliyun.com/index.html

尽管Webkit内核是个非常好的网页解析机制，但是由于以往微软把IE捆绑在Windows里(同样的Webkit内核的Safari捆绑在Apple产品里，Chrome[1] 捆绑在Google产品里)，导致许多网站都是按照IE来架设的，很多网站不兼容Webkit内核，比如登录界面、网银等网页均不可使用Webkit内核的浏览器。

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

WebKit 是一个开源项目，其起源可追溯到 K Desktop Environment (KDE)。WebKit 项目催生了面向移动设备的现代 Web 应用程序。虽然设备本身的能力和形态因素都相当重要，但移动用户最热衷的仍然是内容。如果移动用户可用的内容只是 Internet 用户可用内容的一个很小的子集，那么用户体验充其量也只能划分为二等。

WebKit 还应用在了桌面的 Safari 浏览器内，该浏览器是 Mac OS X 平台默认的浏览器。不管我们讨论的是桌面版本还是 iPhone 或 Android 上的浏览器引擎，WebKit 均优先支持 HTML 和 CSS 特性。实际上，WebKit 还支持尚未被其他浏览器采纳的一些 CSS 样式 — 这些特性正在得到 HTML5 规范的考虑。

HTML5 规范是一个技术草案集，涵盖了各种基于浏览器的技术，它包括客户端 SQL 存储、转变、转型、转换等。HTML5 的出现已经有些时间了，虽然尚未完成，但一旦其特性集因主要浏览器平台支持的加入而逐渐稳定后，Web 应用程序的简陋开端也将成为永久的记忆。Web 应用程序开发将成为主导 — 并且不只是在传统的桌面浏览器空间，还将在移动领域。移动将一跃成为首要考虑，而不再是后备之选。

iOS：

2007年6月29日，iPhone上市，WebKit进入iPhone OS平台，而且立即成为iPhone OS平*一无二的排版引擎。

Android：

Google 开发的手机操作系统Android中内置的浏览器也是采用的WebKit引擎。

Nokia S60：

诺基亚公司将WebKit移植到Symbian S60操作系统中，并开发了基于Webkit的手机浏览器“Web browser for S60”，广泛用于诺基亚、三星、LG等基于Symbian S60操作系统的手机中。

Web OS:

Palm 推出第一款基于WebKit的操作系统，Palm Pre是第一款基于该系统的手机产品。

Linux：

尽管WebKit的原型K内核是由Qt写成，但Linux下目前最受瞩目的WebKit项目却是Gnome领导的WebKit/Gtk+。随着奇趣科技于2008年6月被Nokia收购，Qt方面也加快了WebKit的“回归”进程。

Midori，Google Chrome，GNOME的Epiphany、KDE的Konqueror，浏览器。

Windows：

Webkit内核在Windows上发展最晚，Safari(for Windows)，Midori，Google chrome，具有双核模式的傲游3和傲游云浏览器是最为常见的Webkit浏览器。2009年推出的safari和Chrome以及2010年推出的搜狗浏览器V2.0Beta和傲游3.0beta都使用的webkit引擎完全通过了acid3测试满分！

浏览器的内核引擎，基本上是四分天下：

Trident: IE 以Trident 作为内核引擎;

Gecko: Firefox 是基于 Gecko 开发;

WebKit: Safari, Google Chrome,傲游3,猎豹浏览器,百度浏览器 opera浏览器 基于 Webkit 开发。

Presto: Opera的内核，但由于市场选择问题，主要应用在手机平台--Opera mini

注：2013年2月Opera宣布转向WebKit引擎

注：2013年4月Opera宣布放弃WEBKIT，跟随GOOGLE的新开发的blink引擎

为什么搞WebKit
现在研究WebKit的人越来越多，俺不能免俗，也加入其中。WebKit的火爆也是得益于浏览器和WebOS的混战，随着Palm WebOS, Chrome OS, Firefox OS和Ubuntu Mobile相继发布，WebOS逐渐成为Android和IOS之外的第三世界，而WebKit也随之从浏览器内核晋升为Mobile OS的内核，除了IE和Firefox之外，市面上叫得上名字的都是基于WebKit发展起来，Chrome, Safari, Opera, 360......。因此，无论你是从事浏览器还是Mobile的开发，WebKit都是不二的选择。而我目前是因为需要在WebOS上提供一个类似与Chrome for android那样可以远程debug的功能，而接触到WebKit，随着不断深入，也逐渐步入WebKit的开发正轨，也是想把最近的学习历程记录下来，也是帮助其他朋友进这个大门，WebKit的资料实在不多。

如何起步
我就假定你和我一样，从没接触过WebKit，没写过c/c++，被Java/PHP等傻瓜式语言惯坏了，对设备底层技术不甚了解，在这种情况下（不可能比这个更糟了），也是可以在一周左右入这个门槛的。正式开工之前先准备以下几步：
学习文章：http://paulirish.com/2013/webkit-for-developers/，当然也有中文版本：http://www.infoq.com/cn/articles/webkit-for-developers，弄清楚WebKit的几个概念
准备一台CPU和硬盘较好的电脑，CPU是为了应付编译，硬盘是为了应付大规模代码的访问（去年7月份买的mac已不够用，特地为此换了SSD）
开发平台最好是Xcode，Visual Studio也行，不过可能会遇到很多坎、
准备一本C++ Primmer Plus放在手边，研究WebKit同时顺便把C++也给攻克了
给予足够的耐心，应付漫长的源码下载和编译
好了，就这么多，可以开工了。关于如何编译和调试等问题，我会在后续文章中详细介绍。
开工之前的扫盲
WebKit port
WebKit已发展为类似与Linux这样平台性的框架，已不是单一产品类型的开源项目。它是一个标准和变异的结合体。下面这张图能很好说明这点：

WebKit提供了像这张图这样的标准架构和WebCore这样的核心库，但灰色的其他部分都是要根据各自平台的不同而进行替换和移植，也就是谈及很多的port，这里谈的平台就是各自设备的运行环境，比如mac os x，Android和IOS，因此虽然咱是用WebKit，但可以做的事情还有很多，WebKit只是提供了流程和框架，里面有很多洞需要咱自己去填补的。比如，我现在做的远程调试功能，在WebKit里面已在流程上支持，但具体实现上是需要port的，也就导致了只有chrome for android和safari for IOS支持远程调试。开头介绍的文章中已罗列出哪些点是标准已实现的，哪些点是差异化的，从这里面大概就能预计到需要做哪些东西。
学习平台的选择
官方的WebKit是以Safari for Mac OSX为基础的，Chromium虽然也是基于WebKit，但基本上已是另外一套，还有QT和GTK平台，有很多浏览器，比如Opera和360都选择了基于Chromium，那对于我们这些初学者来说该如何选择学习的起点呢？我的感觉是，标准的WebKit门槛低一点，文档要丰富一些，但作为将来工程的方向，Chromium更受欢迎一些，所以，我推荐以官方的WebKit为起点，然后再延伸到Chromium。后面我会谈开发环境的搭建，基于官方的WebKit，再加上XCode，会感觉手上很顺滑，不至于像大多数大型开源项目那样在最开始就把你拒之门外。
开始动手
下面我介绍动手的几个步骤，可以在你无需了解细节的情况下，把环境搭起来，大多数包括我自己，都还是习惯于代码和环境搭建好情况下，比较有心情和底气去往下深入，所以耐心地完成下面几步，你就可以在开发环境中启动WebKit，这里我介绍的是Mac下的情况，但在windows和linux会困难一些，起码我是受阻后就放弃了：
升级Mac OSX和Xcode至最新版本，我的是Mountain Lion 10.8.3和Xcode 4.6。做这个是因为我的一个哥们用的是lion，用的一样的步骤，但启动后一直报内存访问错误，升级系统至最新后就解决了。当然，别忘记了xcode command line
取得最新代码：svn checkout https://svn.webkit.org/repository/webkit/trunk 当然，这个过程是需要耐心的，特别是下载layout test时，为了将来的一马平川，忍忍吧
Xcode的菜单File->Workspace Settings->Build->Derived Data Location一栏选择Workspace-relative，并输入WebKitBuild->Done
Xcode的菜单Product->Scheme->Edit Scheme->选择scheme: All Source(target WebProcess), Exceutable选择WebProcess.app
如果你是下载的是最新代码，环境搭建仅仅只需要以上几步，当你点击Run后，就可以开始顺利编译，最后会弹出Safari，实际上它的run的是webkit内核，需要一个Safari来作UI层。WebKit也提供了一个MiniBrowser，这就和Safari没关系了，启动方法就是在第四步上的Exceutable选择MiniBrowser.app即可。我当初基于的代码会有些其他的问题，这里就不干扰大家了，如果有遇雷的请把错误贴出来，我看看遇到过没。

OK，了解基本概念，搭建好了开发和调试环境，我敢相信任何级别菜鸟，都会有信心往下继续深究了。我的理念就是这样，不管后面有多难，千万不要把开头搞得太复杂，这样会拒很多人之门外，这也是我为什么推荐最开始用xcode的原因，WebKit官方已把编译中所有细节都隐藏在xcode的项目设置和脚本中了。后面，我会基于源码，逐步深入，和大家一起探究WebKit内核的神奇和伟大。

　　

WebKit最神奇的一点是JS能调到内核部分（c/c++），这是WebOS向外提供扩展能力的关键（实现或扩展W3C API）。要搞清楚一个JS的方法是如何调到后面c/c++的实现颇费周折，其实就是要把IDL和Bindings弄懂，先解释一下这两个名词：

• IDL：接口定义语言，详细解释可见http://trac.webkit.org/wiki/WebKitIDL
• Bindings：WebKit动态生成与其他框架（如JavascriptCore, V8）整合的代码

我这么解释估计还是一头雾水，那就看看WebKit为啥需要这两个概念。首先我们得明白WebKit的世界里只有DOM和DOM相关的行为，它不认识Script，例如：

document.getElementById('domId')

WebKit知道document，也知道getElementById该做什么事儿，但它不认识getElementById这个函数，不具备script解析和执行的能力，因此它需要第三方的解析器来帮助，这也就是JavascriptCore（JSCore）或V8需要干的事儿。但JavascriptCore或V8很薄，能解析和执行javascript语言本身，不知道getElementById的具体实现，所以需要WebKit把具体实现注入进来，好了，说到这里大家就大概明白为啥需要IDL和Bindings了，其实就是为了提供一个标准的方式（IDL），让WebKit把JS API背后的实现注入给javascript解析器，另外，各个解析器的具体注册和执行机制是不同的，所以需要有Bindings来动态生成与各个解析器结合的部分，这样同一套标准的WebKit就能与各种解析器整合了。说了半天，看个图就清楚了：

其中，V8/JSCore Bindings中包含的是基于IDL规范为各个JS实现动态生成的产物，这些产物是会注册到各个DOM上，并能被V8/JSCore识别，所以以v8上的document.getElementById为例，调用流程如下：

1. 编译的时候，基于Document.idl为Document.cpp和Document.h动态生成V8Document.cpp和V8Document.h(后面会讲到动态生成这部分逻辑)
2. V8Document.cpp和V8Document.h其实就是包含两样东西，一是对Document.cpp和Document.h各个方法的代理，二是js API和各个实现方法的对照表
3. WebKit把V8Document中对照表注册到document这个dom中
4. WebKit中执行脚本document.getElementById
5. WebKit按照最新的document的dom结构初始化V8的context
6. V8解析和执行document.getElementById
7. V8根据对照表执行getElementById方法对应的V8Document.cpp中的实现
8. V8Document.cpp代理Document.cpp相应的实现

对于JSCore，流程和原理相同，只是具体的实现细节不同，而这个不同就是在bindings和JSCore中来体现，对于WebKit本身是完全相同的，同样的Document.cpp和Document.h标准实现能适配到不同的解析器上去解析和执行，这就是IDL和Bindings的精妙之处，让WebKit既能单一又能海纳百川。

以上流程中的关键有两点，一是动态生成bindings这块，另外是如何注册和执行bindings，后面这一点由于c/c++功力有限，没完全看懂，留到后面再仔细琢磨，前面这一点是WebKit强大的编译体系中的一部分，下面详细解释一下。

先抽出各个不同编译平台的差异点，WebKit就是通过WebCore/bindings/scripts/中的generate-bindings.pl perl脚本生成bindings中的代码，它在Android平台上会被Android.derived.v8bindings.mk调用到，在mac上被DerivedSources.make调用到，其大体流程是非常清晰的：

1. 解析IDL
2. 调用各个平台相应的CodeGenerate脚本
3. 生成最终bindings代码

见下图所示：

具体的实现逻辑就看看各个脚本源码，这里就不多说了。另外，对于脚本的注册和执行那块可以看看bindings下的ScriptController.cpp，当然，如何想看V8/JSCore中是如何调用对照表中的代码，就需要再看看V8/JSCore本身的源码，V8就看execution.cc，JSCore就看JITCode.h。

综上所述，WebKit利用IDL和Bindings把自己从JS语言本身中脱离，让自己既可以不需了解JS语言，又能实现JS API背后的逻辑，妙哉！