近日有两则与浏览器开发相关的重要新闻:一个是 Google 和 Opera 支持 WebKit 的分支 Blink ;另一个是 Samsung 将与 Mozilla 合作,共同推动 Servo 。Blink 和 Servo 均以并行架构为目标。
不久之前,Opera 宣布放弃自己的浏览器引擎 Presto,拥抱WebKit 。当时有人还担心,少了一种多样性对Web 会有何种不利影响。现在他们不必烦恼了,因为Google 从WebKit 创建了一个分支——即名为 Blink 的抽象浏览器引擎,其开发会与 Chromium 结合在一起,由后者提供该平台的一种实现。Opera 的 Web 布道师 Bruce Lawson 宣布, Opera 将与 Google 一起开发 Blink 。
WebKit 渲染引擎现在势头很猛,而且或许有机会成为最重要的引擎,那 Google 为什么要创建一个分支呢? Google 认为,尽管“只有一种选择看上去对开发者的效率有利”,但从长期来看,“只有一种选择不可避免地会导致停滞不前”,而“如果有更多的渲染引擎可以选择,这会带来更多创新,也会使 Web 生态系统更健康”。
据 Google 介绍,之所以创建 WebKit 分支,有两个主要的技术原因:
- 与其他基于 WebKit 的浏览器相比,Chrome 使用了与众不同的多进程架构。此举给 WebKit 和 Chrome 都带来了一定的复杂性,延缓了创新的步伐。
- Blink 提供了一种选择,Google 可以根据自身需要改进其浏览器性能,引入并行处理机制也是一个主要方向。
简而言之,Google 希望“像 V8 对 JavaScript 所做的改进一样,改进网络、渲染和布局。还记得 V8 之前的 JS 引擎吗?我们希望带来同样健康的创新,让使用各种浏览器的 Web 用户都能受益”。
看来 Google 希望能够根据自己的需要自由推动 WebKit 的开发,不必遵守 WebKit 的开发协议,而且能增强自己控制力更强的 Chromium。要成为 Blink 的提交者( Committer )或所有者( Owner ),其他开发者必须遵从 Google 制定的指导原则。
Google 的第一步是重新组织所继承的 WebKit 代码,“移除了 7 个构建系统,删除了 7000 多个文件——包含的代码超过 450 万行”。从长期来看,Google 希望向 Blink 中引入一系列改进,包括:
- 进程外的 iframe ,支持在单独的沙盒进程中运行不同的页面组件。
- 更快、更简洁的网络,目前受限于“旧的 Mac WebKit API 条款而无法修改”。
- 将文档对象模型(DOM)整个移到 JavaScript 中。这有可能大大加快 JavaScript DOM 访问速度。
Google 还考虑了如下可能的改进:
- 让 WebCore 了解多个进程内的历史记录信息(目前假定的是同步访问同一进程内的历史记录信息)
- 删除 Widget 树(原来受到 Mac WebKit1 的限制)
- 将 WebCore 分到多个模块中
- 尽可能让代码直接使用沙盒 Platform API,代替 WebCore/Platform API
- 建立一种更简洁、更严格的 tree-gardening 系统,避免每天需要两个全职工程师参与的情况
- 尝试把 DOM 移到 JS 堆中
- 增加对多核的利用(比如,改进 HTML 解析器、样式引擎和 JavaScript 解析器等模块)
- 去掉 DOM 中不够清晰的部分,这些部分可以做一些向后不兼容的修改,这样有利于提高性能或降低复杂性
- 在 Mac Chrome 中全部使用现代的、速度更快的 tcmalloc
- 尝试增量式布局或并行布局
- 因为现在只有一个 JavaScript 引擎,所以可以移除 ScriptValue/ScriptState 等抽象概念,以此来修复内存泄漏问题
- 使用 WebIDL 替换 WebKitIDL,移除定制的 JavaScript 绑定代码
- 改进 WebCore,使之赶上 DOM3 Event/[DOM]UI Event
新浏览器引擎的出现引发了 Web 开发者的担忧,他们必须确保其代码能在新的浏览器上正确运行。为缓解开发者的焦虑,Google 引入了与 Mozilla 开发 Firefox 类似的机制。
我们的目标是推动创新,改进兼容性,开放 Web 平台,同时避免加入很多特性,避免破坏与其他浏览器的兼容性。关于新特性的添加、厂商前缀(Vendor Prefix)的使用,以及新特性何时才算足够稳定进而可以交付等问题,我们面向开发者引入了强有力的策略。
Firefox 今天所用的 Gecko 引擎并不是基于 WebKit 的,不过二者高度兼容。我们会采用与 Mozilla 类似的方式,提供一个独特但兼容的开源引擎。我们也会继续开放 Bug 跟踪和实现状态,开发者随时可以看到我们在干什么,并做出自己的贡献。
另一个重要策略与厂商前缀有关,Google 不打算将其用于新特性中了:
与之相反,我们会暴露一个设置入口(在about:flags 中),以便支持实验性的DOM/CSS 特性,用户可以在此看到新添加的特性,进而加以试用并提供反馈,很像目前使用的“Experimental WebKit Features”标记。只有当我们想看看这些特性能否稳定交付时,才会在dev/canary 版本中默认启用。
对于遗留的与厂商前缀有关的特性,我们会继续使用-webkit- 前缀,因为重命名所有前缀会给开发者带来不必要的麻烦。我们已经着手研究实际中应用的HTML5 和CSS3 特性,借助调研数据,可以更好地指导我们如何可靠地弃用相关前缀所指定的属性和API。至于从WebKit 继承而来的任何非标准特性(如-webkit-box-reflect),我们希望具体问题具体分析,随着时间的推移,将其标准化或是弃用。
至于一般性的Android 和移动开发,Google 希望“整个移动Web 平台与Blink 同步,甚至走在Blink 的前面”。
之后WebKit 就主要由Apple 掌控了,这是Blink 带来的副作用之一。Apple 能否快速推进WebKit,使其跟上其他浏览器的步伐?我们拭目以待。
就在Google 宣布Blink 几小时前, Mozilla 宣布与 Samsung 合作,共同推进 Servo 的开发。这是用 Rust 开发的一个并行浏览器项目,作为“利用明天速度更快的多核异构计算架构”的一种尝试。Servo 是“完全从头开始重新构建的 Web 浏览器”,纳入了安全机制,并支持高度并行的硬件。
第一步是让它运行在 Android/ARM 上,到目前为止,Samsung 的主要贡献是“Rust 的 ARM 后端,以及支持 Android 交叉编译所必需的构建基础设施”。
目前,Servo 是运行在 Mac OS X 和 64 位 Linux 上的一个原型浏览器引擎,因为它所用的编程语言尚未成熟,很可能还要承受成长之痛。Mozilla 在同一天宣布了 Rust 0.6 ,但该语言要达到稳定,至少还需要一年的时间。在此期间,他们要“争取完成 Rust 的第一个主要版本——完成库的清理、扩充和文档化,构建改进用户体验的工具,增强性能”。
查看英文原文: Google, Opera Fork WebKit. Samsung Joins Firefox to Push Servo
评论