编自http://www.chromium.org/blink
关于blink
Google Chrome/Chromium 从创始至今一直使用 WebKit(WebCore) 作为 HTML/CSS 渲染引擎。WebKit 早先由 Apple 由 KHTML 项目 fork 出来，用于 Safari 浏览器的 Web 引擎。由于宽松的协议、轻量级的设计和便捷的应用程序内嵌 API，WebKit 逐渐变得流行起来，除了 Google Chrome/Chromium 和 Safari，它在移动终端（ Symbian S60，Android，iOS）到 Toolkit 集成(GTK+, Qt4) 都有不错的收获。
尽管上面一众经常被统称为 WebKit，实际上各自都使用了自己的 WebKit 分支或者编译时选项，使得最终的渲染结果也是存在一定的差异的。不过大体上 WebKit 社区内部还是比较和谐的，各个成员之间也为维持兼容性作出了努力，直到 2010 年随着 OS X Lion 一起面世的 WebKit2。由于 WebKit2 在 WebCore 层面上实现的进程隔离在一定程度上与 Google Chrome/Chromium 自己的沙箱设计存在冲突，故 Google Chrome/Chromium 一直停留在 WebKit，使用 Backport 的方式实现和主线 WebKit2 的兼容。显而易见这增加了 WebKit 和 Chromium 的复杂性，且在一定程度上影响了 Chromium 的架构移植工作。
基于以上原因，Google 决定从 WebKit fork 出自己的 Blink Web 引擎：
现阶段以精简内部结构为主，将删除大约 7000 个文件和 450 万行 WebKit2 兼容代码。
未来将着重改善 DOM 架构，将使用 JavaScript 实现 DOM。
提升安全性，实现进程外 iframes 。
对于今年初宣布放弃自有渲染引擎跟随 Chromium 的 Opera 来说，其开发者也立刻发布博客公告 Opera 亦将切换至 Blink 引擎。 [1]
尽管上面一众经常被统称为 WebKit，实际上各自都使用了自己的 WebKit 分支或者编译时选项，使得最终的渲染结果也是存在一定的差异的。不过大体上 WebKit 社区内部还是比较和谐的，各个成员之间也为维持兼容性作出了努力，直到 2010 年随着 OS X Lion 一起面世的 WebKit2。由于 WebKit2 在 WebCore 层面上实现的进程隔离在一定程度上与 Google Chrome/Chromium 自己的沙箱设计存在冲突，故 Google Chrome/Chromium 一直停留在 WebKit，使用 Backport 的方式实现和主线 WebKit2 的兼容。显而易见这增加了 WebKit 和 Chromium 的复杂性，且在一定程度上影响了 Chromium 的架构移植工作。
基于以上原因，Google 决定从 WebKit fork 出自己的 Blink Web 引擎：
现阶段以精简内部结构为主，将删除大约 7000 个文件和 450 万行 WebKit2 兼容代码。
未来将着重改善 DOM 架构，将使用 JavaScript 实现 DOM。
提升安全性，实现进程外 iframes 。
对于今年初宣布放弃自有渲染引擎跟随 Chromium 的 Opera 来说，其开发者也立刻发布博客公告 Opera 亦将切换至 Blink 引擎。 [1]
谷歌Blink的横空出世将使它和其他的WebKit浏览器开发商包括——苹果、诺基亚和黑莓——更彻底地分道扬镳。
这一举措意味着，现在有四大渲染引擎在线：WebKit、Blink、Trident 和Gecko。对于用户来说，渲染引擎的差异化意味着他们在使用不同浏览器打开同一网页时将得到不同的结果——在移动设备上尤其如此。
谷歌并在一篇博客文章里写道：“我们知道，新的渲染引擎的出现将对网页浏览产生重大影响。”但谷歌补充说，它认为多个渲染引擎 “能够推动创新，并增进整个网络生态系统的健康。”
谷歌此举有很大风险。根据NetMarketShare的
数据，Chrome 浏览器目前是台式机最常用的浏览器之一。而根据Statcounter的统计，Chrome 浏览器目前是台式机最常用的浏览器。NetMarketShare统计的是访客数量，而Statcounter只统计点击量。如果谷歌的新战略不成功，Chrome 浏览器的统治地位或将不保。
Chrome 28开发版本的版本说明中还在使用WebKit，而最新的Chrome 28.0.1469.0中已经替换为Blink。
Blink 的架构变化
当chrome项目开始时，我们的目标是尽可能少的改动Webkit，易于同webkit的代码合并。
对于blink我们兴奋于创建一个更大的架构灵活性的代码，而无需担心其他webkit的用户。
我们计划增加一个 “out-of-process iframes”, 这将使chromium能够分离页面中一个独立的部分到一个分离的沙箱进程。
实现这一点需要大量改动webkit关于iframe的处理。
另外一个例子，我们将修复网络代码，让它更小更快。目前webkit中的网络代码受限于老的mac webkit API，而且不能改变。
chromium已经在其周边工作了很多年，但是这些周边的工作易碎而且bug很多。
在Blink中，我们将使用新的网络代码，而无需强制和其他webkit用户统一。
最后，我们甚至希望将整个DOM树用javascipt来实现。这将使javascript访问更加迅速。但是这需要大量重写Webkit DOM部分的实现。这也是Webkit同时支持两个javascript引擎更近困难。
我们考虑的其他的一些改变
- 让WebCore支持多进程历史（当前，它假定同一个进程同步历史）
- 删除Widget 树（Mac Webkit1的一个约束）
- 分离WebCore到不同模块
- 将直接使用沙箱平台的API，替代目前WebCore/Platform
- Establish a simpler, stricter tree-gardening system that does not require 2 full time engineers per day (这句看不懂，谁能帮我翻译下？谢谢了）
- 尝试将DOM 移动到JS的堆上
- 增加多核复用（如 html 解析，style 引擎和javascript解析）
- 移除DOM中模糊不清的部分和因为向后兼容而引起的模糊不清部分，或者移除不必要的兼容性
- 使用现代的、更快的tcmalloc(google编写的多线程内存分配软件，替代malloc)来贯穿 Mac chrome
- 尝试并行布局
- 通过移除ScriptValue/ScriptState抽象来避免内存泄漏
- 使用WebIDL来替代WebKitIDL，并移除Javascript绑定代码
- 通过DOM3 Events/[DOM]UI Events提上WebCore速度