八个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，首先要解释这两个术语:

我想我仍然不知该如何解释，所以让我们看看为什么WebKit需要这两个概念. 首先，我们必须了解，WebKit世界中只有DOM和与DOM相关的行为. 它无法识别脚本，例如:

document.getElementById（'domId'）

WebKit知道文档，也知道getElementById应该做什么，但是它不识别getElementById函数，并且不具有解析和执行脚本的能力. 因此，它需要第三方解析器JavascriptCore（JSCore）的帮助. ）或V8需要做什么. 但是JavascriptCore或V8非常薄，可以解析和执行javascript语言本身. 我不知道getElementById的具体实现，因此我需要将具体实现注入WebKit. 好的. 在这一点上，每个人都可能理解为什么需要IDL和绑定. 实际上，这是为WebKit提供一种将JS API背后的实现注入到JavaScript解析器中的标准方式（IDL）. 另外，每个解析器的特定注册和执行机制是不同的，因此需要绑定来动态生成和分析每个解析器. 这样，同一标准WebKit可以与各种解析器集成在一起. 经过长时间的交谈，通过查看图片可以清楚地看到:

其中，V8 / JSCore绑定包含根据IDL规范为每个JS动态生成的产品. 这些产品将在每个DOM上注册，并且可以被V8 / JSCore识别，因此请使用v8上的文档. 以getElementById为例，调用过程如下:

编译时，将基于Document.idl为Document.cpp和Document.h动态生成V8Document.cpp和V8Document.h（动态生成的逻辑将在后面讨论）V8Document.cpp和V8Document.h实际上包含两个事物，一个是Document.cpp和Document.h的各种方法的代理，另一个是js API的比较表和每种实现方法. WebKit在V8Document中将比较表注册到文档dom. WebKit根据最新版本执行脚本document.getElementByIdWebKit. 初始化文档的dom结构，并分析和执行V8的contextV8. document.getElementByIdV8根据比较表在V8Document.cpp中执行与getElementById方法相对应的实现. V8Document.cpp代理Document.cpp对应的实现

对于JSCore，其过程和原理相同，但是具体的实现细节不同. 这种差异体现在绑定和JSCore中. 对于WebKit本身，它是完全相同的. 可以实现相同的Document.cpp和Document.h标准. 适应不同的解析器进行解析和执行，这是IDL和绑定的精妙之处，它使WebKit成为单一且可容忍的.

以上过程有两个关键点. 一种是动态生成绑定，另一种是如何注册和执行绑定. 由于c / c ++的能力有限，因此后一点是有限的，因此我无法完全理解它，因此我将在以后进行讨论. 上一点是WebKit强大的编译系统的一部分，下面将对其进行详细说明.

首先提取不同编译平台之间的差异. WebKit使用WebCore / bindings / scripts /中的generate-bindings.pl perl脚本来生成绑定中的代码. 这将是Android平台上的Android.derived.v8bindings. 由mk调用，在Mac上由DerivedSources.make调用，一般过程非常清楚:

分析IDL并调用每个平台的相应CodeGenerate脚本以生成最终绑定代码

请参见下图:

请查看每个脚本的源代码以了解具体的实现逻辑，因此在此不再赘述. 另外，对于脚本的注册和执行，您可以在绑定下查看ScriptController.cpp. 当然，如果要查看在V8 / JSCore中如何在比较表中调用代码，则需要查看V8 / JSCore本身的源代码. 查看V8，然后查看JSCore的JITCode.h.

总而言之，WebKit使用IDL和Bindings将自身与JS语言本身分开，因此您可以在不了解JS语言的情况下实现JS API的逻辑.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shumachanpin/article-292324-1.html