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