|
原文：http://www.cnblogs.com/duguguiyu/archive/2008/10/24/1318363.html
1. Chrome的窗口控件
Chrome提供了自己的一個UI控件庫，相關(guān)文檔可以參見 這里 。用Chrome自己的話來說，我覺得市面上的七葷八素的圖形控件庫都不好用，于是自己倒騰倒騰實現(xiàn)了一套。。。
廣告雖如此說，不過，Chrome的圖形控件結(jié)構(gòu)，我還未發(fā)現(xiàn)有啥非常非常特別的地方。Chrome的窗口、按鈕、菜單之類的控件，都直接或間接派生自View，這個是控件基類。Chrome的View具有樹形結(jié)構(gòu)，其內(nèi)部有一個子View數(shù)組，由此構(gòu)成一個控件常用的組合模式。。。
有一個比較特殊的View子類，叫做RootView，顧名思義，它是整個View控件樹的根，在Chrome中，一個正確的樹形的控件結(jié)構(gòu)，必須由RootView作為根。之所以要這樣設(shè)計，是因為RootView有一個比較特殊的功能，那就是分發(fā)消息。。。
我們知道，一般的Windows控件，都有一個HWND，用與占據(jù)一塊屏幕，捕獲系統(tǒng)消息。Chrome中的View只是保存控件相關(guān)信息和繪制控件，里面沒有HWND句柄，因此不能夠捕獲系統(tǒng)消息。在Chrome中，完整的控件架構(gòu)是這樣的，首先需要有一個ViewContainer，它里面包含一個RootView。ViewContainer是一個抽象類，在Window中的一個子類是HWNDViewContainer，同時，HWNDViewContainer還是MessageLoopForUI::Observer的子類。如果你看過本文第一部分描述的線程通信的內(nèi)容的話，你就應(yīng)該還記得，Observer是用于監(jiān)聽本線程內(nèi)系統(tǒng)消息的東東。。。
當(dāng)有系統(tǒng)消息進(jìn)入此線程消息循環(huán)后，HWNDViewContainer會監(jiān)聽到這個情況，如果和View相關(guān)的消息，它就會調(diào)用RootView的相關(guān)方法，傳遞給控件。在RootView的內(nèi)部，會遍歷整個控件樹上的控件，將消息傳遞給各個控件。當(dāng)然，有的消息是可以獨占的，比如鼠標(biāo)移動發(fā)送在某個View所管轄的范圍內(nèi)，它會告知RootView（通過方法的返回值...），這個消息我要了，那么RootView會停止遍歷。。。
在設(shè)計的時候，View對消息的處理，采取的是大而全的接口模式。就是說在View內(nèi)部，提供了所有可能的消息處理接口，并提供了默認(rèn)實現(xiàn)，所有子類只需要覆蓋自己需要的消息處理函數(shù)即可。如果對MFC的消息映射有了解的話，可以知道兩者的區(qū)別。MFC在設(shè)計的時候，覺得無法提供大而全的接口，因為消息總類實在太多，而且還是可擴(kuò)展的，于是就有了消息映射著一套繁瑣的宏。但Chrome的圖形框架，顯然沒有做一個通用的Framework的打算，因此，可以采用這樣的策略，使得子類的派生變得簡單而自然。。。
每一個View的子類控件，比如Button之類的，會存儲一些數(shù)據(jù)，根據(jù)消息做一些行為，并且繪制出自己。在Chrome中，畫圖的東西是ChromeCanvas這個類，在其內(nèi)部，通過Skia和GDI實現(xiàn)繪制。Skia是Android團(tuán)隊開發(fā)的一個跨平臺的圖形引擎，在Chrome中負(fù)責(zé)除了文字之外，所有內(nèi)容的繪制；而文字繪制的重?fù)?dān)，在Windows中交到了GDI的手上。這樣的設(shè)計會給跨平臺帶來一些困難，估計是由Skia實現(xiàn)文本繪制會比較繁瑣，才會帶出如此一個設(shè)計的模式。。。
另外一個歷史遺留產(chǎn)物，就是在Windows下的圖形控件，還有一些是原生的，就是說帶有HWND那種傳統(tǒng)的控件，這是Chrome身上不多的趕工期的痕跡，隨著時間的寬裕，這樣的原生控件會被淘汰進(jìn)歷史的垃圾箱，而全部變?yōu)閺腣iew派生的控件。。。
其實，對于Chrome這套控件架構(gòu)我還沒算摸得很熟悉，估計等到做一次插件之后會了解的更透徹，因此，只說了點皮毛，聊表心意。。。
2. Chrome的頁面加載和繪制
上面這些UI控件，都是用在窗口上的（比如瀏覽器的外框，菜單，對話框之類的...）。我們在瀏覽器中看到的大部分內(nèi)容，是網(wǎng)頁頁面。頁面的繪制（繪制，就是把一個HTML文件變成一個活靈活現(xiàn)的頁面展示的過程...），只有一半輪子是Chrome自己做的，還有一部分來自于WebKit，這個Apple打造的Web渲染器。。。
之所以說是一半輪子來源于WebKit，是因為WebKit本身包含兩部分主要內(nèi)容，一部分是做Html渲染的，另一部分是做JavaScript解析的。在Chrome中，只有Html的渲染采用了WebKit的代碼，而在JavaScript上，重新搭建了一個NB哄哄的V8引擎。目標(biāo)是，用WebKit + V8的強(qiáng)強(qiáng)聯(lián)手，打造一款上網(wǎng)沖浪的法拉利，從效果來看，還著實做的不錯。。。
不過，雖說Chrome和WebKit都是開源的，并聯(lián)手工作。但是，Chrome還是刻意的和WebKit保持了距離，為其始亂終棄埋下了伏筆。Chrome在WebKit上封裝了一層，稱為WebKit Glue。Glue層中，大部分類型的結(jié)構(gòu)和接口都和WebKit類似，Chrome中依托WebKit的組件，都只是調(diào)用WebKit Glue層的接口，而不是直接調(diào)用WebKit中的類型。按照Chrome自己文檔中的話來說，就是，雖然我們再用WebKit實現(xiàn)頁面的渲染，但通過這個設(shè)計（加一個間接層...）已經(jīng)從某種程度大大降低了與WebKit的耦合，使得可以很容易將WebKit換成某個未來可能出現(xiàn)的更好的渲染引擎。。。
重用
在《夢斷代碼》中，有一坨調(diào)侃重用的文字。他覺著軟件重用的困難一方面來自于場景本身很多變，很難設(shè)計出一套包羅萬象的東西；另一方面來自于人，程序員總是瞅著別人寫的代碼不順眼，總喜歡自己寫一套。。。
于是，解決重用這個問題也就只有兩種，寫最NB人見人服無所不能的代碼，或者是有很多很多NB代碼共君任選。Google無疑在這兩個方面做得都不錯，Map/Reduce，Big Table之類的一套東西，強(qiáng)大到可以適合太多的場景，大大簡化了N多上層應(yīng)用的開發(fā)。而對開源的利用使用，使得其可以隨意挑一個巨人站到他肩膀上跳舞，每看到這種場景，MS估計都會氣得拍著胸口吐血。。。
Google本身在服務(wù)端的基礎(chǔ)底層，有很深積累，隨著Chrome，Android等等客戶端應(yīng)用的開發(fā)，客戶端的積累也逐步提升，也許，擁抱開源才是MS的正道？。。。
當(dāng)你鍵入一個Url并敲下回車后，Chrome會在Browser進(jìn)程中下載Url對應(yīng)的頁面資源（包括Web頁面和Cookie），而不是直接將Url發(fā)送給Render進(jìn)程讓它們自行下載（你會越來越發(fā)現(xiàn)，Render進(jìn)程絕對是100%的名符其實，除了繪制，幾乎啥多余的事情都不會干的...）。與各個Render進(jìn)程各自為站，各自管好自己所需的資源相比，這種策略仿佛會增加大量的進(jìn)程間通信。之所以采用，按照 這篇文檔 的解釋，主要有三個優(yōu)點，一個是避免子進(jìn)程與網(wǎng)絡(luò)通信，從而將網(wǎng)絡(luò)通信的權(quán)限牢牢握在主進(jìn)程手中，Render進(jìn)程能力弱了，想造反干壞事的可能性就降低了（可以更好控制各個Render進(jìn)程的權(quán)限...）；另一個是有利于Cookie等持久化資源在不同頁面中的共享，否則在不同Render進(jìn)程中傳遞Cookie這樣的事情，做起來更麻煩；還有一點很重要的，是可以控制與網(wǎng)絡(luò)建立HTTP連接的數(shù)量，以Browser為代表與網(wǎng)絡(luò)各方進(jìn)行通信，各種優(yōu)化策略都比較好開展（比如池化）。。。
當(dāng)然，在Browser進(jìn)程中進(jìn)行統(tǒng)一的資源管理，也就意味著不再方便用WebKit進(jìn)行資源下載（WebKit當(dāng)然有此能力，不過再次被Chrome拋棄了...），而是依托WinHTTP來做的。WinHTTP在接受數(shù)據(jù)的過程中，會不停的把數(shù)據(jù)和相關(guān)的消息通過IPC，發(fā)送給負(fù)責(zé)繪制此頁面的Render進(jìn)程中對應(yīng)的RenderView。在這里，路由消息中的那個ID值起了關(guān)鍵的作用，系統(tǒng)依照此ID，能夠準(zhǔn)確的將相關(guān)的消息發(fā)送到相關(guān)的View頭上，這玩意發(fā)錯了地方還真不是和有人把錢錯到你賬戶上一樣，因為錯收的進(jìn)程基本上無福消受這個意外來客，輕者頁面顯示混亂，重者消化不良直接噎死。。。
RenderView接收到頁面信息，會一邊繪制一邊等待更多的資源到來，在用戶看來，所請求的頁面正在一點一點顯示出來。當(dāng)然，如果是一個通知傳輸開始、傳輸結(jié)束這樣的消息，通過序列化到消息參數(shù)里面，經(jīng)由IPC發(fā)過來，代價還是可以承受的，但是，想資源內(nèi)容這樣大段大段的字節(jié)流，如果通過消息發(fā)過來，浪費兩邊進(jìn)程大量空間和時間，就不合適了。于是這里用到了共享內(nèi)存。Browser進(jìn)程將下載到的資源寫到共享內(nèi)存中，并將共享內(nèi)存的句柄和共享區(qū)域的大小序列化在消息中發(fā)送給Render進(jìn)程。Render進(jìn)程拿到這個句柄，就可以通過它訪問到共享內(nèi)存相關(guān)的區(qū)域，讀取信息并進(jìn)行繪制。通過這樣的方式，即享用到了統(tǒng)一資源管理的優(yōu)點，由避免了很高的進(jìn)程通信開銷，左右逢源，好不快活。。。
3. Chrome頁面的消息響應(yīng)
Render進(jìn)程是一個嬌生慣養(yǎng)的進(jìn)程，這一點從上面一段已經(jīng)可以看出來了。它自己的資源它自己都不下載，而是由Browser進(jìn)程來幫忙。不過Render進(jìn)程也許比你想象的還要懶惰一些，它不但不自己下載資源，甚至，連自己的系統(tǒng)消息都不接收。。。
Render進(jìn)程中不包含HWND，當(dāng)你鼠標(biāo)在頁面上劃來劃去，點上點下，這些消息其實都發(fā)到了Browser進(jìn)程，它們擁有頁面呈現(xiàn)部分的HWND。Browser會將這些消息轉(zhuǎn)手通過IPC發(fā)送給對應(yīng)的Render進(jìn)程中的RenderView，很多時候WebKit會處理此類消息，當(dāng)它發(fā)現(xiàn)出現(xiàn)了某種值得告訴Browser進(jìn)程的事情，它會組個報回贈給Browser進(jìn)程。舉個例子，你打開一個頁面，然后拿鼠標(biāo)在頁面上亂晃。Browser這時候就像一個碎嘴大嬸，不厭其煩的告訴Render進(jìn)程，“鼠標(biāo)動了，鼠標(biāo)動了”。如果Render對這個信息無所謂，就會很無聊的應(yīng)答著：“哦，哦”（發(fā)送一個回包...）。但是，當(dāng)鼠標(biāo)劃過鏈接的時候，矜持的Render進(jìn)程坐不住了，會大聲告訴Browser進(jìn)程：“換鼠標(biāo)，換鼠標(biāo)~~”，Browser聽到后，會將鼠標(biāo)從箭頭狀換成手指狀，然后繼續(xù)以上過程。。。
比較麻煩的是Paint消息，重新繪制頁面是一個太頻繁發(fā)生的事情，不可能重繪一次就序列化一坨字節(jié)流過去。于是策略也很清楚了，就是依然用共享內(nèi)存讀寫，用消息發(fā)句柄。在Render進(jìn)程中，會有一個共享內(nèi)存池（默認(rèn)值為2...），以size為key，以共享內(nèi)存為值，簡單的先入先出淘汰算法，利用局部性的特征，避免反復(fù)的創(chuàng)建和銷毀共享內(nèi)存（這和資源傳遞不一樣，因為資源傳遞可以開一塊固定大小的共享內(nèi)存...）。Render進(jìn)程從共享內(nèi)存池中拿起一塊（二維字節(jié)數(shù)組...），就好像拿著一塊屏幕似的，拼了命往上繪制，為了讓Render安心覺著有成就感，Browser會偷偷幫Render把這些內(nèi)容繪制到屏幕上，造成Render進(jìn)程直接繪制屏幕的假象。這可就苦了屏幕取詞的工具們，因為在HWND上壓根就沒啥字符信息，全部就是一坨圖像而已，啥也取不著。于是Google金山詞霸，網(wǎng)易有道詞霸各自發(fā)揮智慧，另辟蹊徑，也算是都利用Chrome做了一把廣告。。。
為什么不讓Render進(jìn)程自己擁有HWND，自己管理自己的消息，既快捷又便利。在Chrome的官方Blog上，有一篇 解釋的文章 ，基本上是這個意思，速度是必須快的發(fā)指的，但是為了用戶響應(yīng)，放棄一些速度是必要的，畢竟，沒有人喜歡總假死的瀏覽器。在Browser進(jìn)程中，基本上是杜絕任何同步Render進(jìn)程的工作，所有操作都是異步完成。因為Render進(jìn)程是不靠譜的，隨時可能犧牲掉，同步它們往往導(dǎo)致主進(jìn)程停止響應(yīng)，從而導(dǎo)致整個瀏覽器停下來甚至掛掉，這個代價是不可以容忍的。但是，Windows有一個惡習(xí)，喜歡往整個HWND繼承體系中發(fā)送同步消息（我不是很清楚這個狀況，有人能解釋么？...），這時候，如果HWND在Render進(jìn)程中，就務(wù)必會導(dǎo)致主進(jìn)程與Render進(jìn)程的同步，Chrome無法控制Windows，于是，它們只能夠控制Render，把它們的HWND搬到主進(jìn)程中，避免同步操作，換取用戶響應(yīng)的速度。。。
4. 結(jié)論
整個Chrome的UI架構(gòu)，就是一個權(quán)責(zé)分配的問題�？梢园袯rowser進(jìn)程看成是一個類似于朱元璋般的勤勞皇帝（詳見《明朝那些事 一》...），把大多數(shù)的權(quán)利都牢牢把握在手中，這樣，雖然Browser很操勞，但是整體上的協(xié)調(diào)和同步，都進(jìn)行的非常順暢。Render進(jìn)程就是皇帝手下的傀儡宰相們，只負(fù)責(zé)自己的一畝三分地，聽從皇帝的調(diào)配即可。這這樣的環(huán)境下，Render進(jìn)程的生死變得無足輕重，Render的死亡，只是少了一個繪制頁面的工具而已，其他一切如故。通過控制權(quán)力，換取天下太平，這招在coding界，同樣是一個不錯的策略，但是，唯一的意外來自于Plugin。按照規(guī)范，Chrome的Plugin是可以創(chuàng)立窗口的（HWND），這必然導(dǎo)致同步問題，Chrome沒有辦法通過控制權(quán)力的方式解決這個問題，只能想些別的亡羊補(bǔ)牢的招來搞定。。。
出處：Venus神廟
責(zé)任編輯：bluehearts
上一頁 Chrome的進(jìn)程模型 下一頁 Chrome的插件模型
◎進(jìn)入論壇網(wǎng)絡(luò)編程版塊參加討論
|
第 1 頁 
第 8 頁 Chrome的UI繪制
