Blink:Chromium fork WebKit而来的渲染引擎

导读:2013年4月3日(美国当地时间),Google宣布其将 fork WebKit,新建一个网页渲染引擎(rendering engine)分支,取名 Blink。同一天,Opera 也确认将跟随 Google,参与 Blink 的实现。

补充:① 2013年2月12日,Opera 宣布放弃自家的 Presto 引擎,切换到 WebKit(严格来说,是切换到 Chromium 项目在维护的 WebKit 分支),和 Chrome 浏览器使用同一个代码库。② Safari  在2010年已更新到 WebKit2 分支了。

Blink's Mission:To improve the open web through technical innovation and good citizenship

Blink 的任务:通过技术创新和良好公民,提高开放网络

以下这段话摘译自 Opera 员工 Bruce Lawson 的博客

[英国时间 4月3日 22:46 补充] 我老板,Opera 的代表,Lars Erik Bolstad 表示:“我们的目标是,把 Opera 浏览器引擎的专业知识贡献给 Blink,从新网络标准的实施到现有代码的改进。”

 

以下内容是编译自 Chromium 官博。

WebKit 是一个轻量级但功能强大的网页渲染引擎(也称“排版引擎”),2001年脱胎于 KHTML。在我们发起 Chromium 项目之初,WebKit 的灵活性、性能和贴心设计,使其成为我们的不二之选。感谢社区所有成员的辛勤工作,从那时开始,WebKit 已茁壮成长,并且跟上了网络平台不断增长的功能。

译注:根据StatCounter的浏览器市场份额调查,在2012年11月,Webkit市占超过了40%,它已经成为拥有最大市场份额的排版引擎。

然而,和其他基于WebKit的浏览器相比,Chromium 采用了不同的多进程架构。多年来的支持多种架构,已导致WebKit和Chromium项目的复杂性都增加了。这已经放慢了集体创新的步伐,所以今天,我们给大家介绍 Blink,一个新开源的网页渲染引擎,是WebKit的一个分支。

这并不是一个容易的决定。我们知道,引入一个全新的网页渲染引擎,对网络而言,有着显著影响。不过,我们相信,有多种渲染引擎,就如同有多种浏览器,将会激发创新,随着时间的推移,也会提高整个开放网络生态系统的健康。

短期来说,Blink 会给Web开发人员带来一些变化。前期大量的工作将侧重于内部架构的改进和代码库的简化。比如,我们预期要移除 7 个 build 系统,删除超过 7,000 个文件,包括 450+ 万行代码。(译注:删除的这些代码,就是只支持 WebKit2 特性的代码。 )从长远来说,一个更健康的代码库,也就意味着更多的稳定和更少的Bug。

在整个过渡中,我们将和其他浏览器厂商密切合作,推动网络向前发展,维护使其成为一个成功生态系统的兼容性。本着这种精神,我们已经设置了一个Blink新特性的指南。欲了解Blink的更多信息,请访问我们的项目主页

 

Blink 的一些特性,摘自 Blink 的“开发者 FAQ” (保留了英文原文,以免译文不到位)

What sorts of things should I expect from Chrome?

In the Blink Architectural Changes section we have listed a few changes that will improve the speed and stability of the web platform in Chrome. Meanwhile, there are more improvements whose feasibility and performance benefits we’re excited to investigate:

  • Deliver a speedier DOM and JS engine
    • Multi-process, security-focused, and faster low-overhead DOM bindings to V8
    • JIT DOM attribute getters in V8. That would allow V8 to access div.id, div.firstChild, etc without leaving JIT code. Mozilla is also meanwhile trying to JIT DOM attribute getters.
    • Implement the DOM in JS. This has the potential to make JavaScript DOM access dramatically faster, but will involve a very large re-write of WebKit’s DOM implementation. IE is already doing this and overall, this helps yield faster GC, and faster DOM bindings
    • Support snapshotting in V8. This could allow us to have no parse-time overhead and near-instant startup of previously loaded pages.
  • Keep the platform secure
  • Refactor for performance
    • Reduce binding layer overhead. We can make things even faster by simplifying the many abstractions in the binding layers that have existed to share code between JavaScriptCore and V8 (e.g. ScriptState, DOMRequestState, etc).
    • Improve the performance of style resolution.
    • Improve utilization of multiple cores.
  • Enable more powerful rendering and layout
    • Pursue multi-threaded layout
    • Overhaul style recalculation and selector resolution performance
    • Stop creating renderers for hidden iframes
    • Fix old bugs like plugins unloading when they’re set to display:none.
    • Allow generated content to be selectable and copy-pasteable.
    • Rewrite event handling to be more consistent and have fewer bugs with focus, mouse up, clicks, etc.
    • Fire <iframe> unload events async to make removeChild faster.

 

原文:blog.chromium    编译:伯乐在线 – 黄利民

译文链接:http://blog.jobbole.com/37366/

【非特殊说明,转载必须在正文中标注并保留原文链接、译文链接和译者等信息,谢谢合作!】

1 收藏 4 评论

关于作者:黄利民

伯乐在线联合发起人,关注 IT 和互联网。 个人主页 · 我的文章 · 97 ·  

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部