[[63387]]

WebKit究竟是什么？

最近WebKit這個詞鋪天蓋地，它究竟是什么意思呢？

官方解釋：WebKit是一個開源的Web瀏覽器引擎。WebKit同時也被MacOS X系統(tǒng)的Safari、Dashboard、Mail和很多其他OS X程序選用為引擎。WebKit的HTML解析器和JavaScript解析器代碼分別源自KDE的KHTML和KJS代碼庫。

這就是在說，WebKit是Safari背后的瀏覽器引擎。還需要補充的是，Apple在Safari里面使用了自己的Nitro JavaScript引擎（只用WebKit來渲染HTML）。

有意思的是WebKit現(xiàn)在已經不僅僅是蘋果在使用，它現(xiàn)在還是Google Chrome的內核：

Google官方說明：Chromium使用WebKit做為渲染引擎。與其打造Chromium特有的實現(xiàn)方式，我們更希望去盡可能多的去為使用WebKit核心的瀏覽器做貢獻。

這是說Chrome也在使用Nitro JS引擎？不，Chrome有他自己的V8 JavaScript引擎。簡單的說，Chrome也使用WebKit，但是它也實現(xiàn)了自己的JavaScript處理方式。V8同時還是驅動Node.js的JavaScript引擎。

Opera會使用Chromium實現(xiàn)的WebKit，也會使用V8引擎。這就是說雖然Opera在宣稱自己使用WebKit，但事實上它使用WebKit和Safari與其他瀏覽器使用的WebKit并不完全一樣。如果你想客觀了解現(xiàn)狀，這是必須清楚的概念。

現(xiàn)在WebKit究竟有多少分支？

所以我們知道現(xiàn)在WebKit正在驅動，或者將會驅動3個主流瀏覽器。但是WebKit還有多少其他類型的實現(xiàn)？

確實還有很多很多WebKit的變種，特別是在移動領域。他們都是WebKit的分支。

這些WebKit的分支有多少差別？

有一種假設：因為這些瀏覽器都在使用WebKit，所以他們也會以同樣的方式去支持相同的特性。對于很多基本的特性來說，確實是這樣。但是對于很多小眾特性，就未必如此了。

舉例來說，當Chrome開始支持游戲手柄API的時候，Safari不但還沒開始支持，而且以后也不太可能支持。另一個例子是WebGL。做為在 Chrome已經支持了很久的特性之一，Safari卻才剛剛看到了曙光（而且還是在開發(fā)者選項里）。當然，這些還都是比較出名的例子。還有很多試驗性的 例子潛伏在大眾的視野之下。

甚至很多基礎的、日常的功能，在不同的代碼分支下都有所不同。PPK完整的總結了這些WebKit的差異。

新特性如何加入到WebKit中，誰又來負責審核？

現(xiàn)在有許多公司正在為WebKit項目貢獻自己的力量。

WebKit項目提交和審查頁面提到只能有老的代碼提交員和審核員才能提名新的新的代碼提交員與審核員。這比較合理。然而，無論WebKit項目決定讓誰參與進來，最終都還是要讓Apple來做審核：

當有人被WebKit代碼提交員成功提名后，Apple會處理發(fā)送代碼提交員協(xié)議，在簽署協(xié)議之后，Apple會繼續(xù)開通SVN賬戶。

對于這一點并沒有什么隱秘的動機，但這確實在告訴大家，WebKit和很多開源項目一樣，并不是真正分散和民主的。權利是且必須是集中的——只有這樣才能保證能做出決定，并且把事情做成。

如果一個瀏覽器遷移到了WebKit，那是不是意味著（在編寫代碼的時候）可以少測試一個瀏覽器了？

不。每個瀏覽器都有它自己的怪異模式、性能差異、設計，和功能。所以每個瀏覽器都要測試。

當一個功能加入到WebKit的時候，是不是意味著在其他瀏覽器里就可以使用這功能了？

當然不是。比如游戲手柄API的例子。Paul Irish強調了這樣一個事實：WebKit瀏覽器們可以挑選究竟把哪些API放入他們的版本。比如Chrome選擇支持游戲手柄API。很多API在WebKit的層面就已經被實現(xiàn)了，但是WebKit項目書允許關閉這些功能。（編者注：Paul Irish是Google Chrome的員工，他曾在jQuery團隊工作兩年。）

Opera遷移到WebKit究竟意味著什么？

它意味著Opera將會為WebKit項目投入開發(fā)精力，但是更可能的是，意味著這Opera將會在有經歷為自己的瀏覽器打造一些其他的功能。

遷移到WebKit意味著我們可以把更多開發(fā)資源投入到新功能和增進用戶體驗的解決方案上去。

這也意味著他們不會再繼續(xù)開發(fā)他們的自有Web渲染引擎Presto。

同源和多樣化

上面的問題和回答告訴我們，WebKit們很明顯有著相同的源頭。在不同的瀏覽器版本里他們又有著不同的實現(xiàn)，但是歸根結底，他們共享著相同的代碼庫。

這意味著你可以為移動互聯(lián)網、為性能、為任何你能想到的目標來優(yōu)化WebKit。這是件好事兒。而且這必然會帶來各種各樣的WebKit實現(xiàn)，并為解決問題引入更多資源。在最理想的情況下，這些進步會回饋給每個人。

這會帶來非常多好處。這也是我們?yōu)槭裁聪嘈牛型耆煌囊蝗喝耍瑏泶蛟煲粋€瀏覽器渲染引擎是非常重要的。

Apple在KHTML上構建WebKit是一件好事情。他們當初也可以選擇在Gecko上做這件事情（編者注：Gecko是Firefox的引擎），但他們選擇了創(chuàng)新，給市場增加了多樣性，還帶領瀏覽器在過去幾年里取得了巨大的進步 —— 這就是競爭帶來的直接結果。

如果他們只是做了另一個版本的Gecko，那我們也不確定我們今天會是個什么情況。

渲染其實并不相同

把WebKit先撇一邊兒，如果所有的瀏覽器都使用相同的引擎，這對程序員來說意味著什么？這種情況真的會發(fā)生嗎？Web會因此更加美好嗎？對開發(fā)者來說工作會不會更輕松一些？

最大風險在于程序員們如果相信這些瀏覽器如果都在使用完全相同的渲染引擎，那么：

• 開發(fā)者不會再測試那么多瀏覽器了，因為他們認為反正瀏覽器都是WebKit核心的
• 開發(fā)者也不再測試其他的瀏覽器引擎了，反正WebKit占據(jù)了主流
• 開發(fā)者將會更多使用WebKit引擎獨有的代碼，而不是專注使用Web標準

最可能的后果是程序員會選擇——或者被導向——相信內核的統(tǒng)一會讓工作變輕松。但是隨著時間的流逝，他們會意識到盡管同是WebKit，也會有很多不同的東西。（見PPK總結的WebKit之不同）。

這給IE和Firefox留下了什么局面？

讓我們來清醒一下，看看這對Microsoft和Mozilla來說意味著什么。現(xiàn)在有很多聲音，認為他們應該用WebKit來實現(xiàn)IE和Firefox。

但這真的那么容易嗎？如果這樣的話，所有主流瀏覽器都會構建于一個相同的代碼庫。但是還會有很多的可變因素，代碼分支，插件，等等。對我們來說，這似乎并不是達到多樣性的最佳方式。

如果IE和Firfox不切換渲染引擎呢？這很可能會是一場精彩的競賽，并會為我們帶來一個光明的未來。但與此同時，這也給MicroSoft和Mozilla出了難題：他們將在實現(xiàn)各個層級的Web標準，提升性能，和很多其他方面耗費很多精力，并遇見重重挑戰(zhàn)。

如果市場份額逐漸萎縮，讓WebKit完全統(tǒng)治？也許人們將會使用IE和Firefox，而不使用WebKit？

在未來的歲月里，F(xiàn)irefox和IE有沒有被逐漸淘汰的風險？或者他們會成為不同的因素留在市場上？

瀏覽器廠商的動機是什么

除了現(xiàn)在已經有很多不同WebKit版本的事實以外，還有很多Web瀏覽器在參與競爭，試圖與眾不同。其中一些相信競爭很大程度將會體現(xiàn)用戶體驗領域。這點沒錯，但是在此領域以外，也有很多競爭點。

在《WebKit的悲劇》一文中提到的那樣，誰會對花錢花資源來為競爭對手修補bug呢？

看上去大家更有可能會把精力花在新特性，新功能上，因為這會才讓他們在競爭中脫穎而出。

在這一點上，你將如何發(fā)現(xiàn)新的元素呢？新功能在某些程度上還會被發(fā)現(xiàn)。但是CSS呢？一個-webkit前綴的CSS屬性意味著什么？其實什么意義都沒有，除了它會支持IE和Firefox以外的任何其他瀏覽器。下一步又會發(fā)生什么？更多的瀏覽器廠商的CSS前綴嗎？

WebKit是好的

允許我們強調一下，WebKit是好的。它有開放的流程和強大的貢獻者。我們只是想澄清一個當下被廣泛接受的錯誤概念——一個WebKit等于所有WebKit，還有——如果所有瀏覽器都選擇WebKit，那么對開發(fā)者來說，工作會變得更輕松。

我的意思是說，與眾多獨立的瀏覽器引擎會為市場帶來多樣性一樣，WebKit在這一點來說，同樣會表現(xiàn)的很棒。