Blink 引擎相對於 WebKit 好在哪裡？

01-02

Webkit由有蘋果開發的瀏覽器內核，每一個版本的開發均由蘋果完成，webkit2是蘋果將模仿谷歌沙盒並將其嵌入內核的一個版本，由於谷歌也有這樣的功能，於是一直停留在webkit階段，加上谷歌認為他人的開源產品影響開發效率，同時也希望快速脫離蘋果，於是誕生了blink，現階段的目標是精簡結構並且融入自己的元素，以後會完全獨立，現階段仍在使用webkit，好處除了v8 效率更好且支持windows ，沒有了

對於google，這是好東西，好在可以甩開webkit自己隨心所欲的玩。

對於開發者，這是糟糕透頂的事，瀏覽器的分裂更加嚴重了

在多進程架構上，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主幹分離，自己發展新的瀏覽器引擎就成了必然的選擇。

摘自 Why Blink and Why not BlinkWhy Blink and Why not Blink

最大的好處是支持原生支持Dart，不用再受限於javascript。

原文：A high-profile fork: one year of Blink and Webkit

最本質的區別是兩個項目迭代的側重和方向越來越不同

好不好不知道，現在除了蘋果，其它的都去Blink/Chromium陣營了吧...