最近在研究頁面渲染及web動(dòng)畫的性能問題，以及拜讀《CSS SECRET》（CSS揭秘）這本大作。
　　本文主要想談?wù)勴撁鎯?yōu)化之滾動(dòng)優(yōu)化。
　　主要內(nèi)容包括了為何需要優(yōu)化滾動(dòng)事件，滾動(dòng)與頁面渲染的關(guān)系，節(jié)流與防抖，pointer-events:none 優(yōu)化滾動(dòng)。因?yàn)楸疚纳婕傲撕芏嗪芏嗷A(chǔ)，是我自己學(xué)習(xí)記錄的一個(gè)過程，如果上面列出的知識(shí)點(diǎn)都了然于胸了，就可以不必往下看了。
　　滾動(dòng)優(yōu)化的由來
　　滾動(dòng)優(yōu)化其實(shí)也不僅僅指滾動(dòng)（scroll 事件），還包括了例如 resize 這類會(huì)頻繁觸發(fā)的事件。簡單的看看：
var i = 0;
window.addEventListener('scroll',function(){
 console.log(i++);
},false);
　　在綁定 scroll 、resize這類事件時(shí)，當(dāng)它發(fā)生時(shí)，它被觸發(fā)的頻次非常高，間隔很近。如果事件中涉及到大量的位置計(jì)算、DOM 操作、元素重繪等工作且這些工作無法在下一個(gè) scroll 事件觸發(fā)前完成，就會(huì)造成瀏覽器掉幀。加之用戶鼠標(biāo)滾動(dòng)往往是連續(xù)的，就會(huì)持續(xù)觸發(fā) scroll 事件導(dǎo)致掉幀擴(kuò)大、瀏覽器CPU使用率增加、用戶體驗(yàn)受到影響。
　　在滾動(dòng)事件中綁定回調(diào)應(yīng)用場景也非常多，在圖片的懶加載、下滑自動(dòng)加載數(shù)據(jù)、側(cè)邊浮動(dòng)導(dǎo)航欄等中有著廣泛的應(yīng)用。
　　當(dāng)用戶瀏覽網(wǎng)頁時(shí)，擁有平滑滾動(dòng)經(jīng)常是被忽視但卻是用戶體驗(yàn)中至關(guān)重要的部分。當(dāng)滾動(dòng)表現(xiàn)正常時(shí)，用戶就會(huì)感覺應(yīng)用十分流暢，令人愉悅，反之，笨重不自然卡頓的滾動(dòng)，則會(huì)給用戶帶來極大不舒爽的感覺。
　　滾動(dòng)與頁面渲染的關(guān)系
　　為什么滾動(dòng)事件需要去優(yōu)化？因?yàn)樗绊懥诵阅堋Ｄ撬绊懥耸裁葱阅苣?？這個(gè)就要從頁面性能問題由什么決定說起。
　　我覺得搞技術(shù)一定要追本溯源，不要看到別人一篇文章說滾動(dòng)事件會(huì)導(dǎo)致卡頓并說了一堆解決方案優(yōu)化技巧就如獲至寶奉為圭臬，我們需要的不是拿來主義而是批判主義，多去源頭看看。
　　從問題出發(fā)，一步一步尋找到最后，就很容易找到問題的癥結(jié)所在，只有這樣得出的解決方法才容易記住。
　　說教了一堆廢話，不喜歡的直接忽略哈，回到正題，要找到優(yōu)化的入口就要知道問題出在哪里，對于頁面優(yōu)化而言，那么我們就要知道頁面的渲染原理：
　　瀏覽器渲染原理我在我上一篇文章里也要詳細(xì)的講到，不過更多的是從動(dòng)畫渲染的角度去講的：【W(wǎng)eb動(dòng)畫】CSS3 3D 行星運(yùn)轉(zhuǎn)  瀏覽器渲染原理 。
　　想了想，還是再簡單的描述下，我發(fā)現(xiàn)每次 review 這些知識(shí)點(diǎn)都有新的收獲，這次換一張圖，以chrome為例子，一個(gè)Web頁面的展示，簡單來說可以認(rèn)為經(jīng)歷了以下下幾個(gè)步驟：
　　JavaScript：一般來說，我們會(huì)使用JavaScript來實(shí)現(xiàn)一些視覺變化的效果。比如做一個(gè)動(dòng)畫或者往頁面里添加一些DOM元素等。
　　Style：計(jì)算樣式，這個(gè)過程是根據(jù)CSS選擇器，對每個(gè)DOM元素匹配對應(yīng)的CSS樣式。這一步結(jié)束之后，就確定了每個(gè)DOM元素上該應(yīng)用什么CSS樣式規(guī)則。
　　Layout：布局，上一步確定了每個(gè)DOM元素的樣式規(guī)則，這一步就是具體計(jì)算每個(gè)DOM元素最終在屏幕上顯示的大小和位置。web 頁面中元素的布局是相對的，因此一個(gè)元素的布局發(fā)生變化，會(huì)聯(lián)動(dòng)地引發(fā)其他元素的布局發(fā)生變化。比如，元素的寬度的變化會(huì)影響其子元素的寬度，其子元素寬度的變化也會(huì)繼續(xù)對其孫子元素產(chǎn)生影響。因此對于瀏覽器來說，布局過程是經(jīng)常發(fā)生的。
　　Paint：繪制，本質(zhì)上就是填充像素的過程。包括繪制文字、顏色、圖像、邊框和陰影等，也就是一個(gè)DOM元素所有的可視效果。一般來說，這個(gè)繪制過程是在多個(gè)層上完成的。
　　Composite：渲染層合并，由上一步可知，對頁面中DOM元素的繪制是在多個(gè)層上進(jìn)行的。在每個(gè)層上完成繪制過程之后，瀏覽器會(huì)將所有層按照合理的順序合并成一個(gè)圖層，然后顯示在屏幕上。對于有位置重疊的元素的頁面，這個(gè)過程尤其重要，因?yàn)橐坏﹫D層的合并順序出錯(cuò)，將會(huì)導(dǎo)致元素顯示異常。
　　這里又涉及了層（GraphicsLayer）的概念，GraphicsLayer 層是作為紋理(texture)上傳給GPU的，現(xiàn)在經(jīng)常能看到說GPU硬件加速，就和所謂的層的概念密切相關(guān)。但是和本文的滾動(dòng)優(yōu)化相關(guān)性不大，有興趣深入了解的可以自行 google 更多。
　　簡單來說，網(wǎng)頁生成的時(shí)候，至少會(huì)渲染（Layout+Paint）一次。用戶訪問的過程中，還會(huì)不斷重新的重排（reflow）和重繪（repaint）。
　　其中，用戶 scroll 和 resize 行為（即是滑動(dòng)頁面和改變窗口大小）會(huì)導(dǎo)致頁面不斷的重新渲染。
　　當(dāng)你滾動(dòng)頁面時(shí)，瀏覽器可能會(huì)需要繪制這些層(有時(shí)也被稱為合成層)里的一些像素。通過元素分組，當(dāng)某個(gè)層的內(nèi)容改變時(shí)，我們只需要更新該層的結(jié)構(gòu)，并僅僅重繪和柵格化渲染層結(jié)構(gòu)里變化的那一部分，而無需完全重繪。顯然，如果當(dāng)你滾動(dòng)時(shí)，像視差網(wǎng)站(戳我看看)這樣有東西在移動(dòng)時(shí)，有可能在多層導(dǎo)致大面積的內(nèi)容調(diào)整，這會(huì)導(dǎo)致大量的繪制工作。
　　防抖（Debouncing）和節(jié)流（Throttling）
　　scroll事件本身會(huì)觸發(fā)頁面的重新渲染，同時(shí)scroll事件的handler又會(huì)被高頻度的觸發(fā), 因此事件的handler內(nèi)部不應(yīng)該有復(fù)雜操作，例如DOM操作就不應(yīng)該放在事件處理中。
　　針對此類高頻度觸發(fā)事件問題（例如頁面scroll，屏幕resize，監(jiān)聽用戶輸入等），下面介紹兩種常用的解決方法，防抖和節(jié)流。
　　防抖（Debouncing）
　　防抖技術(shù)即是可以把多個(gè)順序地調(diào)用合并成一次，也就是在一定時(shí)間內(nèi)，規(guī)定事件被觸發(fā)的次數(shù)。
　　通俗一點(diǎn)來說，看看下面這個(gè)簡化的例子：
// 簡單的防抖動(dòng)函數(shù)
function debounce(func, wait, immediate) {
// 定時(shí)器變量
 var timeout;
　return function() {
// 每次觸發(fā) scroll handler 時(shí)先清除定時(shí)器
　 clearTimeout(timeout);
// 指定 xx ms 后觸發(fā)真正想進(jìn)行的操作 handler<br/　 timeout = setTimeout(func, wait);
　 };
};
// 實(shí)際想綁定在 scroll 事件上的 handler
function realFunc(){
　 console.log("Success");
}
// 采用了防抖動(dòng)
window.addEventListener('scroll',debounce(realFunc,500));
// 沒采用防抖動(dòng)
window.addEventListener('scroll',realFunc);
　　上面簡單的防抖的例子可以拿到瀏覽器下試一下，大概功能就是如果 500ms 內(nèi)沒有連續(xù)觸發(fā)兩次 scroll 事件，那么才會(huì)觸發(fā)我們真正想在 scroll 事件中觸發(fā)的函數(shù)。
　　上面的示例可以更好的封裝一下：
// 防抖動(dòng)函數(shù)
function debounce(func, wait, immediate) {
　 return function() {
　 var context = this, args = arguments;
　 var later = function() {
　 timeout = null;
　 if (!immediate) func.apply(context, args);
　 };
　 var callNow = immediate　!timeout;
　 clearTimeout(timeout);
　 timeout = setTimeout(later, wait);
　 if (callNow) func.apply(context, args);
　 };
};
　
var myEfficientFn = debounce(function() {
// 滾動(dòng)中的真正的操作
}, 250);
// 綁定監(jiān)聽
window.addEventListener('resize', myEfficientFn);
　　節(jié)流（Throttling）
　　防抖函數(shù)確實(shí)不錯(cuò)，但是也存在問題，譬如圖片的懶加載，我希望在下滑過程中圖片不斷的被加載出來，而不是只有當(dāng)我停止下滑時(shí)候，圖片才被加載出來。又或者下滑時(shí)候的數(shù)據(jù)的 ajax 請求加載也是同理。
　　這個(gè)時(shí)候，我們希望即使頁面在不斷被滾動(dòng)，但是滾動(dòng) handler 也可以以一定的頻率被觸發(fā)（譬如 250ms 觸發(fā)一次），這類場景，就要用到另一種技巧，稱為節(jié)流函數(shù)（throttling）。
　　節(jié)流函數(shù)，只允許一個(gè)函數(shù)在 X 毫秒內(nèi)執(zhí)行一次，只有當(dāng)上一次函數(shù)執(zhí)行后過了你規(guī)定的時(shí)間間隔，才能進(jìn)行下一次該函數(shù)的調(diào)用。
　　與防抖相比，節(jié)流函數(shù)最主要的不同在于它保證在 X 毫秒內(nèi)至少執(zhí)行一次我們希望觸發(fā)的事件 handler。
　　與防抖相比，節(jié)流函數(shù)多了一個(gè) mustRun 屬性，代表 mustRun 毫秒內(nèi)，必然會(huì)觸發(fā)一次 handler ，同樣是利用定時(shí)器，看看　　簡單的示例：
// 簡單的節(jié)流函數(shù)
function throttle(func, wait, mustRun) {
　var timeout,
　 startTime = new Date();
　 return function() {
　 var context = this,
　 args = arguments,
　 curTime = new Date();
　 clearTimeout(timeout);
　// 如果達(dá)到了規(guī)定的觸發(fā)時(shí)間間隔，觸發(fā) handler
　 if(curTime - startTime >= mustRun){
　func.apply(context,args);
　startTime = curTime;
// 沒達(dá)到觸發(fā)間隔，重新設(shè)定定時(shí)器
}else{
timeout = setTimeout(func, wait);
}
};
};
// 實(shí)際想綁定在 scroll 事件上的 handler
function realFunc(){
console.log("Success");
}
// 采用了節(jié)流函數(shù)
window.addEventListener('scroll',throttle(realFunc,500,1000));
　　上面簡單的節(jié)流函數(shù)的例子可以拿到瀏覽器下試一下，大概功能就是如果在一段時(shí)間內(nèi)scroll觸發(fā)的間隔一直短于500ms，那么能保證事件我們希望調(diào)用的handler至少在1000ms內(nèi)會(huì)觸發(fā)一次。