webkit小结

《webkit小结》由会员分享，可在线阅读，更多相关《webkit小结（8页珍藏版）》请在金锄头文库上搜索。

1、Webkit1.1.简介简介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 后，仍然选择了后者，就因为它拥 有清晰的源码结构、极快的渲染速

2、度。内核引擎WebKit 的前身是 KDE 小组的 KHTML。Apple 将 KHTML 发扬光大，推出了装备 KHTML 改进型的 WebKit 引擎的浏览器 Safari，获得了非常好的反响。 WebKit 引擎比 Gecko 引擎更受程序员欢迎的原因，除了其引擎的高效稳定，兼容性好外，其源码结构清晰，易于维护，是一个重要的原因。而 Gecko 的可维护性就差多了。 现在浏览器的内核引擎，基本上是三分天下： Trident: IE 以 Trident 作为内核引擎; Gecko: Firefox 是基于 Gecko 开发; WebKit: Safari, Google Chrome,搜狗

3、浏览器 基于 Webkit 开发。 WebKit 内核在手机上的应用十分广泛，例如 Google 的手机 Gphone、 Apple 的 iPhone, Nokias Series 60 browser 等所使用的 Browser 内核引擎，都是基于 WebKit。应用平台在应用于 Mac Os 上的 Safari 之后，Webkit 很快被广泛地移植到其他系统平台： iPhone OS： 2007 年 6 月 29 日，iPhone 上市，WebKit 进入 iPhone OS 平台，而且立即成为 iPhone OS 平台独一无二的排版引擎。 Nokia S60 平台： 诺基亚公司将 Web

4、Kit 移植到 Symbian S60 操作系统中，并开发了基于 Webkit 的手机浏览器“Web brower 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 的“回

5、归”进程。 Midori，Google Chrome，GNOME 的 Epiphany、KDE 的 Konqueror，Arora 是现在 Linux 系统下主要的 Webkit 内核浏览器。 Windows： Webkit 内核在 Windows 上发展最晚，Safari(for Windows)，Midori，Google chrome，具有双核模式的傲游 3 和搜狗浏览器 2（极速模式下使用 Webkit 核心）是最为常见的 Webkit 浏览器。2009 年推出的 safari 和 Chrome 以及 2010 年推出的搜狗浏览器 V2.0Beta 和傲游 3.0beta 都使用的 w

6、ebkit 引擎完全通过了 acid3 测试满分！ 浏览器： 2008 年 9 月 2 日，谷歌公司发布的第一个版本 Google Chrome（中文名为谷歌浏览器）就采用了 Webkit 引擎。 2009 年，广受关注的 Google 手机的自带的浏览器也是 Webkit 内核，加载网页速度比IE 手机浏览器快了近一倍。 2010 年 1 月 24 日，搜狗公司发布搜狗浏览器 V2.0Beta，采用 Webkit 引擎，并支持与IE 引擎互相切换。 2010 年 1 月 24 日，傲游 3.0beta 发布。 2.2.总体结构总体结构毛主席教导我们， “我们的方针是路线决定一切，人多，枪多，

7、代替不了正确的路线。 路线正确就有一切，路线不正确有了也可以丢掉。路线是个纲，纲举目张” 。对于软件工程， 主席的教导依然具有指导意义。不妨把主席的教导改动一下， “软件工程的方针是结构决定 一切，代码多，功能多，代替不了正确的结构。结构正确了，不断改进以后就有一切，结 构不正确，有了也可以丢掉。结构是个纲，纲举目张” 。现代软件工程的语汇里，结构多半 特指 object-oriented 的结构。Webkit 源代码十分严格地遵循 object-oriented 的原则来组织， 这样做的好处不仅仅有利于后续开发和维护，而且也便于研读源代码。 Webkit 源代码由三大 packages 组成

8、，1. WebCore，2. WebKit，3. JavaScript。当输入 一个 HTML 文件，WebCore 的职责是解析每个 HTML Tag，以及它们之间的从属关系，生 成一棵树状的数据结构（DOM Tree） ，然后结合 HTML 文件中指定的 CSS 定义，确定 DOM Tree 中每个节点的在整个页面中的位置，以及颜色字体等等。布局与渲染效果的确 定，以属性和属性值的形式，存放在另一棵树状数据结构中，这另一棵树称之为 Rendering Tree。通常情况下，Rendering Tree 的结构与 DOM Tree 大致相同，基本上 DOM Tree 里面 每一个节点，在 R

9、endering Tree 里都有对应的节点。 这里有两个疑问，1. 为什么既有 DOM Tree，又有 Rendering Tree，两者合一不是更 省内存吗？2. Rendering Tree 为什么要与 DOM Tree 保持一致？不一样又如何？这两个问题， 我们稍后讨论。 Rendering Tree 只是确定了该如何渲染 HTML 页面，有点像司令部里的参谋们制订作 战计划。但是具体的渲染，包括画点画线字体等等，在不同的 OS，甚至不同的硬件环境下， 实现的方式各不相同，这就像真正冲锋陷阵，还得靠前线将士。Webkit 源代码中的 WebKit package，里面包含的程序，就是这

10、些前线将士。WebKit package 中有 win/, mac/, gtk/, qt/, wx/ 等等 subpackages，就是针对各个不同 OSes，以及各种不同的跨平台的图形库， 所采取的因地制宜的渲染手段。与各个不同的 OSes 相关的，不仅仅是渲染，还有鼠标移 动和键盘点击等等用户触发的 UI 事件的捕捉。所有这些与具体 Oses 相关的程序，通通被 放置在 WebKit package 中。Webkit 源代码中第三个主要部分，是 JavaScript engine。JavaScript engine 用来解析 JavaScript 代码，并执行。这个系列里不展开介绍 Jav

11、aScript engine。 2. DOM Tree 与 Rendering Tree 是否必须一致？ “ 天下文章一大抄” ，这话说来难听，但是却是实情。很少有文章从头到尾，字字原 创，而绝大多数都是在消化整理前人和他人的知识基础上，添加自己的一点点发挥和创造 而成。人类的文明进步，就是这样一点一滴，逐渐积累起来的。既然文章离不开引经据典， 旁征博引，阅读文章的时候，也就免不了需要查阅相关文献。 在 Web 出现以前，查阅文献是一件费时费力的事情。1989 年 3 月，在欧洲原子能研 究组织（CERN）工作的 Tim Berners-Lee，提议在 TCP/IP 协议基础之上，建立一个相互

12、链 接的信息系统。这个建议很快发展成为万维网（World Wide Web，简称 Web） ，极大地方 便了文献的查阅。Web 的核心，是 hyperlink。在撰写网页时，可以对于某些词句，设置隐 含的 hyperlinks。当读者点击这些词句时，计算机就会根据词句背后隐含的 hyperlink，自 动打开另一个网页。请注意“隐含的”这个词，这意味着文章的显示（Presentation） ，与文 章的内容（Content）并不完全一致。 Tim Berners-Lee 考虑到这一问题，于是建议给每个 Web 网页制订一个规范，这个规 范就是“超文本标识语言” ，简称 HTML。最初的 HTM

13、L 制订了 22 个标识，标注两方面 的功能，1. 内容，包括引用，2. 显示格式。在同一份 HTML 文件，把内容和格式混杂在 一起，这是一个设计错误。20 年过去了，现在的 HTML 文件，基本上是以内容为主，格 式被分离出去，由 CSS 定义。除此之外，还增加了与读者互动的动作，这些互动动作，通 常由 JavaScript 定义。 为什么分离比合并好？同一份内容，针对不同的读者，可以通过不同的 CSS，改变显 示的方式，举几个例子。针对新人类，可以用卡通图标替代某些特定文字。针对老派读者 可以换用大号字体，从上往下，从右往左排版。对于正在开车的听众，可以用朗诵替代文 字显示。 内容与格式

14、分离，并不等同于 DOM Tree 与 Rendering Tree 并存。假如内容由 HTML 承载，格式由 CSS 定义，我们可以只用一棵树，不仅存放内容，也存放格式属性。DOM Tree 与 Rendering Tree 分离，好处在于同一棵 DOM Tree，可以对应多棵 Rendering Trees， 也就是同一个内容，可以由多种不同的方式来布局和渲染。在当今的浏览器里，一棵 DOM Tree 对应多棵 Rendering Trees 的情况不常见，因为同一个页面，通常只有一种风格 的布局和渲染。但是在电子游戏中，同一个场景会有多个不同视角，譬如枪战游戏中，有 枪手本人视角，有旁观

15、者视角，还有俯瞰视角等等。换句话说，Webkit 不仅满足了当今浏 览器的普通需要，而且提供了一些尚没有被广泛利用的潜在的功能。把 DOM Tree 与 Rendering Tree 分离的做法，虽然浪费了一些内存空间，但是着眼于未来，Webkit 这样的 结构设计，为未来的发展埋下了伏笔。 目前而言，Rendering Tree 的结构基本上与 DOM Tree 的保持一致，DOM Tree 里每一 个节点，在 Rendering Tree 都有对应节点，父子节点之间的继承关系也保持一致。但是 Webkit 的代码，给 Rendering Tree 结构的异化，也埋下了伏笔。Renderin

16、g Tree 的结构，不 一定与 DOM Tree 保持一致。举个例子，或许未来的网页可以提供个性化的编辑方式。当 读者第一次打开某个页面的时候，看到的是标准的页面，也就是 Rendering Tree 与 DOM Tree 保持一致的页面。读者可以摘录网页中某些段落，删除不感兴趣的段落，改变着色， 改变字体，甚至重新布局。以后再次造访这个页面时，这位读者就可以看到个性化的页面， 而所谓个性化的实现方式，其实就是构筑另一棵 Rendering Tree。假如他想恢复标准的网页， 只需要重新调用标准的 Rendering Tree，重新渲染一遍网页即可。在这个例子里，我们可以 看到个性化的 Rendering Tree，与 DOM Tree 保持一致的标准的 Rendering Tree，两者并存的场景。 再举一个例子，通常的地图，都是俯瞰图，也就是同一种透视角度。能不能在同一张 地图中包含多个透视视角？听起来匪夷所思，但是有人尝试了这种新奇大胆的设想。如果 套用 DOM Tree 和 Rendering Tree 的概念，可以解释为 DOM Tree 与 R