Chrome源碼剖析、上

原著(zhù)：duguguiyu。
整理：July。
時(shí)間：二零一一年四月二日。
出處：http://blog.csdn.net/v_JULY_v。
說(shuō)明：此Chrome源碼剖析編輯整理自此博客：http://flyvenus.net/。我對寫(xiě)原創(chuàng )文章的作者向來(lái)是以最大的尊重的。近期想好好研究和學(xué)習下Chrome源碼，正巧看到了此duguguiyu兄臺的源碼剖析，處于學(xué)習的目的，就不客氣的根據他的博客整理了此文。若有諸多冒犯之處，還望海涵。
--------------------------------

圖片失效，請訪(fǎng)問(wèn)CSDN原站點(diǎn)，謝謝。

前言：

1、之所以整理此文，有倆個(gè)目的：一是為了供自己學(xué)習研究之用；二是為了備份，以作日后反復研究。除此之外，無(wú)它。
2、此文的形式其實(shí)是有點(diǎn)倆不像的，既不是個(gè)人首創(chuàng )即原創(chuàng )，又非單純的轉載（有加工），無(wú)奈之下，權且稱(chēng)作翻譯吧。有不妥之處，還望原作者，及讀者見(jiàn)諒。

    文中加入了我自己的一些見(jiàn)解，請自行辨別。順便再說(shuō)一句，duguguiyu寫(xiě)的這個(gè)Chrome源碼剖析，真不錯，勾起了偶對源碼剖析的莫大興趣。

    在具體針對源碼剖析之前，再粗略回答一下網(wǎng)友可能關(guān)心的問(wèn)題：chrome速度維護如此之快？據網(wǎng)上資料顯示：有幾個(gè)主要的關(guān)鍵技術(shù)：DNS預解析、Google自主開(kāi)發(fā)的V8 Javacript引擎、DOM綁定技術(shù)以及多進(jìn)程架構等等。但這不是本文的重點(diǎn)，所以略過(guò)不談。

    ok，激動(dòng)人心的Chrome源碼剖析旅程，即刻開(kāi)始。

Chrome源碼剖析【序】

此序成于08年末，Chrome剛剛推出之際。

    duguguiyu：“有的人一看到Chrome用到多進(jìn)程就說(shuō)垃圾廢物肯定低能。拜托，大家都是搞技術(shù)的，你知道多進(jìn)程的缺點(diǎn)，Google也知道，他們不是政客，除了搞個(gè)噱頭扯個(gè)蛋就一無(wú)所知了，人家也是有臉有皮的，寫(xiě)一坨屎一樣的開(kāi)源代碼放出來(lái)遭世人恥笑難道會(huì )很開(kāi)心？所謂技術(shù)的優(yōu)劣，是不能一概而論的，同樣的技術(shù)在不同場(chǎng)合不同環(huán)境不同代碼實(shí)現下，效果是有所不同的。....”

Chrome對我來(lái)說(shuō)，有吸引力的地方在于（排名分先后…）：
  1、它是如何利用多進(jìn)程（其實(shí)也會(huì )有多線(xiàn)程一起）做并發(fā)的，又是如何解決多進(jìn)程間的一些問(wèn)題的，比如進(jìn)程間通信，進(jìn)程的開(kāi)銷(xiāo)；
  2、做為一個(gè)后來(lái)者，它的擴展能力如何，如何去權衡對原有插件的兼容，提供怎么樣的一個(gè)插件模型；
  3、它的整體框架是怎樣，有沒(méi)有很NB的架構思想；
  4、它如何實(shí)現跨平臺的UI控件系統；
  5、傳說(shuō)中的V8，為啥那么快。
    但Chrome是一個(gè)跨平臺的瀏覽器，其Linux和Mac版本正在開(kāi)發(fā)過(guò)程中，所以我把所有的眼光都放在了windows版本中，所有的代碼剖析都是基于windows版本的。有錯誤請指正。

    關(guān)于Chrome的源碼下載和環(huán)境配置，大家可自行查找資料，強調一點(diǎn)，一定要嚴格按照說(shuō)明來(lái)配置環(huán)境，特別是vs2005的補丁和windows SDK的安裝，否則肯定是編譯不過(guò)的。

    最后，寫(xiě)這部分唯一不是廢話(huà)的內容，請記住以下這幅圖，這是Chrome最精華的一個(gè)縮影：

圖1 Chrome的線(xiàn)程和進(jìn)程模型

Chrome源碼剖析【一】—— 多線(xiàn)程模型

【一】 Chrome的多線(xiàn)程模型
0. Chrome的并發(fā)模型
    如果你仔細看了前面的圖，對Chrome的線(xiàn)程和進(jìn)程框架應該有了個(gè)基本的了解。Chrome有一個(gè)主進(jìn)程，稱(chēng)為Browser進(jìn)程，它是老大，管理Chrome大部分的日常事務(wù)；其次，會(huì )有很多Renderer進(jìn)程，它們圈地而治，各管理一組站點(diǎn)的顯示和通信（Chrome在宣傳中一直宣稱(chēng)一個(gè)tab對應一個(gè)進(jìn)程，其實(shí)是很不確切的…），它們彼此互不搭理，只和老大說(shuō)話(huà)，由老大負責權衡各方利益。它們和老大說(shuō)話(huà)的渠道，稱(chēng)做IPC（Inter-Process Communication），這是Google搭的一套進(jìn)程間通信的機制，基本的實(shí)現后面自會(huì )分解。

Chrome的進(jìn)程模型
Google在宣傳的時(shí)候一直都說(shuō)，Chrome是one tab one process的模式，其實(shí)，這只是為了宣傳起來(lái)方便如是說(shuō)而已，基本等同廣告，實(shí)際療效，還要從代碼中來(lái)看。實(shí)際上，Chrome支持的進(jìn)程模型遠比宣傳豐富，簡(jiǎn)單的說(shuō)，Chrome支持以下幾種進(jìn)程模型：

1.Process-per-site-instance：就是你打開(kāi)一個(gè)網(wǎng)站，然后從這個(gè)網(wǎng)站鏈開(kāi)的一系列網(wǎng)站都屬于一個(gè)進(jìn)程。這是Chrome的默認模式。
2.Process-per-site：同域名范疇的網(wǎng)站放在一個(gè)進(jìn)程，比如www.google.com（由于此文形成于08年，所以無(wú)法訪(fǎng)問(wèn)，你懂的）和www.google.com/bookmarks就屬于一個(gè)域名內（google有自己的判定機制），不論有沒(méi)有互相打開(kāi)的關(guān)系，都算作是一個(gè)進(jìn)程中。用命令行–process-per-site開(kāi)啟。
3.Process-per-tab：這個(gè)簡(jiǎn)單，一個(gè)tab一個(gè)process，不論各個(gè)tab的站點(diǎn)有無(wú)聯(lián)系，就和宣傳的那樣。用–process-per-tab開(kāi)啟。
4.Single Process：這個(gè)很熟悉了吧，即傳統瀏覽器的模式：沒(méi)有多進(jìn)程只有多線(xiàn)程，用–single-process開(kāi)啟。

關(guān)于各種模式的優(yōu)缺點(diǎn)，官方有官方的說(shuō)法，大家自己也會(huì )有自己的評述。不論如何，至少可以說(shuō)明，Google不是由于白癡而采取多進(jìn)程的策略，而是實(shí)驗出來(lái)的效果。

大家可以用Shift+Esc觀(guān)察各模式下進(jìn)程狀況，至少我是觀(guān)察失敗了（每種都和默認的一樣…），原因待跟蹤。

    不論是Browser進(jìn)程還是Renderer進(jìn)程，都不只是光桿司令，它們都有一系列的線(xiàn)程為自己打理各種業(yè)務(wù)。對于Renderer進(jìn)程，它們通常有兩個(gè)線(xiàn)程：一個(gè)是Main thread，它負責與老大進(jìn)行聯(lián)系，有一些幕后黑手的意思；另一個(gè)是Render thread，它們負責頁(yè)面的渲染和交互，一看就知道是這個(gè)幫派的門(mén)臉級人物。
    相比之下，Browser進(jìn)程既然是老大，小弟自然要多一些，除了大腦般的Main thread，和負責與各Renderer幫派通信的IO thread，其實(shí)還包括負責管文件的file thread，負責管數據庫的db thread等等，它們各盡其責，齊心協(xié)力為老大打拼。它們和各Renderer進(jìn)程的之間的關(guān)系不一樣，同一個(gè)進(jìn)程內的線(xiàn)程，往往需要很多的協(xié)同工作，這一坨線(xiàn)程間的并發(fā)管理，是Chrome最出彩的地方之一了。

閑話(huà)并發(fā)
單進(jìn)程單線(xiàn)程的編程是最?lèi)芤獾氖虑�，所看即所得，一維的思考即可。但程序員的世界總是沒(méi)有那么美好，在很多的場(chǎng)合，我們都需要有多線(xiàn)程、多進(jìn)程、多機器攜起手來(lái)一齊上陣共同完成某項任務(wù)，統稱(chēng)：并發(fā)（非官方版定義…）。在我看來(lái)，需要并發(fā)的場(chǎng)合主要是要兩類(lèi)：

1.為了更好的用戶(hù)體驗。有的事情處理起來(lái)太慢，比如數據庫讀寫(xiě)、遠程通信、復雜計算等等，如果在一個(gè)線(xiàn)程一個(gè)進(jìn)程里面來(lái)做，往往會(huì )影響用戶(hù)感受，因此需要另開(kāi)一個(gè)線(xiàn)程或進(jìn)程轉到后臺進(jìn)行處理。它之所以能夠生效，仰仗的是單CPU的分時(shí)機制，或者是多CPU協(xié)同工作。在單CPU的條件下，兩個(gè)任務(wù)分成兩撥完成的總時(shí)間，是大于兩個(gè)任務(wù)輪流完成的，但是由于彼此交錯，給人的感覺(jué)更自然一些。

2.為了加速完成某項工作。大名鼎鼎的Map/Reduce，做的就是這樣的事情，它將一個(gè)大的任務(wù)，拆分成若干個(gè)小的任務(wù)，分配個(gè)若干個(gè)進(jìn)程去完成，各自收工后，再匯集在一起，更快地得到最后的結果。為了達到這個(gè)目的，只有在多CPU的情形下才有可能，在單CPU的場(chǎng)合（單機單CPU…），是無(wú)法實(shí)現的。
在第二種場(chǎng)合下，我們會(huì )自然而然的關(guān)注數據的分離，從而很好的利用上多CPU的能力；而在第一種場(chǎng)合，我們習慣了單CPU的模式，往往不注重數據與行為的對應關(guān)系，導致在多CPU的場(chǎng)景下，性能不升反降。

1. Chrome的線(xiàn)程模型
    仔細回憶一下我們大部分時(shí)候是怎么來(lái)用線(xiàn)程的，在我足夠貧瘠的多線(xiàn)程經(jīng)歷中，往往都是這樣用的：起一個(gè)線(xiàn)程，傳入一個(gè)特定的入口函數，看一下這個(gè)函數是否是有副作用的（Side Effect），如果有，并且還會(huì )涉及到多線(xiàn)程的數據訪(fǎng)問(wèn)，仔細排查，在可疑地點(diǎn)上鎖伺候。

    Chrome的線(xiàn)程模型走的是另一個(gè)路子，即，極力規避鎖的存在。換更精確的描述方式來(lái)說(shuō)，Chrome的線(xiàn)程模型，將鎖限制了極小的范圍內（僅僅在將Task放入消息隊列的時(shí)候才存在…），并且使得上層完全不需要關(guān)心鎖的問(wèn)題（當然，前提是遵循它的編程模型，將函數用Task封裝并發(fā)送到合適的線(xiàn)程去執行…），大大簡(jiǎn)化了開(kāi)發(fā)的邏輯。

    不過(guò)，從實(shí)現來(lái)說(shuō)，Chrome的線(xiàn)程模型并沒(méi)有什么神秘的地方，它用到了消息循環(huán)的手段。每一個(gè)Chrome的線(xiàn)程，入口函數都差不多，都是啟動(dòng)一個(gè)消息循環(huán)（參見(jiàn)MessagePump類(lèi)），等待并執行任務(wù)。
    而其中，唯一的差別在于，根據線(xiàn)程處理事務(wù)類(lèi)別的不同，所起的消息循環(huán)有所不同。比如處理進(jìn)程間通信的線(xiàn)程（注意，在Chrome中，這類(lèi)線(xiàn)程都叫做IO線(xiàn)程）啟用的是MessagePumpForIO類(lèi)，處理UI的線(xiàn)程用的是MessagePumpForUI類(lèi)，一般的線(xiàn)程用到的是MessagePumpDefault類(lèi)（只討論windows）。
    不同的消息循環(huán)類(lèi)，主要差異有兩個(gè)，一是消息循環(huán)中需要處理什么樣的消息和任務(wù)，第二個(gè)是循環(huán)流程（比如是死循環(huán)還是阻塞在某信號量上…）。下圖是一個(gè)完整版的Chrome消息循環(huán)圖，包含處理Windows的消息，處理各種Task（Task是什么，稍后揭曉，敬請期待），處理各個(gè)信號量觀(guān)察者（Watcher），然后阻塞在某個(gè)信號量上等待喚醒。

 

圖2 Chrome的消息循環(huán)

    當然，不是每一個(gè)消息循環(huán)類(lèi)都需要跑那么一大圈的，有些線(xiàn)程，它不會(huì )涉及到那么多的事情和邏輯，白白浪費體力和時(shí)間，實(shí)在是不可饒恕的。因此，在實(shí)際中，不同的MessagePump類(lèi)，實(shí)現是有所不同的，詳見(jiàn)下表：

2. Chrome中的Task
    從上面的表不難看出，不論是哪一種消息循環(huán)，必須處理的，就是Task（暫且遺忘掉系統消息的處理和Watcher，以后，我們會(huì )緬懷它們的…）。刨去其它東西的干擾，只留下Task的話(huà)，我們可以這樣認為：Chrome中的線(xiàn)程從實(shí)現層面來(lái)看沒(méi)有任何區別，它的區別只存在于職責層面，不同職責的線(xiàn)程，會(huì )處理不同的Task。最后，在鋪天蓋地西紅柿來(lái)臨之前，我說(shuō)一下啥是Task。

    簡(jiǎn)單的看，Task就是一個(gè)類(lèi)，一個(gè)包含了void Run()抽象方法的類(lèi)（參見(jiàn)Task類(lèi)…）。一個(gè)真實(shí)的任務(wù)，可以派生Task類(lèi)，并實(shí)現其Run方法。每個(gè)MessagePump類(lèi)中，會(huì )有一個(gè)MessagePump::Delegate的類(lèi)的對象（MessagePump::Delegate的一個(gè)實(shí)現，請參見(jiàn)MessageLoop類(lèi)…），在這個(gè)對象中，會(huì )維護若干個(gè)Task的隊列。當你期望，你的一個(gè)邏輯在某個(gè)線(xiàn)程內執行的時(shí)候，你可以派生一個(gè)Task，把你的邏輯封裝在Run方法中，然后實(shí)例一個(gè)對象，調用期望線(xiàn)程中的PostTask方法，將該Task對象放入到其Task隊列中去，等待執行。我知道很多人已經(jīng)抄起了板磚，因為這種手法實(shí)在是太常見(jiàn)了，就不是一個(gè)簡(jiǎn)單的依賴(lài)倒置，在線(xiàn)程池，Undo\Redo等模塊的實(shí)現中，用的太多了。

    但，我想說(shuō)的是，雖說(shuō)誰(shuí)家過(guò)年都是吃頓餃子，這餃子好不好吃還是得看手藝，不能一概而論。在Chrome中，線(xiàn)程模型是統一且唯一的，這就相當于有了一套標準，它需要滿(mǎn)足在各個(gè)線(xiàn)程上執行的幾十上百種任務(wù)的需求，因此，必須在靈活行和易用性上有良好的表現，這就是設計標準的難度。為了滿(mǎn)足這些需求，Chrome在底層庫上做了足夠的功夫：
  1.它提供了一大套的模板封裝（參見(jiàn)task.h），可以將Task擺脫繼承結構、函數名、函數參數等限制（就是基于模板的偽function實(shí)現，想要更深入了解，建議直接看鼻祖《Modern C++》和它的Loki庫…）；
  2.同時(shí)派生出CancelableTask、ReleaseTask、DeleteTask等子類(lèi)，提供更為良好的默認實(shí)現；
  3.在消息循環(huán)中，按邏輯的不同，將Task又分成即時(shí)處理的Task、延時(shí)處理的Task、Idle時(shí)處理的Task，滿(mǎn)足不同場(chǎng)景的需求；
  4.Task派生自tracked_objects::Tracked，Tracked是為了實(shí)現多線(xiàn)程環(huán)境下的日志記錄、統計等功能，使得Task天生就有良好的可調試性和可統計性；
這一套七葷八素的都搭建完，這才算是一個(gè)完整的Task模型，由此可知，這餃子，做的還是很費功夫的。

3. Chrome的多線(xiàn)程模型
    工欲善其事，必先利其器。Chrome之所以費了老鼻子勁去磨底層框架這把刀，就是為了面對多線(xiàn)程這坨怪獸的時(shí)候殺的更順暢一些。在Chrome的多線(xiàn)程模型下，加鎖這個(gè)事情只發(fā)生在將Task放入某線(xiàn)程的任務(wù)隊列中，其他對任何數據的操作都不需要加鎖。當然，天下沒(méi)有免費的午餐，為了合理傳遞Task，你需要了解每一個(gè)數據對象所管轄的線(xiàn)程，不過(guò)這個(gè)事情，與紛繁的加鎖相比，真是小兒科了不知道多少倍。

 

圖3 Task的執行模型

    如果你熟悉設計模式，你會(huì )發(fā)現這是一個(gè)Command模式，將創(chuàng )建于執行的環(huán)境相分離，在一個(gè)線(xiàn)程中創(chuàng )建行為，在另一個(gè)線(xiàn)程中執行行為。Command模式的優(yōu)點(diǎn)在于，將實(shí)現操作與構造操作解耦，這就避免了鎖的問(wèn)題，使得多線(xiàn)程與單線(xiàn)程編程模型統一起來(lái)，其次，Command還有一個(gè)優(yōu)點(diǎn)，就是有利于命令的組合和擴展，在Chrome中，它有效統一了同步和異步處理的邏輯。

Command模式
Command模式，是一種看上去很酷的模式，傳統的面向對象編程，我們封裝的往往都是數據，在Command模式下，我們希望封裝的是行為。這件事在函數式編程中很正常，封裝一個(gè)函數作為參數，傳來(lái)傳去，稀疏平常的事兒；但在面向對象的編程中，我們需要通過(guò)繼承、模板、函數指針等手法，才能將其實(shí)現。

應用Command模式，我們是期望這個(gè)行為能到一個(gè)不同于它出生的環(huán)境中去執行，簡(jiǎn)而言之，這是一種想生不想養的行為。我們做Undo/Redo的時(shí)候，會(huì )把在任一一個(gè)環(huán)境中創(chuàng )建的Command，放到一個(gè)隊列環(huán)境中去，供統一的調度；在Chrome中，也是如此，我們在一個(gè)線(xiàn)程環(huán)境中創(chuàng )建了Task，卻把它放到別的線(xiàn)程中去執行，這種寄居蟹似的生活方式，在很多場(chǎng)合都是有用武之地的。

    在一般的多線(xiàn)程模型中，我們需要分清楚啥是同步啥是異步，在同步模式下，一切看上去和單線(xiàn)程沒(méi)啥區別，但同時(shí)也喪失了多線(xiàn)程的優(yōu)勢（淪落成為多線(xiàn)程串行…）。而如果采用異步的模式，那寫(xiě)起來(lái)就麻煩多了，你需要注冊回調，小心管理對象的生命周期，程序寫(xiě)出來(lái)是嗷嗷惡心。在Chrome的多線(xiàn)程模型下，同步和異步的編程模型區別就不復存在了，如果是這樣一個(gè)場(chǎng)景：A線(xiàn)程需要B線(xiàn)程做一些事情，然后回到A線(xiàn)程繼續做一些事情；在Chrome下你可以這樣來(lái)做：生成一個(gè)Task，放到B線(xiàn)程的隊列中，在該Task的Run方法最后，會(huì )生成另一個(gè)Task，這個(gè)Task會(huì )放回到A的線(xiàn)程隊列，由A來(lái)執行。如此一來(lái)，同步異步，天下一統，都是Task傳來(lái)傳去，想不會(huì )，都難了。

 

圖4 Chrome的一種異步執行的解決方案

4. Chrome多線(xiàn)程模型的優(yōu)缺點(diǎn)
    一直在說(shuō)Chrome在規避鎖的問(wèn)題，那到底鎖是哪里不好，犯了何等滔天罪責，落得如此人見(jiàn)人嫌恨不得先殺而后快的境地�！洞�碼之美》的第二十四章“美麗的并發(fā)”中，Haskell設計人之一的Simon Peyton Jones總結了一下用鎖的困難之處，如下：

1.鎖少加了，導致兩個(gè)線(xiàn)程同時(shí)修改一個(gè)變量；
2.鎖多加了，輕則妨礙并發(fā)，重則導致死鎖；
3.鎖加錯了，由于鎖和需要鎖的數據之間的聯(lián)系，只存在于程序員的大腦中，這種事情太容易發(fā)生了；
4.加鎖的順序錯了，維護鎖的順序是一件困難而又容易出錯的問(wèn)題；
5.錯誤恢復；
6.忘記喚醒和錯誤的重試；
7.而最根本的缺陷，是鎖和條件變量不支持模塊化的編程。比如一個(gè)轉賬業(yè)務(wù)中，A賬戶(hù)扣了100元錢(qián)，B賬戶(hù)增加了100元，即使這兩個(gè)動(dòng)作單獨用鎖保護維持其正確性，你也不能將兩個(gè)操作簡(jiǎn)單的串在一起完成一個(gè)轉賬操作，你必須讓它們的鎖都暴露出來(lái)，重新設計一番。好好的兩個(gè)函數，愣是不能組在一起用，這就是鎖的最大悲哀；

    通過(guò)這些缺點(diǎn)的描述，也就可以明白Chrome多線(xiàn)程模型的優(yōu)點(diǎn)。它解決了鎖的最根本缺陷，即，支持模塊化的編程，你只需要維護對象和線(xiàn)程之間的職能關(guān)系即可，這個(gè)攤子，比之鎖的那個(gè)爛攤子，要簡(jiǎn)化了太多。對于程序員來(lái)說(shuō)，負擔一瞬間從泰山降成了鴻毛。

    而Chrome多線(xiàn)程模型的一個(gè)主要難點(diǎn)，在于線(xiàn)程與數據關(guān)系的設計上，你需要良好的劃分各個(gè)線(xiàn)程的職責，如果有一個(gè)線(xiàn)程所管轄的數據，幾乎占據了大半部分的Task，那么它就會(huì )從多線(xiàn)程淪為單線(xiàn)程，Task隊列的鎖也將成為一個(gè)大大的瓶頸。

設計者的職責
一個(gè)底層結構設計是否成功，這個(gè)設計者是否稱(chēng)職，我一直覺(jué)得是有一個(gè)很簡(jiǎn)單的衡量標準的。你不需要看這個(gè)設計人用了多少NB的技術(shù)，你只需要關(guān)心，他的設計，是否給其他開(kāi)發(fā)人員帶來(lái)了困難。一個(gè)NB的設計，是將所有困難都集中在底層搞定，把其他開(kāi)發(fā)人員換成白癡都可以工作的那種；一個(gè)SB的設計，是自己弄了半天，只是為了給其他開(kāi)發(fā)人員一個(gè)長(cháng)達250條的注意事項，然后很NB的說(shuō)，你們按照這個(gè)手冊去開(kāi)發(fā)，就不會(huì )有問(wèn)題了。

    從根本上來(lái)說(shuō)，Chrome的線(xiàn)程模型解決的是并發(fā)中的用戶(hù)體驗問(wèn)題而不是聯(lián)合工作的問(wèn)題（參見(jiàn)我前面噴的“閑話(huà)并發(fā)”），它不是和Map/Reduce那樣將關(guān)注點(diǎn)放在數據和執行步驟的拆分上，而是放在線(xiàn)程和數據的對應關(guān)系上，這是和瀏覽器的工作環(huán)境相匹配的。設計總是和所處的環(huán)境相互依賴(lài)的，畢竟，在客戶(hù)端，不會(huì )和服務(wù)器一樣，存在超規模的并發(fā)處理任務(wù)，而只是需要盡可能的改善用戶(hù)體驗，從這個(gè)角度來(lái)說(shuō)，Chrome的多線(xiàn)程模型，至少看上去很美。

 

Chrome源碼剖析【二】—— 進(jìn)程通信

【二】Chrome的進(jìn)程間通信
1. Chrome進(jìn)程通信的基本模式
    進(jìn)程間通信，叫做IPC（Inter-Process Communication），在Chrome不多的文檔中，有一篇就是介紹這個(gè)的，在這里。Chrome最主要有三類(lèi)進(jìn)程，一類(lèi)是Browser主進(jìn)程，我們一直尊稱(chēng)它老人家為老大；還有一類(lèi)是各個(gè)Render進(jìn)程，前面也提過(guò)了；另外還有一類(lèi)一直沒(méi)說(shuō)過(guò)，是Plugin進(jìn)程，每一個(gè)插件，在Chrome中都是以進(jìn)程的形式呈現，等到后面說(shuō)插件的時(shí)候再提罷了。Render進(jìn)程和Plugin進(jìn)程都與老大保持進(jìn)程間的通信，Render進(jìn)程與Plugin進(jìn)程之間也有彼此聯(lián)系的通路，唯獨是多個(gè)Render進(jìn)程或多個(gè)Plugin進(jìn)程直接，沒(méi)有互相聯(lián)系的途徑，全靠老大協(xié)調。

    進(jìn)程與進(jìn)程間通信，需要仰仗操作系統的特性，能玩的花著(zhù)實(shí)不多，在Chrome中，用到的就是有名的管道（Named Pipe），只不過(guò)，它用一個(gè)IPC::Channel類(lèi)，封裝了具體的實(shí)現細節。Channel可以有兩種工作模式，一種是Client，一種是Server，Server和Client分屬兩個(gè)進(jìn)程，維系一個(gè)共同的管道名，Server負責創(chuàng )建該管道，Client會(huì )嘗試連接該管道，然后雙發(fā)往各自管道緩沖區中讀寫(xiě)數據（在Chrome中，用的是二進(jìn)制流，異步IO…），完成通信。

管道名字的協(xié)商
在Socket中，我們會(huì )事先約定好通信的端口，如果不按照這個(gè)端口進(jìn)行訪(fǎng)問(wèn)，走錯了門(mén)，會(huì )被直接亂棍打出門(mén)去的。與之類(lèi)似，有名管道期望在兩個(gè)進(jìn)程間游走，就需要拿一個(gè)兩個(gè)進(jìn)程都能接受的進(jìn)門(mén)暗號，這個(gè)就是有名管道的名字。在Chrome中（windows下…），有名管道的名字格式都是：\\.\pipe\chrome.ID。其中的ID，自然是要求獨一無(wú)二，比如：進(jìn)程ID.實(shí)例地址.隨機數。通常，這個(gè)ID是由一個(gè)Process生成（往往是Browser Process），然后在創(chuàng )建另一個(gè)進(jìn)程的時(shí)候，作為命令行參數傳進(jìn)去，從而完成名字的協(xié)商。

如果不了解并期待了解有關(guān)Windows下有名管道和信號量的知識，建議去看一些專(zhuān)業(yè)的書(shū)籍，比如圣經(jīng)級別的《Windows核心編程》和《深入解析Windows操作系統》，當然也可以去查看SDK，你需要了解的API可能包括：CreateNamedPipe, CreateFile, ConnectNamedPipe, WaitForMultipleObjects, WaitForSingleObject, SetEvent, 等等。

    Channel中，有三個(gè)比較關(guān)鍵的角色，一個(gè)是Message::Sender，一個(gè)是Channel::Listener，最后一個(gè)是MessageLoopForIO::Watcher。Channel本身派生自Sender和Watcher，身兼兩角，而Listener是一個(gè)抽象類(lèi)，具體由Channel的使用者來(lái)實(shí)現。顧名思義，Sender就是發(fā)送消息的接口，Listener就是處理接收到消息的具體實(shí)現，但這個(gè)Watcher是啥？如果你覺(jué)得Watcher這東西看上去很眼熟的話(huà)，我會(huì )激動(dòng)的熱淚盈眶的，沒(méi)錯，在前面（第一部分第一小節…）說(shuō)消息循環(huán)的時(shí)候，從那個(gè)表中可以看到，IO線(xiàn)程（記住，在Chrome中，IO指的是網(wǎng)絡(luò )IO，*_*）的循環(huán)會(huì )處理注冊了的Watcher。其實(shí)Watcher很簡(jiǎn)單，可以視為一個(gè)信號量和一個(gè)帶有OnObjectSignaled方法對象的對，當消息循環(huán)檢測到信號量開(kāi)啟，它就會(huì )調用相應的OnObjectSignaled方法。

 

圖5 Chrome的IPC處理流程圖

    一圖解千語(yǔ)，如上圖所示，整個(gè)Chrome最核心的IPC流程都在圖上了，期間，刨去了一些錯誤處理等邏輯，如果想看原汁原味的，可以自查Channel類(lèi)的實(shí)現。當有消息被Send到一個(gè)發(fā)送進(jìn)程的Channel的時(shí)候，Channel會(huì )把它放在發(fā)送消息隊列中，如果此時(shí)還正在發(fā)送以前的消息（發(fā)送端被阻塞…），則看一下阻塞是否解除（用一個(gè)等待0秒的信號量等待函數…），然后將消息隊列中的內容序列化并寫(xiě)道管道中去。操作系統會(huì )維護異步模式下管道的這一組信號量，當消息從發(fā)送進(jìn)程緩沖區寫(xiě)到接收進(jìn)程的緩沖區后，會(huì )激活接收端的信號量。當接收進(jìn)程的消息循環(huán)，循到了檢查Watcher這一步，并發(fā)現有信號量激活了，就會(huì )調用該Watcher相應的OnObjectSignaled方法，通知接受進(jìn)程的Channel，有消息來(lái)了！Channel會(huì )嘗試從管道中收字節，組消息，并調用Listener來(lái)解析該消息。

    從上面的描述不難看出，Chrome的進(jìn)程通信，最核心的特點(diǎn)，就是利用消息循環(huán)來(lái)檢查信號量，而不是直接讓管道阻塞在某信號量上。這樣就與其多線(xiàn)程模型緊密聯(lián)系在了一起，用一種統一的模式來(lái)解決問(wèn)題。并且，由于是消息循環(huán)統一檢查，線(xiàn)程不會(huì )隨便就被阻塞了，可以更好的處理各種其他工作，從理論上講，這是通過(guò)增加CPU工作時(shí)間，來(lái)?yè)Q取更好的體驗，頗有資本家的派頭。

溫柔的消息循環(huán)
其實(shí)，Chrome的很多消息循環(huán)，也不是都那么霸道，也是會(huì )被阻塞在某些信號量或者某種場(chǎng)景上的，畢竟客戶(hù)端不是它家的服務(wù)器，CPU不能被全部歸在它家名下。

比如IO線(xiàn)程，當沒(méi)有消息來(lái)到，又沒(méi)有信號量被激活的時(shí)候，就會(huì )被阻塞，具體實(shí)現可以去看MessagePumpForIO的WaitForWork方法。

不過(guò)這種阻塞是集中式的，可隨時(shí)修改策略的，比起Channel直接阻塞在信號量上，停工的時(shí)間更短。

2. 進(jìn)程間的跨線(xiàn)程通信和同步通信
    在Chrome中，任何底層的數據都是線(xiàn)程非安全的，Channel不是太上老君（抑或中國足球？…），它也沒(méi)有例外。在每一個(gè)進(jìn)程中，只能有一個(gè)線(xiàn)程來(lái)負責操作Channel，這個(gè)線(xiàn)程叫做IO線(xiàn)程（名不符實(shí)真是一件悲涼的事情…）。其它線(xiàn)程要是企圖越俎代庖，是會(huì )出大亂子的。

    但是有時(shí)候（其實(shí)是大部分時(shí)候…），我們需要從非IO線(xiàn)程與別的進(jìn)程相通信，這該如何是好？如果，你有看過(guò)我前面寫(xiě)的線(xiàn)程模型，你一定可以想到，做法很簡(jiǎn)單，先將對Channel的操作放到Task中，將此Task放到IO線(xiàn)程隊列里，讓IO線(xiàn)程來(lái)處理即可。當然，由于這種事情發(fā)生的太頻繁，每次都人肉做一次頗為繁瑣，于是有一個(gè)代理類(lèi)，叫做ChannelProxy，來(lái)幫助你完成這一切。

    從接口上看，ChannelProxy的接口和Channel沒(méi)有大的區別（否則就不叫Proxy了…），你可以像用Channel一樣，用ChannelProxy來(lái)Send你的消息，ChannelProxy會(huì )辛勤的幫你完成剩余的封裝Task等工作。不僅如此，ChannelProxy還青出于藍勝于藍，在這個(gè)層面上做了更多的事情，比如：發(fā)送同步消息。

    不過(guò)能發(fā)送同步消息的類(lèi)不是ChannelProxy，而是它的子類(lèi)，SyncChannel。在Channel那里，所有的消息都是異步的（在Windows中，也叫Overlapped…），其本身也不支持同步邏輯。為了實(shí)現同步，SyncChannel并沒(méi)有另造輪子，而只是在Channel的層面上加了一個(gè)等待操作。當ChannelProxy的Send操作返回后，SyncChannel會(huì )把自己阻塞在一組信號量上，等待回包，直到永遠或超時(shí)。從外表上看同步和異步?jīng)]有什么區別，但在使用上還是要小心，在UI線(xiàn)程中使用同步消息，是容易被發(fā)指的。

3. Chrome中的IPC消息格式
    說(shuō)了半天，還有一個(gè)大頭沒(méi)有提過(guò)，那就是消息包。如果說(shuō)，多線(xiàn)程模式下，對數據的訪(fǎng)問(wèn)開(kāi)銷(xiāo)來(lái)自于鎖，那么在多進(jìn)程模式下，大部分的額外開(kāi)銷(xiāo)都來(lái)自于進(jìn)程間的消息拆裝和傳遞。不論怎么樣的模式，只要進(jìn)程不同，消息的打包，序列化，反序列化，組包，都是不可避免的工作。

    在Chrome中，IPC之間的通信消息，都是派生自IPC::Message類(lèi)的。對于消息而言，序列化和反序列化是必須要支持的，Message的基類(lèi)Pickle，就是干這個(gè)活的。Pickle提供了一組的接口，可以接受int，char，等等各種數據的輸入，但是在Pickle內部，所有的一切都沒(méi)有區別，都轉化成了一坨二進(jìn)制流。這個(gè)二進(jìn)制流是32位齊位的，比如你只傳了一個(gè)bool，也是最少占32位的，同時(shí)，Pickle的流是有自增邏輯的（就是說(shuō)它會(huì )先開(kāi)一個(gè)Buffer，如果滿(mǎn)了的話(huà)，會(huì )加倍這個(gè)Buffer…），使其可以無(wú)限擴展。Pickle本身不維護任何二進(jìn)制流邏輯上的信息，這個(gè)任務(wù)交到了上級處理（后面會(huì )有說(shuō)到…），但Pickle會(huì )為二進(jìn)制流添加一個(gè)頭信息，這個(gè)里面會(huì )存放流的長(cháng)度，Message在繼承Pickle的時(shí)候，擴展了這個(gè)頭的定義，完整的消息格式如下：

                                          圖6 Chrome的IPC消息格式

    其中，黃色部分是包頭，定長(cháng)96個(gè)bit，綠色部分是包體，二進(jìn)制流，由payload_size指明長(cháng)度。從大小上看這個(gè)包是很精簡(jiǎn)的了，除了routing位在消息不為路由消息的時(shí)候會(huì )有所浪費。消息本身在有名管道中是按照二進(jìn)制流進(jìn)行傳輸的（有名管道可以傳輸兩種類(lèi)型的字符流，分別是二進(jìn)制流和消息流…），因此由payload_size + 96bits，就可以確定是否收了一個(gè)完整的包。

    從邏輯上來(lái)看，IPC消息分成兩類(lèi)，一類(lèi)是路由消息（routed message），還有一類(lèi)是控制消息（control message）。路由消息是私密的有目的地的，系統會(huì )依照路由信息將消息安全的傳遞到目的地，不容它人窺視；控制消息就是一個(gè)廣播消息，誰(shuí)想聽(tīng)等能夠聽(tīng)得到。

消息的序列化
前不久讀了Google Protocol Buffers的源碼，是用在服務(wù)器端，用做內部機器通信協(xié)議的標準、代碼生成工具和框架。它主要的思想是揉合了key/value的內容到二進(jìn)制中，幫助生成更為靈活可靠的二進(jìn)制協(xié)議。

在Chrome中，沒(méi)有使用這套東西，而是用到了純二進(jìn)制流作為消息序列化的方式。我想這是由于應用場(chǎng)景不同使然。在服務(wù)端，我們更關(guān)心協(xié)議的穩定性，可擴展性，并且，涉及到的協(xié)議種類(lèi)很多。但在一個(gè)Chrome中，消息的格式很統一，這方面沒(méi)有擴展性和靈活性的需求，而在序列化上，雖然key/value的方式很好很強大，但是在Chrome中需要的不是靈活性而是精簡(jiǎn)性，因此寧可不用Protocol Buffers造好的輪子，而是另立爐灶，花了好一把力氣提供了一套純二進(jìn)制的消息機制。
 

4. 定義IPC消息
    如果你寫(xiě)過(guò)MFC程序，對MFC那里面一大堆宏有所忌憚的話(huà)，那么很不幸，在Chrome中的IPC消息定義中，你需要再吃一點(diǎn)苦頭了，甚至，更苦大仇深一些；如果你曾經(jīng)領(lǐng)教過(guò)用模板的特化偏特化做Traits、用模板做函數重載、用編譯期的Tuple做變參數支持，之類(lèi)機制的種種麻煩的話(huà)，那么，同樣很遺憾，在Chrome中，你需要再感受一次。。。

    不過(guò)，先讓我們忘記宏和模板，看人肉一個(gè)消息，到底需要哪些操作。一個(gè)標準的IPC消息定義應該是類(lèi)似于這樣的：

class SomeMessage: public IPC::Message
{
  public:
    enum { ID = …; }
    SomeMessage(SomeType & data)
    : IPC::Message(MSG_ROUTING_CONTROL, ID, ToString(data))
    {…}
    …
};

    大概意思是這樣的，你需要從Message（或者其他子類(lèi)）派生出一個(gè)子類(lèi)，該子類(lèi)有一個(gè)獨一無(wú)二的ID值，該子類(lèi)接受一個(gè)參數，你需要對這個(gè)參數進(jìn)行序列化。兩個(gè)麻煩的地方看的很清楚，如果生成獨一無(wú)二的ID值？如何更方便的對任何參數可以自動(dòng)的序列化？。

    在Chrome中，解決這兩個(gè)問(wèn)題的答案，就是宏 + 模板。Chrome為每個(gè)消息安排了一種ID規格，用一個(gè)16bits的值來(lái)表示，高4位標識一個(gè)Channel，低12位標識一個(gè)消息的子id，也就是說(shuō)，最多可以有16種Channel存在不同的進(jìn)程之間，每一種Channel上可以定義4k的消息。目前，Chrome已經(jīng)用掉了8種Channel（如果A、B進(jìn)程需要雙向通信，在Chrome中，這是兩種不同的Channel，需要定義不同的消息，也就是說(shuō)，一種雙向的進(jìn)程通信關(guān)系，需要耗費兩個(gè)Channel種類(lèi)…），他們已經(jīng)覺(jué)得，16bits的ID格式不夠用了，在將來(lái)的某一天，估計就被擴展成了32bits的。書(shū)歸正傳，Chrome是這么來(lái)定義消息ID的，用一個(gè)枚舉類(lèi)，讓它從高到低往下走，就像這樣：

enum SomeChannel_MsgType
{
  SomeChannelStart = 5 << 12,
  SomeChannelPreStart = (5 << 12) – 1,
  Msg1,
  Msg2,
  Msg3,
  …
  MsgN,
  SomeChannelEnd
};

    這是一個(gè)類(lèi)型為5的Channel的消息ID聲明，由于指明了最開(kāi)始的兩個(gè)值，所以后續枚舉的值會(huì )依次遞減，如此，只要維護Channel類(lèi)型的唯一性，就可以維護所有消息ID的唯一性了（當然，前提是不能超過(guò)消息上限…）。但是，定義一個(gè)ID還不夠，你還需要定義一個(gè)使用該消息ID的Message子類(lèi)。這個(gè)步驟不但繁瑣，最重要的，是違反了DIY原則，為了添加一個(gè)消息，你需要在兩個(gè)地方開(kāi)工干活，是可忍孰不可忍，于是Google祭出了宏這顆原子彈，需要定義消息，格式如下：

IPC_BEGIN_MESSAGES(PluginProcess, 3)
IPC_MESSAGE_CONTROL2(PluginProcessMsg_CreateChannel,
int /* process_id */,
HANDLE /* renderer handle */)
IPC_MESSAGE_CONTROL1(PluginProcessMsg_ShutdownResponse,
bool /* ok to shutdown */)
IPC_MESSAGE_CONTROL1(PluginProcessMsg_PluginMessage,
std::vector<uint8> /* opaque data */)
IPC_MESSAGE_CONTROL0(PluginProcessMsg_BrowserShutdown)
IPC_END_MESSAGES(PluginProcess)

    這是Chrome中，定義PluginProcess消息的宏，我挖過(guò)來(lái)放在這了，如果你想添加一條消息，只需要添加一條類(lèi)似與IPC_MESSAGE_CONTROL0東東即可，這說(shuō)明它是一個(gè)控制消息，參數為0個(gè)。你基本上可以這樣理解，IPC_BEGIN_MESSAGES就相當于完成了一個(gè)枚舉開(kāi)始的聲明，然后中間的每一條，都會(huì )在枚舉里面增加一個(gè)ID，并聲明一個(gè)子類(lèi)。這個(gè)一宏兩吃，直逼北京烤鴨兩吃的高超做法，可以參看ipc_message_macros.h，或者看下面一宏兩吃的一個(gè)舉例。

多次展開(kāi)宏的技巧
這是Chrome中用到的一個(gè)技巧，定義一次宏，展開(kāi)多段代碼，我孤陋寡聞，第一次見(jiàn)，一個(gè)類(lèi)似的例子，如下：

首先，定義一個(gè)macro.h，里面放置宏的定義：
#undef SUPER_MACRO
#if defined(FIRST_TIME)
#undef FIRST_TIME
#define SUPER_MACRO(label, type) \

enum IDs { \
  label##__ID = 10 \
};

#elif defined(SECOND_TIME)
#undef SECOND_TIME

#define SUPER_MACRO(label, type) \
class TestClass \
{ \
  public: \
    enum {ID = label##__ID}; \
    TestClass(type value) : _value(value) {} \
    type _value; \
};
#endif

可以看到，這個(gè)頭文件是可重入的，每一次先undef掉之前的定義，然后判斷進(jìn)行新的定義。然后，你可以創(chuàng )建一個(gè)use_macro.h文件，利用這個(gè)宏，定義具體內容：

#include “macros.h”
SUPER_MACRO(Test, int)

這個(gè)頭文件在利用宏的部分不需要放到ifundef…define…這樣的頭文件保護中，目的就是為了可重入。在主函數中，你可以多次define + include，實(shí)現多次展開(kāi)的目的：

#define FIRST_TIME
#include “use_macro.h”
#define SECOND_TIME
#include “use_macro.h”
#include <iostream>
int _tmain(int argc, _TCHAR* argv[])
{
  TestClass t(5);
  std::cout << TestClass::ID << std::endl;
  std::cout << t._value << std::endl;
  return 0;
}

這樣，你就成功的實(shí)現，一次定義，生成多段代碼了。

此外，當接收到消息后，你還需要處理消息。接收消息的函數，是IPC::Channel::Listener子類(lèi)的OnMessageReceived函數。在這個(gè)函數中，會(huì )放置一坨的宏，這一套宏，一定能讓你想起MFC的Message Map機制（關(guān)于此消息機制原理更具體的介紹，可參考侯捷的深入淺出MFC一書(shū)。）：

IPC_BEGIN_MESSAGE_MAP_EX(RenderProcessHost, msg, msg_is_ok)

IPC_MESSAGE_HANDLER(ViewHostMsg_PageContents, OnPageContents)
IPC_MESSAGE_HANDLER(ViewHostMsg_UpdatedCacheStats,
OnUpdatedCacheStats)
IPC_MESSAGE_UNHANDLED_ERROR()
IPC_END_MESSAGE_MAP_EX()

 

    這個(gè)東西很簡(jiǎn)單，展開(kāi)后基本可以視為一個(gè)Switch循環(huán)，判斷消息ID，然后將消息，傳遞給對應的函數。與MFC的Message Map比起來(lái)，做的事情少多了。

    通過(guò)宏的手段，可以解決消息類(lèi)聲明和消息的分發(fā)問(wèn)題，但是自動(dòng)的序列化還不能支持（所謂自動(dòng)的序列化，就是不論你是什么類(lèi)型的參數，幾個(gè)參數，都可以直接序列化，不需要另寫(xiě)代碼…）。在C++這種語(yǔ)言中，所謂自動(dòng)的序列化，自動(dòng)的類(lèi)型識別，自動(dòng)的XXX，往往都是通過(guò)模板來(lái)實(shí)現的。這些所謂的自動(dòng)化，其實(shí)就是通過(guò)事前的大量人肉勞作，和模板自動(dòng)遞推來(lái)實(shí)現的，如果說(shuō).Net或Java中的自動(dòng)序列化是過(guò)山軌道，這就是那挑夫的驕子，雖然最后都是兩腿不動(dòng)到了山頂，這底下費得力氣真是天壤之別啊。具體實(shí)現技巧，有興趣的看看侯捷的《STL源碼剖析》，或者是《C++新思維》，或者Chrome中的ipc_message_utils.h，這要說(shuō)清楚實(shí)在不是一兩句的事情。

    總之通過(guò)宏和模板，你可以很簡(jiǎn)單的聲明一個(gè)消息，這個(gè)消息可以傳入各式各樣的參數（這里用到了夸張的修辭手法，其實(shí)，只要是模板實(shí)現的自動(dòng)化，永遠都是有限制的，在Chrome的模板實(shí)現中，參數數量不要超過(guò)5個(gè)，類(lèi)型需要是基本類(lèi)型、STL容器等，在不BT的場(chǎng)合，應該夠用了…），你可以調用Channel、ChannelProxy、SyncChannel之類(lèi)的Send方法，將消息發(fā)送給其他進(jìn)程，并且，實(shí)現一個(gè)Listener類(lèi)，用Message Map來(lái)分發(fā)消息給對應的處理函數。如此，整個(gè)IPC體系搭建完成。

苦力的宏和模板
不論是宏還是模板，為了實(shí)現這套機制，都需要寫(xiě)大量的類(lèi)似代碼，比如為了支持0~N個(gè)參數的Control消息，你就需要寫(xiě)N+1個(gè)類(lèi)似的宏；為了支持各種基礎數據結構的序列化，你就需要寫(xiě)上十來(lái)個(gè)類(lèi)似的Write函數和Traits。

之所以做如此苦力的活，都是為了用這些東西的人能夠盡可能的簡(jiǎn)單方便，符合DIY原則。規約到之前說(shuō)的設計者的職責上來(lái)，這是一個(gè)典型的苦了我一個(gè)幸福千萬(wàn)人的負責任的行為。在Chrome中，如此的代碼隨處可見(jiàn)，光Tuple那一套拳法，我現在就看到了使了不下三次（我曾經(jīng)做過(guò)一套，直接吐血…），如此兢兢業(yè)業(yè)，真是可歌可泣啊。
 

【三】 Chrome的進(jìn)程模型
1. 基本的進(jìn)程結構
    Chrome是一個(gè)多進(jìn)程的架構，不過(guò)所有的進(jìn)程都會(huì )由老大，Browser進(jìn)程來(lái)管理，走的是集中化管理的路子。在Browser進(jìn)程中，有xxxProcessHost，每一個(gè)host，都對應著(zhù)一個(gè)Process，比如RenderProcessHost對應著(zhù)RenderProcess，PluginProcessHost對應著(zhù)PluginProcess，有多少個(gè)host的實(shí)例，就有多少個(gè)進(jìn)程在運行。

    這是一個(gè)比較典型的代理模式，Browser對Host的操作，都會(huì )被Host封裝成IPC消息，傳遞給對應的Process來(lái)處理，對于大部分上層的類(lèi)，也就隔離了多進(jìn)程細節。

2. Render進(jìn)程
    先不扯Plugin的進(jìn)程，只考慮Render進(jìn)程。前面說(shuō)了，一個(gè)Process一個(gè)tab，只是廣告用語(yǔ)，實(shí)際上，每一個(gè)web頁(yè)面內容（包括在tab中的和在彈出窗口中的…），在Chrome中，用RenderView表示一個(gè)web頁(yè)面，每一個(gè)RenderView可以寄宿在任一一個(gè)RenderProcess中，它只是依托RenderProcess幫助它進(jìn)行通信。每一個(gè)RenderProcess進(jìn)程都可以有1到N個(gè)RenderView實(shí)例。

    Chrome支持不同的進(jìn)程模型，可以一個(gè)tab一個(gè)進(jìn)程，一個(gè)site instance一個(gè)進(jìn)程等等。但基本模式都是一致的，當需要創(chuàng )建一個(gè)新的RenderView的時(shí)候，Chrome會(huì )嘗試進(jìn)行選擇或者是創(chuàng )建進(jìn)程。比如，在one site one process的模式下，如果存在此site，就會(huì )選擇一個(gè)已有的RenderProcessHost，讓它管理這個(gè)新的RenderView，否則，會(huì )創(chuàng )建一個(gè)RenderProcessHost（同時(shí)也就創(chuàng )建了一個(gè)Process），把RenderView交給它。

    在默認的one site instance one process的模式中，Chrome會(huì )為每個(gè)新的site instance創(chuàng )建一個(gè)進(jìn)程（從一個(gè)頁(yè)面鏈開(kāi)來(lái)的頁(yè)面，屬于同一個(gè)site instance），但，Render進(jìn)程總數是有個(gè)上限的。這個(gè)上限，根據內存大小的不同而異，比如，在我的機器上（2G內存），最多可以容納20個(gè)Render進(jìn)程，當達到這個(gè)上限后，你再開(kāi)新的網(wǎng)站，Chrome會(huì )隨機為你選擇一個(gè)已有的進(jìn)程，把這個(gè)網(wǎng)站對應的RenderView給扔進(jìn)去。。。

    每一次你新輸入一個(gè)站點(diǎn)信息，在默認模式下，都必然導致一個(gè)進(jìn)程的誕生，很可能，伴隨著(zhù)另一個(gè)進(jìn)程的死亡（如果這個(gè)進(jìn)程沒(méi)有其他承載的RenderView的話(huà)，他就自然死亡了，RenderView的個(gè)數，就相當于這個(gè)進(jìn)程的引用計數…）。比如，你打開(kāi)一個(gè)新標簽頁(yè)的時(shí)候，系統為你創(chuàng )造了一個(gè)進(jìn)程來(lái)承載這個(gè)新標簽頁(yè)，你輸入http://www.baidu.com/，于是新標簽頁(yè)進(jìn)程死亡，承載http://www.baidu.com/的進(jìn)程誕生。你用baidu搜索了一下，毫無(wú)疑問(wèn)，你基本對它的搜索結果很失望，于是你重新輸入http://www.google.com.hk/，老的承載baidu的進(jìn)程死亡，承載google的進(jìn)程被構建出來(lái)。這時(shí)候你想回退到之前baidu的搜索結果，樂(lè )呵樂(lè )呵的話(huà)，一個(gè)新的承載baidu的進(jìn)程被創(chuàng )造，之前Google的進(jìn)程死亡。同樣，你再次點(diǎn)擊前進(jìn)，又來(lái)到Google搜索結果的時(shí)候，一個(gè)新的進(jìn)程有取代老的進(jìn)程出現了。

    以上現象，你都可以自己來(lái)檢驗，通過(guò)觀(guān)察about:memory頁(yè)面的信息，你可以了解整個(gè)過(guò)程（記得每做一步，需要刷新一下about:memory頁(yè)面）。我唧唧歪歪說(shuō)了半天，其實(shí)想表達的是，Chrome并沒(méi)有像我YY的一樣做啥進(jìn)程池之類(lèi)的特殊機制，而是簡(jiǎn)單的履行有就創(chuàng )建、沒(méi)有就銷(xiāo)毀的策略。我并不知道有沒(méi)有啥很有效的多進(jìn)程模型，這方面一點(diǎn)都沒(méi)玩過(guò)，猜測Chrome之所以采取這樣的策略，是經(jīng)過(guò)琢磨的，覺(jué)得進(jìn)程生死的代價(jià)可以承受，比較可行。

3. 進(jìn)程開(kāi)銷(xiāo)控制算法
    說(shuō)開(kāi)銷(xiāo)無(wú)外乎兩方面的內容，一為時(shí)間，二則空間。Chrome沒(méi)有在進(jìn)程創(chuàng )建和銷(xiāo)毀上做功夫，但是當進(jìn)程運行起來(lái)后，還是做了一些工作的。

    節約工作首先從CPU耗時(shí)上做起，優(yōu)先級越高的進(jìn)程中的線(xiàn)程，越容易被調度，從而耗費CPU時(shí)間，于是，當一個(gè)頁(yè)面不再直接面對用戶(hù)的時(shí)候，Chrome會(huì )將它的進(jìn)程優(yōu)先級切到Below Normal的級別，反之，則切回Normal級別。通過(guò)這個(gè)步驟，小節約了一把時(shí)間。

進(jìn)程的優(yōu)先級
在windows中，進(jìn)程是有優(yōu)先級的，當然，這個(gè)優(yōu)先級不是真實(shí)的調度優(yōu)先級，而是該進(jìn)程中，線(xiàn)程優(yōu)先級計算的基準。在《Windows via C/C++》（也就是《windows核心編程》的第五版）中，有一張詳細的表，表述了線(xiàn)程優(yōu)先級和進(jìn)程優(yōu)先級的具體對應關(guān)系，感覺(jué)設計的很不錯，在此就不再贅述了，有興趣的自行動(dòng)手翻書(shū)。

    當然這只是一道開(kāi)胃小菜，滿(mǎn)漢全席是控制進(jìn)程的工作集大小，以達到降低進(jìn)程實(shí)際內存消耗的目的（Chrome為了體現它對內存的節約，用了“更為精確”的內存消耗計算方法…）。提到這一點(diǎn)，Chrome頗為自豪，在文檔中，順著(zhù)道把單進(jìn)程的模式鄙視了一下，基本意思是：在多進(jìn)程的模式下，各個(gè)頁(yè)面實(shí)際占用的內存數量，更容易被控制，而在單進(jìn)程的模式下，幾乎是不能作出控制的，所以，很多時(shí)候，多進(jìn)程模式耗費的內存，是會(huì )小于多線(xiàn)程模式的。這個(gè)說(shuō)法靠不靠譜，大家心里都有譜，就不多說(shuō)了。

    具體說(shuō)來(lái)，Chrome對進(jìn)程工作集的控制算法還是比較簡(jiǎn)單的。首先，在進(jìn)程啟動(dòng)的時(shí)候，需要指明進(jìn)程工作的內存環(huán)境，是高內存，低內存，還是中等內存，默認模式下，是中等內存（我以為Chrome會(huì )動(dòng)態(tài)計算的，沒(méi)想到竟然是啟動(dòng)時(shí)指定…）。在高內存模式，不存在對工作集的調整，使勁用就完事了；在低內存的模式下，調整也很簡(jiǎn)單，一旦一個(gè)進(jìn)程不再有頁(yè)面面對觀(guān)眾了，嘗試釋放其所有工作集。相比來(lái)說(shuō)，中等模式下，算法相對復雜一些，當一個(gè)進(jìn)程從直接面對觀(guān)眾，淪落到切換到后臺的悲慘命運，其工作集會(huì )縮減，算法為： TargetWorkingSetSize = (LastWorkingSet/2 + CurrentWorkingSet) /2；其中，TargetWorkingSetSize指的是預期降到的工作集大小，CurrentWorkingSet指的是進(jìn)程當前的工作集（在Chrome中，工作集的大小，包含私有的和可共享的兩部分內存，而不包含已經(jīng)共享了的內存空間…），LastWorkingSet，等于上一次的CurrentWorkingSet除以DampingFactor，默認的DampingFactor為2。而反之，當一個(gè)進(jìn)程從幕后走向臺前，它的工作集會(huì )被放大為 LastWorkingSet * DampingFactor * 2，了解過(guò)LastWorkingSet的含義，你已經(jīng)知道，這就是將工作集放大兩倍的另類(lèi)版寫(xiě)法。

    Chrome的Render進(jìn)程工作集調整，除了發(fā)生在tab切換（或新頁(yè)面建立）的時(shí)候，還會(huì )發(fā)生在整個(gè)Chrome的idle事件觸發(fā)后。Chrome有個(gè)計時(shí)器，統計Chrome空閑的時(shí)長(cháng)，當時(shí)長(cháng)超過(guò)30s后（此工作會(huì )反復進(jìn)行…），Chrome會(huì )做一系列工作，其中就包括，調整進(jìn)程的工作集。被調整的進(jìn)程，不僅僅是Render進(jìn)程，還包括Plugin進(jìn)程和Browser進(jìn)程，換句話(huà)描述，就是所有Chrome進(jìn)程。

    這個(gè)算法導致一個(gè)很悲涼的狀況，當你去蹲了個(gè)廁所回到電腦前，切換了一個(gè)Chrome頁(yè)面，你發(fā)現頁(yè)面一片慘白，一陣硬盤(pán)的騷動(dòng)過(guò)后，好不容易恢復了原貌。如果再切，相同的事情又會(huì )發(fā)生，孜孜不倦，直到你切過(guò)每一個(gè)進(jìn)程。這個(gè)慘案發(fā)生的主要原因，就是由于所有Chrome進(jìn)程的工作集都被釋放了，頁(yè)面的重載和Render需要不少的一坨時(shí)間，這就大大影響了用戶(hù)感受，畢竟，總看到慘白的畫(huà)面，容易產(chǎn)生不好的情緒。強烈感覺(jué)這個(gè)不算一個(gè)很出色的策略，應該有一個(gè)工作集切換的底限，或者是在Chrome從idle中被激活的時(shí)候，偷偷摸摸的統一擴大工作集，發(fā)幾個(gè)事件刺激一下，把該加載的東西加載起來(lái)。

    整體感覺(jué)，Chrome對進(jìn)程開(kāi)銷(xiāo)的控制，并不像想象中的有非常精妙絕倫的策略在里面，通過(guò)工作集這總手段并不算華麗，而且，如果想很好的工作的話(huà)，有一個(gè)非常非常重要的前提，就是被切換的頁(yè)面，很少再被繼續瀏覽。個(gè)人覺(jué)得這個(gè)假設并不是十分可靠，這就使得在某些情況下，產(chǎn)生非常不好的用戶(hù)體驗，也許Chrome需要進(jìn)一步在這個(gè)地方琢磨點(diǎn)方法的。

本文Chrome源碼剖析、上，完。

--------------------------------------------------------------------------------

本文版權歸原著(zhù)duguguiyu和譯者July共同所有。轉載，請以超鏈接形式注明出處。謝謝。

本文來(lái)自CSDN博客，轉載請標明出處：http://blog.csdn.net/v_JULY_v/archive/2011/04/02/6296329.aspx