Why Blink and Why not Blink

清明放假的第一天，Mozilla 和 Google同时宣布了他们新的浏览器引擎的开发计划 —— Servo 和 Blink。Servo 早前其实就一直有消息了，而 Blink 的发布则是相当突然，因为工作的原因，我自然是对 Blink 更感兴趣（放个假都不得安生，苦逼的程序员），更希望了解 Google 为什么要从 WebKit fork 出一个新的浏览器引擎（Why Blink），这样的做法会给 Chrome 后续的发展带来什么样正面变化（Why not Blink）。

在Blink的官方主页里，Google 认为 Blink 的使命是通过技术创新和良好的社区合作来推动开放网络的发展（Blink's Mission : To improve the open web through technical innovation and good citizenship）。根据官方 Developer FAQ 的说法，Google 之所以选择不再继续跟随 WebKit 而是独自开发新的引擎的主要原因是：

There are two main reasons why we’re making this change.  

• The main reason is that Chromium uses a different multi-process architecture than other WebKit-based browsers. So, over the years, supporting multiple architectures has led to increasing complexity for both the WebKit and Chromium communities, slowing down the collective pace of innovation.
• In addition, this gives us an opportunity to do open-ended investigations into other performance improvement strategies. We want web applications to be as fast as possible. So for example, we want to make as many of the browser’s duties run in parallel, so we can keep the main thread free for your application code. We’ve already made significant progress here--for example by reducing the impact JavaScript and layout has on page scrolling, and making it so an increasing number of CSS animations can run at 60fps even while JavaScript is doing some heavy-lifting--but this is just the start.

We want to do for networking, rendering and layout what V8 did for JavaScript. Remember JS engines before V8? We want the same sort of healthy innovation that benefits all users of the web, on all browsers.

在多进程架构上，Google一开始就独自开发了一套沙盒多进程架构，它和后来由Apple主导的WebKit2多进程架构差异很大，为了支持WebKit2架构而加入WebCore的大量代码，对Google不但一点用也没有，还不得不花时间去处理兼容性的问题，而Google需要修改WebCore来支持自己架构的代码又很难进入WebKit主干，必须很小心处理避免影响其它的Port，大量的代码不得不通过迂回的方式放在外部处理，一些没方法在外部处理而需要对WebCore进行大改的特性不得不暂时放弃。

并且，因为历史原因，WebCore本身一开始就没有多线程或者多进程的概念，现有的架构对并行处理的支持非常困难，Google也认为必须对WebCore进行整体架构上的大改才能更好的支持并行处理，更充分利用多核CPU的能力，避免主线程过度拥挤（虽然现在大部分的WebKit Port都把主要的渲染工作分离到其它线程，但是主线程仍然需要负担HTML解析，CSS样式计算和匹配，排版，JS执行等繁重的任务，为了避免单项任务长时间阻塞主线程，WebCore目前是用延时Timer的方式将一个复杂任务分解成多段来顺序执行，这种方式即不优雅，更无法充分利用多核的能力）。

另外，WebCore现在的模块化比较混乱；一些历史遗留的代码和仅仅用于支持某些特定平台的代码导致WebCore代码臃肿不堪；平台相关的处理也没有一个统一的标准和方式，没有一个很好的抽象层去隔离平台相关和平台无关的部分；WebCore为了可以同时支持不同的JS虚拟机（如JSC和V8）导致了 额外的性能开销和妨碍了对JS性能 更多的改进；除此以外，更安全的隔离机制；对现有的网络层进行更大的结构优化等等这些原因也是Google需要自己发展Blink的主要原因。

总之，Chrome有太多激进的改进需要对WebCore进行大改，而原来那种在外围做文章，曲线救国的方式再也行不通，为了能够自行主导架构的演进方向，避免跟其它Port相互干扰，相互扯皮给双方带来的困扰和痛苦，加快开发的速度，从WebKit主干分离，自己发展新的浏览器引擎就成了必然的选择。

从Chrome自身的开发者来看，对此无一不表示欢欣鼓舞之情 ^_^，纷纷表示 —— 

“这实在太令人兴奋啦！我们早就该这么做啦！”

“以后老子想怎么改就怎么改，想蘸糖吃就蘸糖吃，想蘸醋吃就蘸醋吃，再也不用跟那帮斯扯来扯去纠缠不清”

“自从用了Blink以后，内个不痛，月月轻松... so easy！妈妈再也不用担心我的学习啦...”

http://infrequently.org/2013/04/probably-wrong/

https://plus.google.com/u/0/116560594978217291380/posts/AeCnq76cAXb

https://plus.google.com/u/0/105497998876878526147/posts/etnTiaXZEGM

https://plus.google.com/u/0/116237864387312784020/posts/d62jMDKXcLb