譯—現代瀏覽器內部原理(第一部分)

ziling_dzl發表於2019-03-27

原文:https://developers.google.com/web/updates/2018/09/inside-browser-part1

(最近在看底層類的文件,有很多是英文文件。因此我覺得反正都要看的,順便翻譯出來,方便以後查閱)

CPU,GPU,記憶體和多程式架構

在這個由4部分組成的系列文章裡,我們將介紹Chrome瀏覽器內部從高階架構到渲染管道的細節。如果你想知道瀏覽器如何將你的程式碼轉換為功能性網站,或者你還很疑惑為什麼建議一些特定方法來提高效能,那麼本系列很適合你。

作為本系列的第1部分,我們將介紹核心計算術語和Chrome的多程式架構。

注意:如果你熟悉CPU / GPU和程式/執行緒的概念,則可以跳到瀏覽器體系結構。

計算器的核心是GPU和CPU。

為了瞭解瀏覽器執行的環境,我們必須得知道一些電腦部件和它們的功能。

CPU

首先是中央處理器—CPU。你可以將CPU看成電腦的大腦。CPU的核心,在這張圖片裡看著就像辦公室裡的工作人員,當他們進來以後可以逐個處理不同的任務。它可以在邊回覆客戶電話的同時處理從數學到藝術等各種事情。在過去,大多數CPU都是單晶片。核心(core)就像住在同一個晶片裡的另一個CPU。在現代硬體裡,你通常會獲得多個核心,給你的手機和膝上型電腦了更強大的計算能力。

CPU

                          圖1:4個CPU核心作為辦公室工作人員坐在每個辦公桌處理任務

GPU

圖形處理器—GPU是電腦的另一個部分。同CPU不同的是,GPU更擅長在跨多個核心的同時處理一些簡單的任務。就像其名字所表明的一樣,它最初是被開發來處理影象的。這就是為什麼當提到“使用GPU”或“以GPU為支援”時,跟著的就是快速的渲染和流暢的互動。近些年來,隨著GPU計算速度的提升,越來越多的計算能利用GPU單獨完成。

GPU

                           圖2:許多帶有扳手的GPU核心表明它們處理的任務有限

當你在你的電腦或手機上啟動一個應用程式時,支援這個程式執行的就是CPU和GPU。通常,應用程式使用作業系統提供的機制在CPU和GPU上執行。

Hardware, OS, Application

圖3:三層計算機體系結構。機器硬體位於底部,作業系統位於中間,應用程式位於頂部。

在程式和執行緒上執行程式

在潛入瀏覽器內部前還要掌握的另一個概念就是程式和執行緒。( Process and Thread)一個程式可以看成是一個應用的執行程式。執行緒是程式裡面的執行程式程式的任何部分的。(執行緒在程式內部,一個程式就是一個程式,程式裡面就是一個個執行緒)。

當你啟動一個應用程式時,一個程式就建立好了。程式可能會建立一個執行緒去幫助它開展工作,但那不是必須的(可選)。作業系統為工作中的程式提供了一個記憶體塊("slab" of memory),所有的應用狀態都儲存在那個私密的記憶體空間裡。當你關閉這個應用時,程式也會隨之而消失,作業系統會釋放這個記憶體。

process and threads

                                 圖4:作為邊界框的程式,執行緒作為在程式內遊動的抽象的魚

process and memory

click on the image to see animation(點選上圖看動效)

                                      圖5:使用記憶體空間和儲存應用程式資料的程式圖

一個程式可以讓作業系統啟動另一個程式來執行不同的任務。當這種情況發生時,記憶體的另一個部分會被分配給這個新的程式。如果兩個程式之間需要對話,他們可以IPC(程式間通訊Inter Process Communication)來實現。很多應用程式被設計成以這種方式工作是為了當其中一個程式不響應時,它可以重啟並且不會影響執行應用程式的其他部分的程式(其他程式不會因此被停止)。

worker process and IPC

                                   圖6:通過IPC進行通訊的獨立程式圖(點選檢視動圖)

瀏覽器架構

那麼如何使用程式和執行緒構建web瀏覽器呢?好吧,有兩種情況—可能是一個擁有不同執行緒的程式也可能是擁有少量執行緒的通過IPC通訊的多個程式。

browser architecture

                                   圖7:流程/執行緒圖中的不同瀏覽器體系結構

這裡的重點是不同的架構是實現的細節性的東西。這裡沒有一個該如何構建瀏覽器的特定的標準。一個瀏覽器用的方式可能和其他瀏覽器的完全不同。

在我們的這個系列部落格中,我們會使用如下圖所示的谷歌Chrome最近的架構方式為例。

在頂部的是瀏覽器程式與負責應用程式的其他部分的程式的協調配合。對於渲染程式,多個程式被建立來分配給每一個標籤頁。直到最近,谷歌才儘可能地為每一個標籤頁提供一個程式。現在,谷歌嘗試給每個站點一個自己的程式,包括iframes(參閱Site Isolation

browser architecture

圖8:Chrome的多程式架構圖。渲染程式下有多個圖層,表示Chrome為每個選項卡執行多個渲染器程式。

每個程式控制什麼?

下表介紹了每個Chrome流程及其控制的內容:

譯—現代瀏覽器內部原理(第一部分)

Chrome processes

                                        圖9:指向瀏覽器UI不同部分的不同程式

甚至還有更多的程式比如擴充套件程式和實用程式(utility processes)。如果你想看看有多少程式在你的Chrome裡執行,點選右上角的menu 圖示,選擇更多工具,然後點選工作管理員。這會開啟一個程式表視窗上面是當前執行的程式和他們所佔的CPU/記憶體量。

Chrome多程式架構的優點

先前,我提到了Chrome用多個渲染器程式。在最簡單的情況下,你可以想象成每個tab頁有一個自己的渲染器程式。假如你開啟了3個選項卡,那麼每個選項卡都有一個獨立的渲染器程式。如果其中一個選項卡不響應了,你可以關閉不響應的那個,其他的選項卡還是可以正常使用的。如果所有的選項卡都在同一個程式中,當一個不響應時所有的都不響應了,那就有點悲慘了。

multiple renderer for tabs

                         圖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中的Servicification 

對瀏覽器程式應用相同的方法。Chrome正在經歷架構變革以將瀏覽器中的每個部分作為服務來執行以方便輕鬆地分解成多個不同的程式或是將多個不同的程式合併成一個。

通常的想法是,當Chrome在一個強大的硬體上使用,可能會把每個服務分解成不同的程式以給予更多的穩定性。但是當在一個資源約束的裝置上執行時,Chrome將服務合併成一個程式以節省記憶體佔用。在這次變革之前與合併程式以減少記憶體佔用類似的方法已經在安卓平臺上有所使用。

Chrome servicfication

                圖11:Chrome的服務化圖表將不同的服務轉移到多個流程和單個瀏覽器流程中

每幀(Per-frame)渲染器程式—站點隔離(Site Isolation)

Site Isolation是Chrome最近推出的一個功能,為每個跨站點的iframe執行一個單獨的渲染器程式。我們已經討論過為每個選項卡提供一個渲染器程式的模式,允許跨站點iframe在單個渲染器程式中執行,並在不同站點之間共享記憶體空間。在同一個渲染器程式中執行a.com和b.com看起來是可行的。同源策略是web的核心安全模型。它保證了一個站點在未經許可的情況下不能從另一個站點請求資料。繞過此策略是安全攻擊的主要目標。程式隔離是分割站點最有效的方法。隨著Meltdown and Spectre漏洞的揭開,要通過程式來隔離站點更加顯而易見了。自Chrome 67以來在桌面上預設啟用了站點隔離,選項卡中的每個跨站點iframe都會獲得單獨的渲染器程式。

site isolation

                             圖12:站點隔離圖;多個渲染器程式指向站點內的iframe


使站點隔離成為可能花費了多年的時間去研究。站點隔離不像分配不同的渲染程式那麼簡單。它從根本上改變了iframes彼此對話的方式。在不同程式上執行iframe的頁面上開啟devtools意味著devtools必須實現幕後工作才能使其看起來無縫。即使執行簡單的Ctrl + F來查詢頁面中的單詞,也意味著在不同的渲染器程式中搜尋。這就是瀏覽器工程師將Site Isolation的釋出作為一個重要里程碑的原因!

總結

本文,我們已經從一個高層次上講了瀏覽器的架構,也講了多程式架構的好處。我們還提到了和多程式架構密切相關的服務(Servicification )和站點隔離(Site Isolation)。在下篇推文中,我們會深入瞭解這些程式和執行緒為了展示一個網頁做了些什麼。

你喜歡這篇文章嗎?如果你有任何的疑惑和對以後的推文的建議我很期待你能在下面的評論或我的推特(@kosamari)上告訴我。

next:導航中發生了什麼



相關文章