Google Chromium 為什麼要從 WebKit 中抽離，新建一個 Blink 分支？對 Chrome 有什麼影響？
Chromium Blog: Blink: A rendering engine for the Chromium project:
Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit.
Webkit2 主要的貢獻是 Apple，Webkit 的未來並不明朗。雖然 fork 一個 Blink 而且依然開源，但除掉 Apple 的代碼後 Blink(包括現在主線的 Webkit)的最主要貢獻者就是 Google 自己了，Google 認為這樣可以加快改進速度。
而且 Google 認為 Apple 在實現標準方面過於保守，Google 則更樂於實現各種草案標準，即使該標準處於 Working Draft 甚至是 Editor Draft 階段，未來面臨大改甚至廢棄的可能。但是對於開發者來說，你必須把標準放出來給他們用，他們才能用實踐告訴你這東西好不好用，要不要改，怎麼改。關於這個問題， Ars Technica的John Siracusa的一篇文章"Code Hard or Go Home"前半部分寫得很清楚，看了這篇文章，答案也就出來了。說到底，蘋果不進取，Google對Webkit的貢獻越來越大，爲什麽不fork一下呢？現搬運如下：
When Apple decided to make its own web browser back in 2001, it chose KHTML/KJS from the KDE project as the basis of its rendering engine. Apple didn』t merely 「adopt」 this technology; it took the source code and ran with it, hiring a bunch of smart, experienced developers and giving them the time and resources they needed to massively improve KHTML/KJS over the course of several years. Thus, WebKit was born.
In the world of open source software, this is the only legitimate way to assert 「ownership」 of a project: become the driving force behind the development process by contributing the most—and the best—changes. As WebKit raced ahead, Apple had little motivation to help keep KHTML in sync. The two projects had different goals and very different constraints. KDE eventually incorporated WebKit. Though KHTML development continues, WebKit has clearly left it behind.
When Google introduced its own web browser in 2008, it chose WebKit as the basis for its rendering engine. Rather than forking off its own engine based on WebKit, Google chose to participate in the existing WebKit community. At the time, Apple was clearly the big dog in the WebKit world. But just look at what happened after Google joined the party. (Data from Bitergia.)
WebKit: Reviewed Commits
Google has already proven that it has the talent, experience, and resources to develop a world-class web browser. It made its own JavaScript engine, its own multi-process architecture for stability and code isolation, and has added a huge number of improvements to WebKit itself. Now it』s taken the reins of the rendering engine too.
Where does this leave Apple? All the code in question is open-source, so Apple is free to pull improvements from Blink into WebKit. Of course, Google has little motivation to help with this effort. Furthermore, Blink is a clearly declared fork that』s likely to rapidly diverge from its WebKit origins. From Google』s press release about Blink: 「[W]e anticipate that we』ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat.」 (There』s some streamlining in the works on the other side of the fence too.)
Does Apple—and the rest of the WebKit community—have the skill and capacity to continue to drive WebKit forward at a pace that matches Google』s grand plans for Blink? The easy answer is, 「Of course it does! Apple created the WebKit project, and it got along fine before Google started contributing.」 But I look at those graphs and wonder.
The recent history of WebKit also gives me pause. Google did not want to contribute its multi-process architecture back to the WebKit project, so Apple created its own solution: the somewhat confusingly named WebKit2. While Google chose to put the process management into the browser application, Apple baked multi-process support into the WebKit engine itself. This means that any application that uses WebKit2 gets the benefits of multi-process isolation without having to do anything special.
This all sounds great on paper, but in (several years of) practice, Google』s Chrome has proven to be far more stable and resilient in the face of misbehaving web pages than Apple』s WebKit2-based Safari. I run both browsers all day, and a week rarely goes by where I don』t find myself facing the dreaded 「Webpages are not responding」 dialog in Safari that invites me to reload every single open tab to resume normal operation.
原文鏈接：http://hypercritical.co/2013/04/12/code-hard-or-go-homeGoogle: 我們想做這個
Apple: 不行Google: 我們想這麼改Apple: 不行
.....Google: 去你丫的，我自己玩了互聯網公司講究Move Fast，而且Google對HTML5態度也比較激進，越早做實現，就越能發現標準中的缺陷，這樣反過來也能影響HTML5的標準，雙贏！摘自LinuxToy xero：chromium的相關技術在實現了一年多之後webkit2才將這些功能實現，並且和chromiun中的架構有些不同（之前Google提交的patch一直被拒絕，所以才有了webkit2）.隨著webkit2和chromium越走越遠，對google來說是巨大的負擔，維護兩套codebase，自己技術發展的很快，還必須時不時的等等webkit2，花大量的經歷去維護兼容庫，這才有了blink。 另外，看chrome的官方文檔上面說：chromium那種架構（不同於webkit2）更加靈活，也就是說：chrome這個瀏覽器內核不是固定死的，可以在上層代碼不變的情況下非常靈活的使用其他的內核，甚至使用firefox老式的gecko內核。它當初設計的時候就說了不會在一個內核上弔死。對於google這種性能狂，如果有新的更高效的內核，它肯定不會視而不見的。而對用戶來說：如果內核之上的通用介面實現的比較好，和其他瀏覽器技術兼容性良好的話，換什麼內核對用戶來說幾乎是透明的，除了感覺到更加快了。 opera的移動版瀏覽器本來就是基於chromium的，而非webkit2，所以轉向blink實在是很自然的事情。
先說一下，這是必然的。以下鏈接說的很透徹了：不看蘋果臉色！谷歌Blink重啟瀏覽器大戰
有優勢了，就要建立自己獨特的標準。做法和當初的IE一樣。
瀏覽器標準問題一直是各方爭奪的前沿陣地，Google先藉助Webkit聯合蘋果等，以「IE不遵守標準」為由幹掉了IE，順手幹掉了OP，FF也處境艱難。這個時候Chrome已經建立了極大的優勢，可以進行一些「建立標準」的事情了。但是顯然，一個由多個巨頭組成的聯合體，無法滿足Chrome的要求，有必要另立門戶了。在多進程架構上，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 BlinkChromium Blog: Blink: A rendering engine for the Chromium project:rendering engine VS js engine08:21 Google Chromium 為什麼要從 WebKit 中抽離，新建一個 Blink 分支？對 Chrome 有什麼影響？ - 谷歌 (Google)
想自己做老大唄～
推薦閱讀：
TAG:谷歌Google | 瀏覽器內核 | Blink瀏覽器內核 |