webkit技術內幕讀書筆記 (一)

本文部分摘錄自互聯網。

Chromeium與Chrome

Chromium是Google爲發展自家的瀏覽器Google Chrome而打開的項目，因此Chromium至關於Google Chrome的工程版或稱實驗版（儘管Google Chrome自身也有β版階段），新功能會率先在Chromium上實現，待驗證後纔會應用在Google Chrome上，故Google Chrome的功能會相對落後但較穩定。

Chromium的更新速度很快，每隔數小時即有新的開發版本發佈，並且能夠免安裝，下載zip封裝版後解壓縮便可使用（Windows下也有安裝版）。Chrome雖然理論上也能夠免安裝，但Google僅提供安裝版。

Google Chrome是基於Chromium製造，但包含非開放源代碼包，主要是多媒體相關。

Chromium

Blink

Google但願將來在Blink中加入的新技術以下：

1. 實現跨進程的iframe。iframe容許網頁中嵌入其餘頁面，這存在潛在的安全問題。一個新的想法就是爲iframe建立一個單獨的沙箱進程。該部分的介紹在第12章展開。

2. 從新整理和修改WebKit關於網絡方面的架構和接口。長期以來，WebKit中的一些實現是以Mac OS平臺爲基礎的，因此存在某些方面的限制，Blink將會在這方面作比較大的調整。

3. 一個更爲膽大更爲激進的想法就是將DOM樹引入JavaScript引擎中。由前面的介紹能夠看到，目前DOM和JavaScript引擎是分開的，這意味着JavaScript引擎訪問DOM樹須要較高的代價。筆者認爲這是一個大膽而又具備革命性的嘗試，會帶來性能的極大提高，爲何呢？緣由是JavaScript引擎訪問DOM樹須要額外的負擔，這影響了訪問速度。

4. 就是針對各類技術的性能優化，包括可是不限於圖形、JavaScript引擎、內存使用、編譯的二進制文件大小等。

Chromium瀏覽器之渲染引擎Blink

whatwg與w3c

瀏覽器廠商和標準組織博弈出來的產物，重要的是明白它們背後的人是誰。WHATWG受到了Opera, Mozilla和Chrome, Safari的支持，而W3C的背後則隱藏着IE這個微軟菊苣。私覺得在工業發展速度遠遠超過標準定義的今天，WHATWG或許會更權威一點。關於HTML5標準的定製，最開始是WHATWG在作的，因爲到後期大部分瀏覽器廠商都已經實現了統一標準，W3C想不支持也是不行的啊，這就是傳說中的霸王硬上弓

xhtml仍是html

總的來講我仍是更喜歡html一點，儘管xhtml更加的規範，但我以爲怎麼編寫代碼是開發人員自身的問題，而不該該將其強制，好比：單標籤的閉合，我以爲單標籤閉合無關緊要。

html5

一次編寫，處處運行(Write once, Run anywhere)是每個程序員的夢想。當年的Java沒有作到，本來程序員們期望Web標準可以作到。然而事實上是，只要瀏覽器大戰沒有消停，HTML5也作不到。

有人說HTML5很差，由於用戶討厭打開瀏覽器輸入URL的過程。我想說這種想法是對HTML5的片面理解。HTML5!=傳統瀏覽器，雖然編程語言仍是HTML、Javascript、CSS，但發行方式毫不是傳統網站那麼簡單。HTML5應用的入口，反而不多是啓動瀏覽器輸入URL，它能夠是存在於手機桌面的圖標、也能夠來自超級App（如微信朋友圈）、以及搜索引擎、應用市場、廣告聯盟，處處都是它的入口。它的入口，比原生App更多。

目前各路瀏覽器廠商、應用市場廠商、甚至rom廠商，都在努力整合更優質的瀏覽器引擎。假使微信內嵌的webview能夠運行更優秀的canvas遊戲、假使360手機助手能夠發行即點即用的HTML5應用而且能力體驗與原生一致、假使小米rom內置更強大的webview使得全部HTML5應用在小米手機上運行的更流暢。全部巨頭都會聞風而動，沒錯，這場戰役會是移動互聯網世界的二次世界大戰。

早期HTML只須要記事本寫幾個Tag，中期的HTML、JS、CSS比較複雜，須要更高級的文本編輯器，但HTML5到來後，它的代碼量、複雜度、開發模型將與原生開發看齊，須要相似XCode、Eclipse等專業的IDE工具來解決開發、調試的問題。一些以會使用記事本寫代碼爲榮的開發者，將面臨思路轉換甚至被更高效的開發者淘汰。

web的不斷髮展意味着，會有更多的api，所以若是咱們還靠去死記硬背是不行的了，同時也意味着你不可能將web的全部技術掌握，咱們須要更強大的IDE工具，以及學習能力。

混亂的用戶代理

早期內容供應商爲了給用戶提供更好的網站體驗，爲不一樣的瀏覽器提供了不一樣的內容，而IE廠商發現，不少內容供應商爲Mozilla提供的內容比本身更加的豐富，後來IE廠商想出了一個法子，在用戶代理中加入一條Mozilla的信息，後來其餘瀏覽器廠商也紛紛效仿，致使最後用戶代理異常混亂。

既然選擇全部瀏覽器廠商都這樣作了，還使用這種方式就沒有什麼用處了，我想之後瀏覽器廠商會從新迴歸到最初。

用戶代理能夠作什麼

經過用戶代理，咱們能夠用來判斷用戶使用的是什麼瀏覽器，而根據瀏覽器的不一樣，使用不一樣的樣式，又或是一次兼容問題，但若是涉及到一些安全性問題，千萬別經過用戶代理來判斷，由於用戶代理是能夠經過人工修改的。

推薦閱讀：自定義UserAgent繞過安全狗

更改Chrome用戶代理

chrome 下修改 agent 的方法
Change User Agent in Google Chrome
瀏覽器USER-AGENT（用戶代理）的介紹

瀏覽器內核

雖然使用Linux內核的操做系統很是多，但某些操做系統對內核作了不少改變，所以雖然不少操做系統使用的內核是同樣的，但它們的差異仍是很大的。

以前比較疑問，既然移動端大部分瀏覽器使用的是webkit內核的，可是顯示出的效果差異卻那麼大，今天算是明白了，雖然它們是同一個內核，可是每一個瀏覽器廠商卻作了不一樣的處理。

多線程

一個應用程序是不是多線程，不只僅是應用程序的問題，更取決於操做系統是否支持多線程，由於你的程序是在人家操做系統上跑的。

webkit於webkit2

WebKit2是面向WebKit的一個新的API層，從底層設計，以支持拆分過程模型，其中Web內容（JavaScript，HTML，佈局等）與應用程序UI在一個單獨的過程當中。 該模型與Google Chrome提供的模式很是類似，主要區別在於咱們將流程分割模型直接構建到框架中，容許WebKit的其餘客戶端使用它。

這與Chromium WebKit有何不一樣？

Chromium採用不一樣的多進程方法：

請注意，在這種狀況下，進程邊界是*以上的API邊界。 Chromium WebKit不直接提供多進程框架，而是針對多進程應用程序的一個組件進行了優化，它能夠執行全部代理和進程管理。谷歌的Chrome團隊在開發Chrome瀏覽器的多進程瀏覽方面作得很是出色。可是很難重用他們的工做，由於進程管理，流程和沙盒之間的代理關鍵邏輯都是Chrome應用程序的一部分，而不是API層的一部分。所以，若是另外一個基於WebKit的應用程序或另外一個端口想要基於Chromium WebKit進行多進程，則須要從新建立或剪切並粘貼大量代碼。

這是Google的一個能夠理解的選擇 - Chrome被開發爲一個祕密項目多年，而且深刻投資於這種方法。此外，尚未任何其餘重要的API客戶端。有Chrome瀏覽器，而後有緊密相關的Chrome框架。

WebKit2有一個不一樣的目標 - 咱們但願流程管理成爲WebKit自己提供的一部分，以便任何應用程序均可以輕鬆使用。咱們但願聊天客戶端，郵件客戶端，twitter客戶端以及人們使用WebKit構建的全部創意應用程序，以便可以利用此技術。咱們相信這是Web內容引擎應該提供的基本部分。

Webkit2