Chrome渲染優化：層模型
引言
對于大多數Web開發者而言，Web頁面的基本模型就是DOM模型。頁面的渲染過程常常并不為人所知，大家只是知道它是一個將頁面的DOM表示方式轉化為在屏幕上顯示的一個圖片的過程。近幾年，現代瀏覽器利用圖形卡對頁面渲染方式進行了改進：這種改進一般都籠統地稱為“硬件加速”。當談及普通Web頁面（也即：非Canvas2D或者WebGL頁面）時，硬件加速這個詞到底意味著什么？本文將對作為Chrome中硬件加速下Web頁面渲染基礎的基本模型進行說明。
冗長的注意事項
我們在這里討論的是WebKit，更具體地講，我們討論的是Chromium下的WebKit。 本文所涉及的是Chrome的實現細節，而不是Web平臺的特性。Web平臺及其標準并沒有對這個層次的實現細節做出詳細的規定，所以我們并不能保證本文中的內容可以適用于其它的瀏覽器，但是對瀏覽器內部工作機理的了解定會有益于對應用進行高水平的錯誤調試和性能調優。
另外還要主意，整個這篇文章討論的都是Chrome渲染架構中的一個核心部分，但這個結構仍在迅速變化之中。本文試圖僅僅涉及那些不太可能發生變化的部分，但要是在6個月后再看這篇文章，那可就不一定是什么情況了。
很重要的是要明白Chrome當下有段時間還會有兩個不同的渲染途徑：硬件加速式的渲染和早期軟件式的渲染。直到寫這篇文章之時為止，在Windows、 ChromeOS和Android下的Chrome中，所有的頁面都走的是硬件加速途徑。在Mac和Linux下， 只有那些部分內容需要組合的頁面才會走硬件加速途徑（更多關于什么才需要組合的說明請參見下文），但用不了多久，所有頁面將都會走硬件加速途徑。
最后要說的是，我們在這里的內容只是對Chrome的渲染引擎的管窺之見，所看到的只是其對性能影響比較大的一些特性。當你想要提高你的網站的性能時，對層模型有所了解會非常有幫助作用，但這也容易造成搬起石頭砸自己腳的情況：層這種結構非常有用，但是創建過多的層會造成整個圖形棧開銷的增加。到時候可別說我沒有提前警告過你哦！
從DOM到屏幕
層的引入
頁面一旦在裝入并解析完成后，就會表示為許多Web開發者所熟悉的結構：DOM。然而，在頁面的渲染過程中，瀏覽器還具有一系列并不直接暴露給開發者的頁面中間表示方式。這些表示方式中最重要的結構就是層。
在Chrome中實際上有幾種不同類型的層：掌管DOM子樹的渲染層（RenderLayer）以及掌管渲染層子樹的圖形層（GraphicsLayer）。 我們這里最關心的是后者，因為作為紋理上傳到GPU之中的就是圖形層。本文自此就只用“層”來指代圖形層了。
稍稍離題說一下同GPU有關的幾個術語：什么是紋理？紋理可以看作是位圖圖像，從主存儲器（也就是RAM）傳遞到視頻存儲器（也就是GPU之上的 VRAM）之中的就是這個圖像。一旦傳遞到GPU之中后，你就能夠將紋理映射到一個網格幾何結構之上 —— 在視頻游戲或者CAD程序中，這種技術用來給框架式的3D模型添加“皮膚”。Chrome采用紋理把頁面中的內容分塊發送給GPU。紋理能夠以很低的代價映射到不同的位置，而且還能夠以很低的代價通過把它們應用到一個非常簡單的矩形網格中進行變形。這就是3D CSS的實現原理，而且這么做對頁面在屏幕的快速滾動也非常好 —— 現在先說這些，這兩方面更詳細的探討情況下文。
下面讓我們用幾個例子來說明層的概念。
在Chome中研究層時有一個非常有用的工具就是Chrome的開發者工具里設置（也就是那個小齒輪圖標）中“渲染（rendering）”小標題下的 “顯示層的組合邊界（show composited layer borders）”開關。讓我們把這個開關打開。本文中所有的截屏和例子都來自最新版的Chrome Canary，在寫這篇文章的時候是Chrome 27。
圖1： 只有一層的頁面 (將在新窗口中打開)
- <html>
- <body>
- <div>I am a strange root.</div>
- </body>
- </html>
（譯者注：這里缺了一個圖，原文中的圖就看不到，可能是需要翻墻？）
在頁面的基本層中組合層的渲染邊界屏幕截圖
這個頁面只有一層。藍色的柵格表示的是分塊，這些分塊可以看作是比層更低一級的單位，Chrome以這些分塊為單位，一次向GPU上傳一個分塊的內容。這里它們并不怎么重要。
圖2：有自己的層的元素 (open stand-alone)
- <html>
- <body>
- <div style="-webkit-transform: rotateY(30deg) rotateX(-30deg); width: 200px;">
- I am a strange root.
- </div>
- </body>
- </html>
（譯者注：這里缺了一個圖，原文中的圖就看不到，可能是需要翻墻？）
旋轉后層的渲染邊界的截屏
在<div>上加上讓它旋轉一個角度的3D CSS屬性后，我們就能夠看到一個元素有自己的層是個什么樣子：請注意其中的橘色邊界，這個邊界給出了這個視圖中層的輪廓。
層的創建準則
還要其它什么元素會得到自己的層？Chrome在這方面采用的規則仍在隨著時間推移逐漸發展變化，但在目前下面這些因素都會引起Chrome創建層：
- 進行3D或者透視變換的CSS屬性
- 使用硬件加速視頻解碼的<video>元素
- 具有3D（WebGL）上下文或者硬件加速的2D上下文的<canvas>元素
- 組合型插件（即Flash）
- 具有有CSS透明度動畫或者使用動畫式Webkit變換的元素
- 具有硬件加速的CSS濾鏡的元素
- 子元素中存在具有組合層的元素的元素（換句話說，就是存在具有自己的層的子元素的元素）
- 同級元素中有Z索引比其小的元素，而且該Z索引比較小的元素具有組合層（換句話說就是在組合層之上進行渲染的元素）
實際意義：動畫
我們還可以將層在頁面中到處移動，正好可用于動畫。
圖3: 動畫層（將在新窗口中打開）
- <html>
- <head>
- <style type="text/css">
- div {
- -webkit-animation-duration: 5s;
- -webkit-animation-name: slide;
- -webkit-animation-iteration-count: infinite;
- -webkit-animation-direction: alternate;
- width: 200px;
- height: 200px;
- margin: 100px;
- background-color: gray;
- }
- @-webkit-keyframes slide {
- from {
- -webkit-transform: rotate(0deg);
- }
- to {
- -webkit-transform: rotate(120deg);
- }
- }
- </style>
- </head>
- <body>
- <div>I am a strange root.</div>
- </body>
- </html>
正如前文所述，層在將Web頁面中的靜態內容隨處移動方面真的很有用。在最基本的情況下，Chrome將層中的內容繪制到軟件位圖中，然后再將該位圖作為紋理上載到GPU之中。如果層中的內容將來不會發生變化，那就不需要對其進行重繪了。這是個好事：重繪將會占用本可以用于干其它事情，比如運行 JavaScript的時間，而且如果繪制過程太長，動畫還會出現卡頓現象。
例如，可以在Chrome的開發工具中看一下這個頁面的時間線：但該層在來回旋轉的時候，并沒有出現繪制操作。 動畫過程中的開發者工具時間線屏幕截圖無效！重繪
但是如果層中的內容發生了改變，它就需要重繪了。
圖4：層的重繪 (將在新窗口打開)
- <html>
- <head>
- <style type="text/css">
- div {
- -webkit-animation-duration: 5s;
- -webkit-animation-name: slide;
- -webkit-animation-iteration-count: infinite;
- -webkit-animation-direction: alternate;
- width: 200px;
- height: 200px;
- margin: 100px;
- background-color: gray;
- }
- @-webkit-keyframes slide {
- from {
- -webkit-transform: rotate(0deg);
- }
- to {
- -webkit-transform: rotate(120deg);
- }
- }
- </style>
- </head>
- <body>
- <div id="foo">I am a strange root.</div>
- <input id="paint" type="button" onclick="" value=”repaint”>
- <script>
- var w = 200;
- document.getElementById('paint').onclick = function() {
- document.getElementById('foo').style.width = (w++) + 'px';
- }
- </script>
- </body>
- </html>
每次點擊按鈕后，旋轉中的元素的寬度就會增加1px。這將導致頁面重新布局，整個元素都需要重繪，在這個例子中需要重繪的是整個層。
#p#
查看Chrome重繪了哪些元素的一個很好的辦法是使用開發者工具中的“顯示繪制矩形”開關，這個開關同樣也在開發者工具設置中的“渲染”標題下。打開該開關后，在點擊按鈕的時候請注意動畫中的元素和按鈕周圍都會有一個紅色的矩形閃現。
顯示繪制矩形檢查框的屏幕截圖
同時繪制時間也出現在開發者工具里的時間線中了。明眼的讀者可能還注意到這里有兩個繪制事件：一個是層的，另外一個是按鈕的。按鈕會在它的狀態變成按下狀態和從按下狀態變為非按下狀態時需要進行重繪。
開發者工具時間線中層的重繪的屏幕截圖
請注意Chrome并不總是需要重繪整個層，它會盡量地以聰明的方式只繪制DOM中發生變化的那部分內容。在我們的這個例子中，我們所改變的DOM元素是整個層的尺寸。但是在很多情況下，在一層中會有大量的DOM元素。
很顯然接下來的問題是頁面內容失效和強制進行重繪是由什么引起的。要全面回答這個問題并不容易，因為引起強制進行重繪的有大量不太容易區分的情況。其中最常見的原因是通過操縱CSS樣式或者引起重新進行頁面布局來改變DOM的特性。Tony Gentilcore寫了一篇很不錯的討論引起頁面重新布局的原因的博文，Stoyan Stefanov有一篇更近詳盡地討論瀏覽器繪制過程的文章（但這篇文章僅僅止于繪制過程，并沒有涉及奇特的組合部分的內容）。
找出重繪是否影響到了某些你正在關注中的元素的最好方式是使用開發者工具中的時間線以及“顯示繪制矩形”工具，用這兩個工具能夠看出瀏覽器是否在重繪一些你并不認為需要重繪的內容，然后找出就在重新布局/重繪前的那個時刻之前到底是在哪里改變了DOM結構。如果繪制過程無法避免但繪制過程卻長的不太合理，請參考一下Eberhard Gräther的文章，這是一篇關于在開發者工具中如果對持續性繪制模式進行性能優化的文章。
總結：從DOM到屏幕
Chrome是如何將DOM轉換為屏幕上的圖像的呢？從概念上講，它：
- 取得DOM并將其分成若干個層
- 分布將這些層繪制到各自的軟件位圖中
- 將繪制好的位圖作為紋理上載至GPU之中
- 將這些不同的層組合起來形成屏幕上最后顯示出的圖像
這些步驟在Chrome第一次產生Web頁面的幀時都需要執行。但是在產生隨后的幀時，就可能會走一些捷徑：
- 如果有某些CSS屬性發生了改變，就并不一定要重繪所有的內容了。Chrome能夠將已經作為紋理保存在GPU之中的層重新組合起來，但只是在重新組合時，使用不同的組合屬性（比如，在不同的位置、以不同的透明度來組合等等）。
- 如果某一層中的某個部分的內容變成無效的了，那么該層就需要重繪并在重繪完成后重新上載至GPU中。如果其內容仍然不變，只是其組合屬性發生了變化（比如它的位置或者透明度改變了），Chrome就不會對GPU中該層的位圖做任何處理，只是通過重新進行組合來生成新的幀。
現在大家應該弄清楚了，基于層的組合模型對渲染性能有著非常大的意義。在沒有需要重新繪制的內容時，組合的代價相對來說代價更低一些，所以在調試渲染性能時，避免層的重繪是一個非常好的總體目標。經驗老道的開發者會去看上文提到的組合觸發的列表，并意識到很可能會非常容易的導致瀏覽器創建很多層。但是，一定要小心無意識地去創建層，因為使用層是有代價的：它們會占用系統RAM以及GPU中的存儲空間（移動設備上的存儲空間特別有限），層太多的話還會在跟蹤哪些從可見哪些層不可見的算法中引入額外的開銷。如果層都很大而且原先不重疊的層突然重疊了起來，那么太多的層就會增加瀏覽器花在柵格化方面的時間，這會導致有時稱之為“過度繪制”的情況。所以，一定要明智地運用你所學到的知識！
暫時先寫到這里了。請你以后再到這里來查看另外幾篇關于層模型實際意義的文章。
其它參考資料
英文原文：Accelerated Rendering in Chrome - The Layer Model
譯文鏈接：http://www.oschina.net/translate/chrome-accelerated-rendering
