【四】Chrome的UI繪製
1. Chrome的窗口控件
Chrome提供了自己的一個UI控件庫，相關文檔可以參見這裏。用Chrome自己的話來說，我覺得市面上的七葷八素的圖形控件庫都不好用，於是自己倒騰倒騰實現了一套。。。
廣告雖如此說，不過，Chrome的圖形控件結構，我還未發現有啥非常非常特別的地方。Chrome的窗口、按鈕、菜單之類的控件，都直接或間接派生自View，這個是控件基類。Chrome的View具有樹形結構，其內部有一個子View數組，由此構成一個控件常用的組合模式。。。
有一個比較特殊的View子類，叫做RootView，顧名思義，它是整個View控件樹的根，在Chrome中，一個正確的樹形的控件結構，必須由RootView作爲根。之所以要這樣設計，是因爲RootView有一個比較特殊的功能，那就是分發消息。。。
我們知道，一般的Windows控件，都有一個HWND，用與佔據一塊屏幕，捕獲系統消息。Chrome中的View只是保存控件相關信息和繪製控件，裏面沒有HWND句柄，因此不能夠捕獲系統消息。在Chrome中，完整的控件架構是這樣的，首先需要有一個ViewContainer，它裏面包含一個RootView。ViewContainer是一個抽象類，在Window中的一個子類是HWNDViewContainer，同時，HWNDViewContainer還是MessageLoopForUI::Observer的子類。如果你看過本文第一部分描述的線程通信的內容的話，你就應該還記得，Observer是用於監聽本線程內系統消息的東東。。。
當有系統消息進入此線程消息循環後，HWNDViewContainer會監聽到這個情況，如果和View相關的消息，它就會調用RootView的相關方法，傳遞給控件。在RootView的內部，會遍歷整個控件樹上的控件，將消息傳遞給各個控件。當然，有的消息是可以獨佔的，比如鼠標移動發送在某個View所管轄的範圍內，它會告知RootView（通過方法的返回值...），這個消息我要了，那麼RootView會停止遍歷。。。
在設計的時候，View對消息的處理，採取的是大而全的接口模式。就是說在View內部，提供了所有可能的消息處理接口，並提供了默認實現，所有子類只需要覆蓋自己需要的消息處理函數即可。如果對MFC的消息映射有了解的話，可以知道兩者的區別。MFC在設計的時候，覺得無法提供大而全的接口，因爲消息總類實在太多，而且還是可擴展的，於是就有了消息映射着一套繁瑣的宏。但Chrome的圖形框架，顯然沒有做一個通用的Framework的打算，因此，可以採用這樣的策略，使得子類的派生變得簡單而自然。。。
每一個View的子類控件，比如Button之類的，會存儲一些數據，根據消息做一些行爲，並且繪製出自己。在Chrome中，畫圖的東西是ChromeCanvas這個類，在其內部，通過Skia和GDI實現繪製。Skia是Android團隊開發的一個跨平臺的圖形引擎，在Chrome中負責除了文字之外，所有內容的繪製；而文字繪製的重擔，在Windows中交到了GDI的手上。這樣的設計會給跨平臺帶來一些困難，估計是由Skia實現文本繪製會比較繁瑣，纔會帶出如此一個設計的模式。。。
另外一個歷史遺留產物，就是在Windows下的圖形控件，還有一些是原生的，就是說帶有HWND那種傳統的控件，這是Chrome身上不多的趕工期的痕跡，隨着時間的寬裕，這樣的原生控件會被淘汰進歷史的垃圾箱，而全部變爲從View派生的控件。。。
其實，對於Chrome這套控件架構我還沒算摸得很熟悉，估計等到做一次插件之後會了解的更透徹，因此，只說了點皮毛，聊表心意。。。
2. Chrome的頁面加載和繪製
上面這些UI控件，都是用在窗口上的（比如瀏覽器的外框，菜單，對話框之類的...）。我們在瀏覽器中看到的大部分內容，是網頁頁面。頁面的繪製（繪製，就是把一個HTML文件變成一個活靈活現的頁面展示的過程...），只有一半輪子是Chrome自己做的，還有一部分來自於WebKit，這個Apple打造的Web渲染器。。。
之所以說是一半輪子來源於WebKit，是因爲WebKit本身包含兩部分主要內容，一部分是做Html渲染的，另一部分是做JavaScript解析的。在Chrome中，只有Html的渲染採用了WebKit的代碼，而在JavaScript上，重新搭建了一個NB哄哄的V8引擎。目標是，用WebKit + V8的強強聯手，打造一款上網衝浪的法拉利，從效果來看，還着實做的不錯。。。
不過，雖說Chrome和WebKit都是開源的，並聯手工作。但是，Chrome還是刻意的和WebKit保持了距離，爲其始亂終棄埋下了伏筆。Chrome在WebKit上封裝了一層，稱爲WebKit Glue。Glue層中，大部分類型的結構和接口都和WebKit類似，Chrome中依託WebKit的組件，都只是調用WebKit Glue層的接口，而不是直接調用WebKit中的類型。按照Chrome自己文檔中的話來說，就是，雖然我們再用WebKit實現頁面的渲染，但通過這個設計（加一個間接層...）已經從某種程度大大降低了與WebKit的耦合，使得可以很容易將WebKit換成某個未來可能出現的更好的渲染引擎。。。
重用 |
當你鍵入一個Url並敲下回車後，Chrome會在Browser進程中下載Url對應的頁面資源（包括Web頁面和Cookie），而不是直接將Url發送給Render進程讓它們自行下載（你會越來越發現，Render進程絕對是100%的名符其實，除了繪製，幾乎啥多餘的事情都不會幹的...）。與各個Render進程各自爲站，各自管好自己所需的資源相比，這種策略彷彿會增加大量的進程間通信。之所以採用，按照這篇文檔的解釋，主要有三個優點，一個是避免子進程與網絡通信，從而將網絡通信的權限牢牢握在主進程手中，Render進程能力弱了，想造反幹壞事的可能性就降低了（可以更好控制各個Render進程的權限...）；另一個是有利於Cookie等持久化資源在不同頁面中的共享，否則在不同Render進程中傳遞Cookie這樣的事情，做起來更麻煩；還有一點很重要的，是可以控制與網絡建立HTTP連接的數量，以Browser爲代表與網絡各方進行通信，各種優化策略都比較好開展（比如池化）。。。
當然，在Browser進程中進行統一的資源管理，也就意味着不再方便用WebKit進行資源下載（WebKit當然有此能力，不過再次被Chrome拋棄了...），而是依託WinHTTP來做的。WinHTTP在接受數據的過程中，會不停的把數據和相關的消息通過IPC，發送給負責繪製此頁面的Render進程中對應的RenderView。在這裏，路由消息中的那個ID值起了關鍵的作用，系統依照此ID，能夠準確的將相關的消息發送到相關的View頭上，這玩意發錯了地方還真不是和有人把錢錯到你賬戶上一樣，因爲錯收的進程基本上無福消受這個意外來客，輕者頁面顯示混亂，重者消化不良直接噎死。。。
RenderView接收到頁面信息，會一邊繪製一邊等待更多的資源到來，在用戶看來，所請求的頁面正在一點一點顯示出來。當然，如果是一個通知傳輸開始、傳輸結束這樣的消息，通過序列化到消息參數裏面，經由IPC發過來，代價還是可以承受的，但是，想資源內容這樣大段大段的字節流，如果通過消息發過來，浪費兩邊進程大量空間和時間，就不合適了。於是這裏用到了共享內存。Browser進程將下載到的資源寫到共享內存中，並將共享內存的句柄和共享區域的大小序列化在消息中發送給Render進程。Render進程拿到這個句柄，就可以通過它訪問到共享內存相關的區域，讀取信息並進行繪製。通過這樣的方式，即享用到了統一資源管理的優點，由避免了很高的進程通信開銷，左右逢源，好不快活。。。
3. Chrome頁面的消息響應
Render進程是一個嬌生慣養的進程，這一點從上面一段已經可以看出來了。它自己的資源它自己都不下載，而是由Browser進程來幫忙。不過Render進程也許比你想象的還要懶惰一些，它不但不自己下載資源，甚至，連自己的系統消息都不接收。。。
Render進程中不包含HWND，當你鼠標在頁面上劃來劃去，點上點下，這些消息其實都發到了Browser進程，它們擁有頁面呈現部分的HWND。Browser會將這些消息轉手通過IPC發送給對應的Render進程中的RenderView，很多時候WebKit會處理此類消息，當它發現出現了某種值得告訴Browser進程的事情，它會組個報回贈給Browser進程。舉個例子，你打開一個頁面，然後拿鼠標在頁面上亂晃。Browser這時候就像一個碎嘴大嬸，不厭其煩的告訴Render進程，“鼠標動了，鼠標動了”。如果Render對這個信息無所謂，就會很無聊的應答着：“哦，哦”（發送一個回包...）。但是，當鼠標劃過鏈接的時候，矜持的Render進程坐不住了，會大聲告訴Browser進程：“換鼠標，換鼠標~~”，Browser聽到後，會將鼠標從箭頭狀換成手指狀，然後繼續以上過程。。。
比較麻煩的是Paint消息，重新繪製頁面是一個太頻繁發生的事情，不可能重繪一次就序列化一坨字節流過去。於是策略也很清楚了，就是依然用共享內存讀寫，用消息發句柄。在Render進程中，會有一個共享內存池（默認值爲2...），以size爲key，以共享內存爲值，簡單的先入先出淘汰算法，利用局部性的特徵，避免反覆的創建和銷燬共享內存（這和資源傳遞不一樣，因爲資源傳遞可以開一塊固定大小的共享內存...）。Render進程從共享內存池中拿起一塊（二維字節數組...），就好像拿着一塊屏幕似的，拼了命往上繪製，爲了讓Render安心覺着有成就感，Browser會偷偷幫Render把這些內容繪製到屏幕上，造成Render進程直接繪製屏幕的假象。這可就苦了屏幕取詞的工具們，因爲在HWND上壓根就沒啥字符信息，全部就是一坨圖像而已，啥也取不着。於是Google金山詞霸，網易有道詞霸各自發揮智慧，另闢蹊徑，也算是都利用Chrome做了一把廣告。。。
爲什麼不讓Render進程自己擁有HWND，自己管理自己的消息，既快捷又便利。在Chrome的官方Blog上，有一篇解釋的文章，基本上是這個意思，速度是必須快的髮指的，但是爲了用戶響應，放棄一些速度是必要的，畢竟，沒有人喜歡總假死的瀏覽器。在Browser進程中，基本上是杜絕任何同步Render進程的工作，所有操作都是異步完成。因爲Render進程是不靠譜的，隨時可能犧牲掉，同步它們往往導致主進程停止響應，從而導致整個瀏覽器停下來甚至掛掉，這個代價是不可以容忍的。但是，Windows有一個惡習，喜歡往整個HWND繼承體系中發送同步消息（我不是很清楚這個狀況，有人能解釋麼？...），這時候，如果HWND在Render進程中，就務必會導致主進程與Render進程的同步，Chrome無法控制Windows，於是，它們只能夠控制Render，把它們的HWND搬到主進程中，避免同步操作，換取用戶響應的速度。。。
4. 結論
整個Chrome的UI架構，就是一個權責分配的問題。可以把Browser進程看成是一個類似於朱元璋般的勤勞皇帝（詳見《明朝那些事 一》...），把大多數的權利都牢牢把握在手中，這樣，雖然Browser很操勞，但是整體上的協調和同步，都進行的非常順暢。Render進程就是皇帝手下的傀儡宰相們，只負責自己的一畝三分地，聽從皇帝的調配即可。這這樣的環境下，Render進程的生死變得無足輕重，Render的死亡，只是少了一個繪製頁面的工具而已，其他一切如故。通過控制權力，換取天下太平，這招在coding界，同樣是一個不錯的策略，但是，唯一的意外來自於Plugin。按照規範，Chrome的Plugin是可以創立窗口的（HWND），這必然導致同步問題，Chrome沒有辦法通過控制權力的方式解決這個問題，只能想些別的亡羊補牢的招來搞定。。。