摘要：頁面性能優(yōu)化學而不思則惘，思而不學則殆前幾天接到一個頁面效果優(yōu)化的任務，邊做邊查閱了一些關(guān)于頁面性能的資料。可能只需要在中使用這類屬性，即可開啟硬件加速硬件加速真的那么好嗎從本人在移動端開發(fā)的實踐來看，硬件加速是比較坑的。

學而不思則惘，思而不學則殆

前幾天接到一個頁面效果優(yōu)化的任務，邊做邊查閱了一些關(guān)于頁面性能的資料。做完任務之后，抽空寫了一篇總結(jié)，梳理一下思路，加深自己的理解。

先思考這樣的一個問題：

什么叫頁面性能好？如何進行評判？

直觀上講，我們通常會通過一個頁面流不流暢來判斷一個頁面的性能好不好。但是開發(fā)中，總不能這么隨意吧。

FPS(frame per second)，即一秒之間能夠完成多少次重新渲染.

網(wǎng)頁動畫的每一幀（frame）都是一次重新渲染，每秒低于24幀的動畫，人眼就能感受到停頓。一般的網(wǎng)頁動畫，需要達到每秒30幀到60幀的頻率，才能比較流暢。

而大多數(shù)顯示器的刷新頻率是60Hz，為了與系統(tǒng)一致，以及節(jié)省電力，瀏覽器會自動按照這個頻率，刷新動畫。所以，如果網(wǎng)頁能夠做到每秒60幀，就會跟顯示器同步刷新，達到最佳的視覺效果。這意味著，一秒之內(nèi)進行60次重新渲染，每次重新渲染的時間不能超過16.66ms。

在實際的開發(fā)，只要達到30fps就可以了

強大的chrome給我們提供了一個工具，叫做timeline，在幀模式下，我們可以看到代碼的執(zhí)行情況

柱狀"frame"：表示渲染過程中的一幀，也就是瀏覽器為了渲染單個內(nèi)容塊而必須要做的工作，包括：執(zhí)行js，處理事件，修改DOM，更改樣式和布局，繪制頁面等。幀柱的高度表示了該幀的總耗時，幀柱中的顏色分別對應該幀中包含的不停類型的事件。我們的目標就是控制其在30fps，即1000ms / 30 = 33.34ms

藍色: 網(wǎng)絡和HTML解析

黃色: JavaScript 腳本運行

紫色: 樣式重計算和布局 ( Layout , Recaculate Style, Update Layer tree)

綠色: 繪制和合成 ( Paint , Composite Layers)

30fps和60fps的基準線，可以直觀地看到頁面每一幀的情況

灰色區(qū)塊：那些沒有被DevTools感知到的活動

空白區(qū)塊：顯示刷新周期（display refresh cycles）中的空閑時間段？？

event ：事件，上面可以看到觸發(fā)了什么的事件，然后執(zhí)行的語句是哪些，

recalculate style: 重新計算樣式

update layer tree: 【耗時】

composite layers: 【耗時】

paint X n: 【耗時】

接下來思考這個問題：

什么是update layer tree，什么是compsite layers，它們?yōu)槭裁茨敲春臅r？

要理解update layer tree和composite layers，我們必須了解頁面的渲染原理和過程。

我們都知道網(wǎng)頁生成過程，大致可以分成五步

HTML代碼轉(zhuǎn)化為DOM

CSS代碼轉(zhuǎn)化成CSSOM（CSS Object Model）

結(jié)合DOM和CSSOM，生成一棵渲染樹（包含每個節(jié)點的視覺信息）

生成布局（layout），即將所有渲染樹的所有節(jié)點進行平面合成

將布局繪制（paint）在屏幕上

那么，瀏覽器是如何進行渲染的？

瀏覽器在渲染一個頁面時，會將頁面分為很多個圖層，圖層有大有小，每個圖層上有一個或多個節(jié)點。瀏覽器實際所做的工作有：

獲取DOM后分隔為多個圖層

對每個圖層的節(jié)點計算樣式結(jié)果（recalculate style）

為每個節(jié)點生成圖形和位置（layout即reflow和重布局）

將每個節(jié)點繪制填充到圖層位圖匯總（paint，repaint）

圖層作為紋理加載到GPU

合并多個圖層到頁面上，生成最終圖像（composite layers）

渲染的過程通常是相當耗時，低效的代碼往往就是觸發(fā)過程的layout，paint，composite layers，導致頁面卡頓。

明白了整個渲染的過程和timeline的操作的含義，那么可以思考這樣的一個問題：

什么樣的代碼會觸發(fā)這么耗時的操作，導致我們的頁面卡頓？

網(wǎng)頁生成的時候，至少會渲染一次。而我們需要關(guān)注的是用戶訪問過程中，那些會導致網(wǎng)頁重新渲染的行為：

修改DOM

修改樣式表

用戶事件（例如鼠標懸停，頁面滾動，輸入框輸入文字等）

重新渲染，就涉及重排和重繪

重排（reflow）

即重新生成布局，重排必然導致重繪，如元素位置的改變，就會觸發(fā)重排和重繪。

會觸發(fā)重排的的屬性：

盒子模型相關(guān)屬性會觸發(fā)重布局：

width

height

padding

margin

display

border-width

border

min-height

定位屬性及浮動也會觸發(fā)重布局：

top

bottom

left

right

position

float

clear

改變節(jié)點內(nèi)部文字結(jié)構(gòu)也會觸發(fā)重布局：

text-align

overflow-y

font-weight

overflow

font-family

line-height

vertival-align

white-space

font-size

重繪（repaint）

即重新繪制，需要注意的是，重繪不一定需要重排，比如改變某個元素的顏色，就只會觸發(fā)重繪，而不會觸發(fā)重排。

會觸發(fā)重繪的屬性

color

border-style

border-radius

visibility

text-decoration

background

background-image

background-position

background-repeat

background-size

outline-color

outline

outline-style

outline-width

box-shadow

手機就算重繪也很慢

重排和重繪會不斷觸發(fā)，這是不可避免的，但是它們非常消耗資源，是導致網(wǎng)頁性能低下的根本原因。

提高網(wǎng)頁性能，就是要降低重排和重繪的頻率和成本，盡量少觸發(fā)重新渲染。

大部分瀏覽器通過隊列化修改和批量顯示優(yōu)化重排版過程。然而有些操作會強迫刷新并要求所有計劃改變的部分立刻應用。

1. 創(chuàng)建圖層有什么用？

我們知道瀏覽器layout和paint是在每一個圖層上進行的，當有一個元素經(jīng)常變化，為了減少這個元素對頁面的影響，我們可以為這個元素創(chuàng)建一個多帶帶的圖層，來提供頁面的性能。

2. 在什么時候會創(chuàng)建圖層？

3D或透視變換（perspective transform）CSS屬性（例如translateZ(0)/translate3d(0,0,0)）

使用加速視頻解碼的

擁有3D（WebGL）上下文或加速的2D上下文的節(jié)點

混合插件（如Flash）

對自己的opacity做CSS動畫或使用一個動畫webkit變換的元素

擁有加速CSS過濾器的元素

元素有一個包含復合層的后代節(jié)點（一個元素擁有一個子元素，該子元素在自己的層里）

元素有一個z-index較低且包含一個復合層的兄弟元素（換句話說就是該元素在復合層上面渲染）

position為fixed也會創(chuàng)建圖層，而absolute則不會

3. 創(chuàng)建圖層的弊端

圖層的創(chuàng)建也需要一定的開銷，太多的圖層會消耗過多的內(nèi)存。這可能導致出現(xiàn)預期之外的行為，可能會導致潛在的崩潰。

1. 什么是硬件加速？

現(xiàn)代瀏覽器大都可以利用GPU來加速頁面渲染。在GPU的眾多特性之中，它可以存儲一定數(shù)量的紋理（一個矩形的像素點集合）并且高效地操作這些紋理（比如進行特定的移動、縮放和旋轉(zhuǎn)操作）。這些特性在實現(xiàn)一個流暢的動畫時特別有用。瀏覽器不會在動畫的每一幀都繪制一次，而是生成DOM元素的快照，并作為GPU紋理（也被叫做層）存儲起來。之后瀏覽器只需要告訴GPU去轉(zhuǎn)換指定的紋理來實現(xiàn)DOM元素的動畫效果。這就叫做GPU合成，也經(jīng)常被稱作硬件加速。

2. 怎么啟用硬件加速？

CSS animations, transforms 以及 transitions 不會自動開啟GPU加速，而是由瀏覽器的緩慢的軟件渲染引擎來執(zhí)行。那我們怎樣才可以切換到GPU模式呢，很多瀏覽器提供了某些觸發(fā)的CSS規(guī)則。

translate3d(0,0,0)

rotate3d(0,0,0,0)

scale3d(0,0,0)

translateZ(0)【可能】

只需要在css中使用這類屬性，即可開啟硬件加速

3. 硬件加速真的那么好嗎？

從本人在移動端開發(fā)的實踐來看，硬件加速是比較坑的。開啟硬件加速會占有手機過多的內(nèi)存而導致手機卡頓（這個時候頁面也肯定卡頓了），因此在我們團隊中，是禁止掉硬件加速的。

具體的原理可以參考鏈接5

做完這個任務之后， 才覺得自己真正是在做開發(fā)。嚴謹細致的工匠精神，把控好自己的每一行代碼。面對復雜的問題，一步步分析情況，查閱資料，不斷地debug，感覺提高不少。希望自己繼續(xù)加油，也與抽空看這篇文章的你共勉。

http://frontenddev.org/link/the-timeline-panel-of-the-chrome-developer-tools.html#heading-1-2

https://segmentfault.com/a/1190000003991459

http://gold.xitu.io/entry/5584c9a2e4b06b8a728fe53d

https://segmentfault.com/a/1190000000490328

http://efe.baidu.com/blog/hardware-accelerated-css-the-nice-vs-the-naughty/