原文:https://developers.google.com/web/updates/2018/09/inside-browser-part1web
(最近在看底層類的文檔,有不少是英文文檔。所以我以爲反正都要看的,順便翻譯出來,方便之後查閱)瀏覽器
在這個由4部分組成的系列文章裏,咱們將介紹Chrome瀏覽器內部從高級架構到渲染管道的細節。若是你想知道瀏覽器如何將你的代碼轉換爲功能性網站,或者你還很疑惑爲何建議一些特定方法來提升性能,那麼本系列很適合你。安全
做爲本系列的第1部分,咱們將介紹核心計算術語和Chrome的多進程架構。
架構
注意:若是你熟悉CPU / GPU和進程/線程的概念,則能夠跳到瀏覽器體系結構。
ide
爲了瞭解瀏覽器運行的環境,咱們必須得知道一些電腦部件和它們的功能。svg
首先是中央處理器—CPU。你能夠將CPU當作電腦的大腦。CPU的核心,在這張圖片裏看着就像辦公室裏的工做人員,當他們進來之後能夠逐個處理不一樣的任務。它能夠在邊回覆客戶電話的同時處理從數學到藝術等各類事情。在過去,大多數CPU都是單芯片。核心(core)就像住在同一個芯片裏的另外一個CPU。在現代硬件裏,你一般會得到多個核心,給你的手機和筆記本電腦了更強大的計算能力。工具
圖1:4個CPU核心做爲辦公室工做人員坐在每一個辦公桌處理任務
性能
圖形處理器—GPU是電腦的另外一個部分。同CPU不一樣的是,GPU更擅長在跨多個核心的同時處理一些簡單的任務。就像其名字所代表的同樣,它最初是被開發來處理圖像的。這就是爲何當提到「使用GPU」或「以GPU爲支持」時,跟着的就是快速的渲染和流暢的互動。近些年來,隨着GPU計算速度的提高,愈來愈多的計算能利用GPU單獨完成。網站
圖2:許多帶有扳手的GPU核心代表它們處理的任務有限google
當你在你的電腦或手機上啓動一個應用程序時,支持這個程序運行的就是CPU和GPU。一般,應用程序使用操做系統提供的機制在CPU和GPU上運行。
圖3:三層計算機體系結構。機器硬件位於底部,操做系統位於中間,應用程序位於頂部。
在潛入瀏覽器內部前還要掌握的另外一個概念就是進程和線程。( Process and Thread)一個進程能夠當作是一個應用的執行程序。線程是進程裏面的執行進程程序的任何部分的。(線程在進程內部,一個程序就是一個進程,進程裏面就是一個個線程)。
當你啓動一個應用程序時,一個進程就建立好了。進程可能會建立一個線程去幫助它開展工做,但那不是必須的(可選)。操做系統爲工做中的進程提供了一個內存塊("slab" of memory),全部的應用狀態都保存在那個私密的內存空間裏。當你關閉這個應用時,進程也會隨之而消失,操做系統會釋放這個內存。
圖4:做爲邊界框的進程,線程做爲在進程內遊動的抽象的魚
click on the image to see animation(點擊上圖看動效)
圖5:使用內存空間和存儲應用程序數據的進程圖
一個進程可讓操做系統啓動另外一個進程來運行不一樣的任務。當這種狀況發生時,內存的另外一個部分會被分配給這個新的進程。若是兩個進程之間須要對話,他們能夠IPC(進程間通訊Inter Process Communication)來實現。不少應用程序被設計成以這種方式工做是爲了當其中一個進程不響應時,它能夠重啓而且不會影響運行應用程序的其餘部分的進程(其餘進程不會所以被中止)。
圖6:經過IPC進行通訊的獨立進程圖(點擊查看動圖)
那麼如何使用進程和線程構建web瀏覽器呢?好吧,有兩種狀況—多是一個擁有不一樣線程的進程也多是擁有少許線程的經過IPC通訊的多個進程。
圖7:流程/線程圖中的不一樣瀏覽器體系結構
這裏的重點是不一樣的架構是實現的細節性的東西。這裏沒有一個該如何構建瀏覽器的特定的標準。一個瀏覽器用的方式可能和其餘瀏覽器的徹底不一樣。
在咱們的這個系列博客中,咱們會使用以下圖所示的谷歌Chrome最近的架構方式爲例。
在頂部的是瀏覽器進程與負責應用程序的其餘部分的進程的協調配合。對於渲染進程,多個進程被建立來分配給每個標籤頁。直到最近,谷歌才儘量地爲每個標籤頁提供一個進程。如今,谷歌嘗試給每一個站點一個本身的進程,包括iframes(參閱Site Isolation)
圖8:Chrome的多進程架構圖。渲染進程下有多個圖層,表示Chrome爲每一個選項卡運行多個渲染器進程。
下表介紹了每一個Chrome流程及其控制的內容:
圖9:指向瀏覽器UI不一樣部分的不一樣進程
甚至還有更多的進程好比擴展進程和實用進程(utility processes)。若是你想看看有多少進程在你的Chrome裏運行,點擊右上角的menu 圖標,選擇更多工具,而後點擊任務管理器。這會開啓一個進程表窗口上面是當前運行的程序和他們所佔的CPU/內存量。
先前,我提到了Chrome用多個渲染器進程。在最簡單的狀況下,你能夠想象成每一個tab頁有一個本身的渲染器進程。假如你打開了3個選項卡,那麼每一個選項卡都有一個獨立的渲染器進程。若是其中一個選項卡不響應了,你能夠關閉不響應的那個,其餘的選項卡仍是能夠正常使用的。若是全部的選項卡都在同一個進程中,當一個不響應時全部的都不響應了,那就有點悲慘了。
圖10:顯示運行每一個選項卡的多個進程的圖表(點擊圖片看動圖)
把瀏覽器工做分解爲多進程的另外一個好處是安全性和沙盒。由於操做系統提供了一種阻止進程的yi一些特權的方法,瀏覽器能夠在某些功能上沙盒某個進程。例如,瀏覽器能夠爲處理任意用戶輸入的進程好比渲染器進程阻止任意的文件訪問。
因爲進程有本身的私人內存空間,它們一般包含通用基礎架構的副本(好比Chrome的JavaScript引擎V8)。這意味着若是它們是同一進程中的線程它們將沒法以它們的方式共享,這會佔用更多的內存(這句沒怎麼懂
Because processes have their own private memory space, they often contain copies of common infrastructure (like V8 which is a Chrome's JavaScript engine). This means more memory usage as they can't be shared the way they would be if they were threads inside the same process. )。爲了節約內存,Chrome限制了它能夠開啓的進程的數量。這個限制取決於你的設備有多少CPU功率和內存。可是,當Chrome達到限制以後,它開始在同一個進程中運行來自同一個網站的多個標籤頁。
對瀏覽器進程應用相同的方法。Chrome正在經歷架構變革以將瀏覽器中的每一個部分做爲服務來運行以方便輕鬆地分解成多個不一樣的進程或是將多個不一樣的進程合併成一個。
一般的想法是,當Chrome在一個強大的硬件上使用,可能會把每一個服務分解成不一樣的進程以給予更多的穩定性。可是當在一個資源約束的設備上運行時,Chrome將服務合併成一個進程以節省內存佔用。在此次變革以前與合併進程以減小內存佔用相似的方法已經在安卓平臺上有所使用。
圖11:Chrome的服務化圖表將不一樣的服務轉移到多個流程和單個瀏覽器流程中
Site Isolation是Chrome最近推出的一個功能,爲每一個跨站點的iframe運行一個單獨的渲染器進程。咱們已經討論過爲每一個選項卡提供一個渲染器進程的模式,容許跨站點iframe在單個渲染器進程中運行,並在不一樣站點之間共享內存空間。在同一個渲染器進程中運行a.com和b.com看起來是可行的。同源策略是web的核心安全模型。它保證了一個站點在未經許可的狀況下不能從另外一個站點請求數據。繞過此策略是安全攻擊的主要目標。進程隔離是分割站點最有效的方法。隨着Meltdown and Spectre漏洞的揭開,要經過進程來隔離站點更加顯而易見了。自Chrome 67以來在桌面上默認啓用了站點隔離,選項卡中的每一個跨站點iframe都會得到單獨的渲染器進程。
圖12:站點隔離圖;多個渲染器進程指向站點內的iframe
使站點隔離成爲可能花費了多年的時間去研究。站點隔離不像分配不一樣的渲染進程那麼簡單。它從根本上改變了iframes彼此對話的方式。在不一樣進程上運行iframe的頁面上打開devtools意味着devtools必須實現幕後工做才能使其看起來無縫。即便運行簡單的Ctrl + F來查找頁面中的單詞,也意味着在不一樣的渲染器進程中搜索。這就是瀏覽器工程師將Site Isolation的發佈做爲一個重要里程碑的緣由!
本文,咱們已經從一個高層次上講了瀏覽器的架構,也講了多進程架構的好處。咱們還提到了和多進程架構密切相關的服務(Servicification )和站點隔離(Site Isolation)。在下篇推文中,咱們會深刻了解這些進程和線程爲了展現一個網頁作了些什麼。
你喜歡這篇文章嗎?若是你有任何的疑惑和對之後的推文的建議我很期待你能在下面的評論或個人推特(@kosamari)上告訴我。