chromiun 學習《一》

衆所周知，Chrome是創建在開源的Chromium項目上的。

並且不得不說，學習並分析開源項目的代碼對一個程序員的提升確實蠻大的。這篇博文我會記錄一下學習過程當中我遇到的一些問題，並分享學習中我所參考的幾篇優秀的Chromium代碼分析文章。

 

構建的一點吐槽和官方的方法文檔摘錄

 

不看不知道，編譯好的Chromium可執行文件雖然只有40+M，但打包好的源碼文件包居然高達3G之多（也許是我孤陋寡聞了，可是這個反差確實讓我嚇我一跳）。

Chromium的構建方法就很少說了，推薦官方的安裝方法文檔。

值得一提的是，必定要按照他所提供的辦法嚴格的執行，否則可能會遇到各類編譯錯誤。 編譯過程極可能會長達數小時之久 (在個人筆記本上構建了一整晚才完成 ... )。爲了加速編譯過程，上面的文檔推薦使用多核CPU，64位windows，至少8G內存和60G硬盤空間。還有其餘的幾點：

• 儘可能使用Visual Studio 2010 SP1 版本，否則precompiled headers模式可能會出現不少問題。因爲Chromium中有大量的頭文件，使用此選項大概能加速25%。
• 關閉殺毒軟件，或者把.ilk, .pdb, .cc, .h文件加入白名單。再或者，把Chromium源代碼目錄加入殺毒軟件白名單。
• 在一個沒有虛擬內存交換的硬盤上構建Chromium。或者固態硬盤，若是可能的話。
• 使用ninja構建Chromium。這是Google專門爲Chromium項目開發的構建工具鏈，筆者沒有嘗試，文檔稱使用ninja會讓incremental linking過程快不少。
• 修改Visual Studio選項，減小同時連接的項目數量，以減小Chromium連接時所須要的內存。由於Chromium連接須要大量的內存，若是內存不足，大量的分頁操做會大大下降系統的反應速度。"maximum number of parallel project builds"能夠在Tools/Options/Projects and Solutions/Build and Run頁面找到。這個選項能夠減小Visual Studio啓動的VCBuildHelper.exe實例數目。
• 修改include.gypi文件，減小同時執行的cl.exe的數目。默認狀況下，Visual Studio會開啓/MP選項，動用系統一切資源生成多個編譯進程加速編譯。可是因爲Chromium項目過大，最差狀況下一個cl.exe（連接器）可能會佔用大約1G內存。

 

Visual Studio中調試Chromium淺談

 

分析Chromium源碼，爲了快速的在代碼海洋中找到本身所須要的部分，不可避免的要調試的Chromium項目。好比說，咱們想知道，Chromium是如何從頁面上下載一張圖片，通過渲染，最後顯示在頁面上的呢？這個流程實際上的要比看起來複雜很多：一個頁面內的WebKit分析出DOM樹，發現一個<img>元素裏的圖片須要顯示；WebKit發送一個URL下載的IPC消息給主進程Browser Process，而後WebKit根據返回數據的MIME類型標籤進行解析，發現這個資源是個圖片，再根據編碼方式調用相應的WebCore::ImageDecoder類進行解碼，最後還要進行一系列的渲染，把須要繪製的東西交給RenderWidget，這樣咱們才能看到圖片。這個過程若是單純的去瀏覽代碼找到對應的類和方法調用關係，效率低下不說，還很容易出錯，這時候咱們就須要在Chromium中進行代碼調試和追蹤了。

 

有個關鍵問題，Chromium不一樣於普通的單進程程序，默認狀況下它是多進程模式的。好比，新打開的只有一個首頁的Chrome程序，至少有3個相關進程，分別是Browser進程（管理全部的UI框架，全局消息傳遞，資源下載等等），GPU進程（提供WebGL渲染，繞過沙盒機制調用3D API），和渲染進程Renderer（包括首頁響應用戶操做的content和負責渲染的WebKit實例等等），甚至還可能還有其餘的進程外運行的插件進程，等等。具體的Chrome進程模型還有不一樣進程之間如何用IPC消息進行交互的，請參考本文推薦的閱讀源。若是直接經過visual studio進行調試，只有主進程（Browser）被調試，而負責渲染的renderer進程則像是其餘程序同樣。最直觀的表現就是，使用Chrome瀏覽器時，Windows任務管理器中會出現多個chrome.exe進程實例。

 

調試多進程的Chromium，其實利用visual studio自帶的工具就徹底能夠進行: 調試開始後，只要把已經運行起來的子進程附加到debugger上就能夠了。具體操做是，開始調試，選擇Tools > Attach to Process， 而後按住ctrl選擇多個你想要調試的chrome.exe進程，附加到debugger上。另外，最好用debug構建的Chromium進行調試，否則release的編譯器優化問題會產生一些很詭異的狀況（好比取不到特定變量的值，跳過了一些被優化過的函數什麼的。。。）

附加進程到debugger的界面如圖所示：

附加到debugger後，你能夠在process窗口看到正在調試的進程:

 

另外，剛纔說過，Chromium默認狀況下是多進程模式（Process-per-site-instance，一個網站打開的全部頁面屬於同一進程）。你還能夠提供運行時參數--single-process，強制讓Chromium 只用一個進程運行。這種模式能夠經過傳統的方式進行調試，可是這種模式屬於實驗性質的，可能會有這樣和那樣的bug出現，致使頁面崩潰。

 

Chromium project官網還提供了多個調試辦法，不過直接利用visual studio的附加到進程方式最簡便。 http://dev.chromium.org/developers/how-tos/debugging

 

不過實際開發調試中，開發者並不須要每次都要打開龐大的Chromium項目。 Chromium源碼目錄還包含了2個供測試開發用的項目，分別是content_shell和test_shell，默認狀況下這兩個項目能夠從src\content\content.sln和src\webkit\webkit.sln中打開。test_shell主要展現了chromium webkit API，包含了大部分的webkit渲染引擎核心的chrome移植接口（不包括HTML5，GPU加速，沙箱模型），注意，它是單進程的。對於content_shell，這個程序主要用來展現content shell API，它幾乎包含了全部的瀏覽器的功能，像是一個沒有外殼的瀏覽器。跟test_shell不一樣，content_shell是多進程的，進程模型與chromium相同。若是你願意，徹底能夠在content_shell上加一個外殼變成本身自主開發的瀏覽器。開發者能夠根據本身的須要（好比，單獨測試Webkit部分，或是要研究不一樣瀏覽器部件之間如何進行交互）選擇不一樣的程序調試或開發。

 

下圖是一個content_shell在windows下運行的效果。注意，這個東西處理HTTP請求很慢（content API並不包括完整的資源下載功能，Chrome的全部資源下載都是經過 Browser進程負責的），最好只用來測試本地的頁面。

 

推薦閱讀和引用來源

 

從零開始分析源碼來了解Chromium項目是十分困難的。好在Google爲咱們提供了很多有用的文章，具體能夠從  The Chromium Project->For Developers->How-Tos  搜索。不過這些文章有些晦澀難懂，二來是英語的，閱讀起來會對我等英語渣渣形成困難；這裏推薦如下幾個中文博客：

• Chrome源碼剖析 1~5 by duguguiyu。這位大神在08年Chromium剛公佈源碼後就進行了系統化而且通俗易懂的源碼分析（說實話幫了我大忙~謝謝大神）。文章沒有從代碼上進行詳細說明，而是從更高一層的設計層面分析了Chrome的不一樣組件，這是更難能難得的。具體內容包括了Chromium的多線程任務模型、多進程瀏覽頁模型，Chrome內的IPC消息傳遞機制，Chrome的圖形渲染繪製流程。
• Chrome源碼閱讀 by zero_lee。這位做者主要從代碼層面分析了多個Chrome內部類的做用和實現技巧，對於代碼的理解頗有幫助。
• Chromium研究 by chen.zhengyong。做者把眼光放在了Linux系統和嵌入式設備上的Chrome的開發和實現上。裏面有不少繪製精美的UML圖，值得一看。
• Chrome擴展開發文檔中文版 by 360。360公司翻譯的Chrome擴展開發文檔，若是要寫Chrome擴展（不是插件，擴展和插件在Chrome中是兩種東西）大概會有用。

 

本文轉自http://blog.csdn.net/pengx17/article/details/8259099