八大Webkit内核浏览器
为什么搞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为例，调用流程如下：
编译的时候，基于Document.idl为Document.cpp和Document.h动态生成V8Document.cpp和V8Document.h(后面会讲到动态生成这部分逻辑)
V8Document.cpp和V8Document.h其实就是包含两样东西，一是对Document.cpp和Document.h各个方法的代理，二是js API和各个实现方法的对照表
WebKit把V8Document中对照表注册到document这个dom中
WebKit中执行脚本document.getElementById
WebKit按照最新的document的dom结构初始化V8的context
V8解析和执行document.getElementById
V8根据对照表执行getElementById方法对应的V8Document.cpp中的实现
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调用到，其大体流程是非常清晰的：
解析IDL
调用各个平台相应的CodeGenerate脚本
生成最终bindings代码
见下图所示：
具体的实现逻辑就看看各个脚本源码，这里就不多说了。另外，对于脚本的注册和执行那块可以看看bindings下的ScriptController.cpp，当然，如何想看V8/JSCore中是如何调用对照表中的代码，就需要再看看V8/JSCore本身的源码，V8就看execution.cc，JSCore就看JITCode.h。
综上所述，WebKit利用IDL和Bindings把自己从JS语言本身中脱离，让自己既可以不需了解JS语言，又能实现JS API背后的逻辑，妙哉！