Javascript高效能動畫與頁面渲染

No setTimeout, No setInterval

如果你不得不使用setTimeout或者setInterval來實現動畫，那麼原因只能是你需要精確的控制動畫。但我認為至少在現在這個時間點，高階瀏覽器、甚至手機瀏覽器的普及程度足夠讓你有理由有條件在實現動畫時使用更高效的方式。

什麼是高效

頁面是每一幀變化都是系統繪製出來的(GPU或者CPU)。但這種繪製又和PC遊戲的繪製不同，它的最高繪製頻率受限於顯示器的重新整理頻率(而非顯示卡)，所以大多數情況下最高的繪製頻率只能是每秒60幀(frame per second，以下用fps簡稱)，對應於顯示器的60Hz。60fps是一個最理想的狀態，在日常對頁面效能的測試中，60fps也是一個重要的指標，the closer the better。在Chrome的除錯工具中，有不少工具都是用於衡量當前幀數：

接下來的工作中，我們將會用到這些工具，來實時檢視我們頁面的效能。

60fps是動力也是壓力，因為它意味著我們只有16.7毫秒(1000 / 60)來繪製每一幀。如果使用setTimeout或者setInterval(以下統稱為timer)來控制繪製，問題就來了。

首先，Timer計算延時的精確度不夠。延時的計算依靠的是瀏覽器的內建時鐘，而時鐘的精確度又取決於時鐘更新的頻率(Timer resolution)。IE8及其之前的IE版本更新間隔為15.6毫秒。假設你設定的setTimeout延遲為16.7ms，那麼它要更新兩個15.6毫秒才會該觸發延時。這也意味著無故延遲了 15.6 x 2 – 16.7 = 14.5毫秒。

            16.7ms
DELAY: |------------|

CLOCK: |----------|----------|
          15.6ms    15.6ms

所以即使你給setTimeout設定的延時為0ms，它也不會立即觸發。目前Chrome與IE9+瀏覽器的更新頻率都為4ms(如果你使用的是膝上型電腦，並且在使用電池而非電源的模式下，為了節省資源，瀏覽器會將更新頻率切換至於系統時間相同，也就意味著更新頻率更低)。

退一步說，假使timer resolution能夠達到16.7ms，它還要面臨一個非同步佇列的問題。因為非同步的關係setTimeout中的回撥函式並非立即執行，而是需要加入等待佇列中。但問題是，如果在等待延遲觸發的過程中，有新的同步指令碼需要執行，那麼同步指令碼不會排在timer的回撥之後，而是立即執行，比如下面這段程式碼：

function runForSeconds(s) {
    var start = +new Date();
    while (start + s * 1000 > (+new Date())) {}
}

document.body.addEventListener("click", function () {
    runForSeconds(10);
}, false);

setTimeout(function () {
    console.log("Done!");
}, 1000 * 3);

如果在等待觸發延遲的3秒過程中，有人點選了body，那麼回撥還是準時在3s完成時觸發嗎？當然不能，它會等待10s，同步函式總是優先於非同步函式：

等待3秒延遲 |    1s    |    2s    |    3s    |--->console.log("Done!");

經過2秒     |----1s----|----2s----|          |--->console.log("Done!");

點選body後

以為是這樣：|----1s----|----2s----|----3s----|--->console.log("Done!")--->|------------------10s----------------|

其實是這樣：|----1s----|----2s----|------------------10s----------------|--->console.log("Done!");

John Resign有三篇關於Timer效能與準確性的文章: 1.Accuracy of JavaScript Time, 2.Analyzing Timer Performance， 3.How JavaScript Timers Work。從文章中可以看到Timer在不同平臺瀏覽器與作業系統下的一些問題。

再退一步說，假設timer resolution能夠達到16.7ms，並且假設非同步函式不會被延後，使用timer控制的動畫還是有不盡如人意的地方。這也就是下一節要說的問題。

垂直同步問題

這裡請再允許我引入另一個常量60——螢幕的重新整理率60Hz。

60Hz和60fps有什麼關係？沒有任何關係。fps代表GPU渲染畫面的頻率，Hz代表顯示器重新整理螢幕的頻率。一幅靜態圖片，你可以說這副圖片的fps是0幀/秒，但絕對不能說此時螢幕的重新整理率是0Hz，也就是說重新整理率不隨影像內容的變化而變化。遊戲也好瀏覽器也好，我們談到掉幀，是指GPU渲染畫面頻率降低。比如跌落到30fps甚至20fps，但因為視覺暫留原理，我們看到的畫面仍然是運動和連貫的。

接上一節，我們假設每一次timer都不會有延時，也不會被同步函式干擾，甚至能把時間縮短至16ms，那麼會發生什麼呢：

(點選影像放大)

在22秒處發生了丟幀

如果把延遲時間縮的更短，丟失的幀數也就更多：

實際情況會比以上想象的複雜的多。即使你能給出一個固定的延時，解決60Hz螢幕下丟幀問題，那麼其他重新整理頻率的顯示器應該怎麼辦，要知道不同裝置、甚至相同裝置在不同電池狀態下的螢幕重新整理率都不盡相同。

以上同時還忽略了螢幕重新整理畫面的時間成本。問題產生於GPU渲染畫面的頻率和螢幕重新整理頻率的不一致：如果GPU渲染出一幀畫面的時間比顯示器重新整理一張畫面的時間要短(更快)，那麼當顯示器還沒有重新整理完一張圖片時，GPU渲染出的另一張圖片已經送達並覆蓋了前一張，導致螢幕上畫面的撕裂，也就是是上半部分是前一張圖片，下半部分是後一張圖片：

PC遊戲中解決這個問題的方法是開啟垂直同步(v-sync)，也就是讓GPU妥協，GPU渲染圖片必須在螢幕兩次重新整理之間，且必須等待螢幕發出的垂直同步訊號。但這樣同樣也是要付出代價的：降低了GPU的輸出頻率，也就降低了畫面的幀數。以至於你在玩需要高幀數執行的遊戲時(比如競速、第一人稱射擊)感覺到“頓卡”，因為掉幀。

requestAnimationFrame

在這裡不談requestAnimationFrame(以下簡稱rAF)用法，具體請參考MDN:Window.requestAnimationFrame()。我們來具體談談rAF所解決的問題。

從上一節我們可以總結出實現平滑動畫的兩個因素

1. 時機(Frame Timing)： 新的一幀準備好的時機
2. 成本(Frame Budget)： 渲染新的一幀需要多長的時間

這個Native API把我們從糾結於多久重新整理的一次的困境中解救出來(其實rAF也不關心距離下次螢幕重新整理頁面還需要多久)。當我們呼叫這個函式的時候，我們告訴它需要做兩件事： 1. 我們需要新的一幀；2.當你渲染新的一幀時需要執行我傳給你的回撥函式

那麼它解決了我們上面描述的第一個問題，產生新的一幀的時機。

那麼第二個問題呢。不，它無能為力。比如可以對比下面兩個頁面：

1. DEMO
2. DEMO-FIXED

對比兩個頁面的原始碼，你會發現只有一處不同：

// animation loop
function update(timestamp) {
    for(var m = 0; m < movers.length; m++) {
        // DEMO 版本
        //movers[m].style.left = ((Math.sin(movers[m].offsetTop + timestamp/1000)+1) * 500) + 'px';

        // FIXED 版本
        movers[m].style.left = ((Math.sin(m + timestamp/1000)+1) * 500) + 'px';
        }
    rAF(update);
};
rAF(update);

DEMO版本之所以慢的原因是，在修改每一個物體的left值時，會請求這個物體的offsetTop值。這是一個非常耗時的reflow操作(具體還有哪些耗時的reflow操作可以參考這篇: How (not) to trigger a layout in WebKit)。這一點從Chrome除錯工具中可以看出來(截圖中的某些功能需要在Chrome canary版本中才可啟用)

未矯正的版本

可見大部分時間都花在了rendering上，而矯正之後的版本：

rendering時間大大減少了

但如果你的回撥函式耗時真的很嚴重，rAF還是可以為你做一些什麼的。比如當它發現無法維持60fps的頻率時，它會把頻率降低到30fps，至少能夠保持幀數的穩定，保持動畫的連貫。

使用rAF推遲程式碼

沒有什麼是萬能的，面對上面的情況，我們需要對程式碼進行組織和優化。

看看下面這樣一段程式碼：

function jank(second) {
    var start = +new Date();
    while (start + second * 1000 > (+new Date())) {}
}

div.style.backgroundColor = "red";

// some long run task
jank(5);

div.style.backgroundColor = "blue";

無論在任何的瀏覽器中執行上面的程式碼，你都不會看到div變為紅色，頁面通常會在假死5秒，然後容器變為藍色。這是因為瀏覽器的始終只有一個執行緒在執行(可以這麼理解，因為js引擎與UI引擎互斥)。雖然你告訴瀏覽器此時div背景顏色應該為紅色，但是它此時還在執行指令碼，無法呼叫UI執行緒。

有了這個前提，我們接下來看這段程式碼：

var div = document.getElementById("foo");

var currentWidth = div.innerWidth; 
div.style.backgroundColor = "blue";

// do some "long running" task, like sorting data

這個時候我們不僅僅需要更新背景顏色，還需要獲取容器的寬度。可以想象它的執行順序如下：

當我們請求innerWidth一類的屬性時，瀏覽器會以為我們馬上需要，於是它會立即更新容器的樣式(通常瀏覽器會攢著一批，等待時機一次性的repaint，以便節省效能)，並把計算的結果告訴我們。這通常是效能消耗量大的工作。

但如果我們並非立即需要得到結果呢？

上面的程式碼有兩處不足，

1. 更新背景顏色的程式碼過於提前，根據前一個例子，我們知道，即使在這裡告知了瀏覽器我需要更新背景顏色，瀏覽器至少也要等到js執行完畢才能呼叫UI執行緒；
2. 假設後面部分的long runing程式碼會啟動一些非同步程式碼，比如setTimeout或者Ajax請求又或者web-worker，那應該儘早為妙。

綜上所述，如果我們不是那麼迫切的需要知道innerWidth，我們可以使用rAF推遲這部分程式碼的發生：

requestAnimationFrame(function(){
    var el = document.getElementById("foo");

    var currentWidth = el.innerWidth;
    el.style.backgroundColor = "blue";

    // ...
});

// do some "long running" task, like sorting data

可見即使我們在這裡沒有使用到動畫，但仍然可以使用rAF優化我們的程式碼。執行的順序會變成：

在這裡rAF的用法變成了：把程式碼推遲到下一幀執行。

有時候我們需要把程式碼推遲的更遠，比如這個樣子：

再比如我們想要一個效果分兩步執行：1.div的display變為block；2. div的top值縮短移動到某處。如果這兩項操作都放入同一幀中的話，瀏覽器會同時把這兩項更改應用於容器，在同一幀內。於是我們需要兩幀把這兩項操作區分開來：

requestAnimationFrame(function(){
   el.style.display = "block";
   requestAnimationFrame(function(){
      // fire off a CSS transition on its `top` property
      el.style.top = "300px";
   });
});

這樣的寫法好像有些不太講究，Kyle Simpson有一個開源專案h5ive，它把上面的用法封裝了起來，並且提供了API。實現起來非常簡單，摘一段程式碼瞧瞧：

function qID(){
    var id;
    do {
        id = Math.floor(Math.random() * 1E9);
    } while (id in q_ids);
    return id;
}

function queue(cb) {
    var qid = qID();

    q_ids[qid] = rAF(function(){
        delete q_ids[qid];
        cb.apply(publicAPI,arguments);
    });

    return qid;
}

function queueAfter(cb) {
    var qid;

    qid = queue(function(){
        // do our own rAF call here because we want to re-use the same `qid` for both frames
        q_ids[qid] = rAF(function(){
            delete q_ids[qid];
            cb.apply(publicAPI,arguments);
        });
    });

    return qid;
}

使用方法：

// 插入下一幀
id1 = aFrame.queue(function(){
    text = document.createTextNode("##");
    body.appendChild(text);
});

// 插入下下一幀
id2 = aFrame.queueAfter(function(){
    text = document.createTextNode("!!");
    body.appendChild(text);
});

使用rAF解耦程式碼

先從一個2011年twitter遇到的bug說起。

當時twitter加入了一個新功能：“無限滾動”。也就是當頁面滾至底部的時候，去載入更多的twitter：

$(window).bind('scroll', function () {
    if (nearBottomOfPage()) {
        // load more tweets ...
    }
});

但是在這個功能上線之後，發現了一個嚴重的bug：經過幾次滾動到最底部之後，滾動就會變得奇慢無比。

經過排查發現，原來是一條語句引起的：$details.find(“.details-pane-outer”);

這還不是真正的罪魁禍首，真正的原因是因為他們將使用的jQuery類庫從1.4.2升級到了1.4.4版。而這jQuery其中一個重要的升級是把Sizzle的上下文選擇器全部替換為了querySelectorAll。但是這個介面原實現使用的是getElementsByClassName。雖然querySelectorAll在大部分情況下效能還是不錯的。但在通過Class名稱選擇元素這一項是佔了下風。有兩個對比測試可以看出來：1.querySelectorAll v getElementsByClassName 2.jQuery Simple Selector

通過這個bug，John Resig給出了一條(實際上是兩條，但是今天只取與我們話題有關的)非常重要的建議

It’s a very, very, bad idea to attach handlers to the window scroll event.

他想表達的意思是，像scroll，resize這一類的事件會非常頻繁的觸發，如果把太多的程式碼放進這一類的回撥函式中，會延遲頁面的滾動，甚至造成無法響應。所以應該把這一類程式碼分離出來，放在一個timer中，有間隔的去檢查是否滾動，再做適當的處理。比如如下程式碼：

var didScroll = false;

$(window).scroll(function() {
    didScroll = true;
});

setInterval(function() {
    if ( didScroll ) {
        didScroll = false;
        // Check your page position and then
        // Load in more results
    }
}, 250)

這樣的作法類似於Nicholas將需要長時間運算的迴圈分解為“片”來進行運算：

// 具體可以參考他寫的《javascript高階程式設計》
// 也可以參考他的這篇部落格： http://www.nczonline.net/blog/2009/01/13/speed-up-your-javascript-part-1/
function chunk(array, process, context){
    var items = array.concat();   //clone the array
    setTimeout(function(){
        var item = items.shift();
        process.call(context, item);

        if (items.length > 0){
            setTimeout(arguments.callee, 100);
        }
    }, 100);
}

原理其實是一樣的，為了優化效能、為了防止瀏覽器假死，將需要長時間執行的程式碼分解為小段執行，能夠使瀏覽器有時間響應其他的請求。

回到rAF上來，其實rAF也可以完成相同的功能。比如最初的滾動程式碼是這樣：

function onScroll() {
    update();
}

function update() {

    // assume domElements has been declared
    for(var i = 0; i < domElements.length; i++) {

        // read offset of DOM elements
        // to determine visibility - a reflow

        // then apply some CSS classes
        // to the visible items - a repaint

    }
}

window.addEventListener('scroll', onScroll, false);

這是很典型的反例：每一次滾動都需要遍歷所有元素，而且每一次遍歷都會引起reflow和repaint。接下來我們要做的事情就是把這些費時的程式碼從update中解耦出來。

首先我們仍然需要給scroll事件新增回撥函式，用於記錄滾動的情況，以方便其他函式的查詢：

var latestKnownScrollY = 0;

function onScroll() {
    latestKnownScrollY = window.scrollY;
}

接下來把分離出來的repaint或者reflow操作全部放入一個update函式中，並且使用rAF進行呼叫：

function update() {
    requestAnimationFrame(update);

    var currentScrollY = latestKnownScrollY;

    // read offset of DOM elements
    // and compare to the currentScrollY value
    // then apply some CSS classes
    // to the visible items
}

// kick off
requestAnimationFrame(update);

其實解耦的目的已經達到了，但還需要做一些優化，比如不能讓update無限執行下去，需要設標誌位來控制它的執行：

var latestKnownScrollY = 0,
    ticking = false;

function onScroll() {
    latestKnownScrollY = window.scrollY;
    requestTick();
} 

function requestTick() {
    if(!ticking) {
        requestAnimationFrame(update);
    }
    ticking = true;
}

並且我們始終只需要一個rAF例項的存在，也不允許無限次的update下去，於是我們還需要一個出口：

function update() {
    // reset the tick so we can
    // capture the next onScroll
    ticking = false;

    var currentScrollY = latestKnownScrollY;

    // read offset of DOM elements
    // and compare to the currentScrollY value
    // then apply some CSS classes
    // to the visible items
}

// kick off - no longer needed! Woo.
// update();

理解Layer

Kyle Simpson說：

Rule of thumb: don’t do in JS what you can do in CSS.

如以上所說，即使使用rAF，還是會有諸多的不便。我們還有一個選擇是使用css動畫：雖然瀏覽器中UI執行緒與js執行緒是互斥，但這一點對css動畫不成立。

在這裡不聊css動畫的用法。css動畫運用的是什麼原理來提升瀏覽器效能的。

首先我們看看淘寶首頁的焦點圖：

我想提出一個問題，為什麼明明可以使用translate 2d去實現的動畫，它要用3d去實現呢？

我不是淘寶的員工，但我的第一猜測這麼做的原因是為了使用translate3d hack。簡單來說如果你給一個元素新增上了-webkit-transform: translateZ(0);或者-webkit-transform: translate3d(0,0,0);屬性，那麼你就等於告訴了瀏覽器用GPU來渲染該層，與一般的CPU渲染相比，提升了速度和效能。(我很確定這麼做會在Chrome中啟用了硬體加速，但在其他平臺不做保證。就我得到的資料而言，在大多數瀏覽器比如Firefox、Safari也是適用的)。

但這樣的說法其實並不準確，至少在現在的Chrome版本中這算不上一個hack。因為預設渲染所有的網頁時都會經過GPU。那麼這麼做還有必要嗎？有。在理解原理之前，你必須先了解一個層(Layer)的概念。

html在瀏覽器中會被轉化為DOM樹，DOM樹的每一個節點都會轉化為RenderObject, 多個RenderObject可能又會對應一個或多個RenderLayer。瀏覽器渲染的流程如下：

1. 獲取 DOM 並將其分割為多個層(RenderLayer)
2. 將每個層柵格化，並獨立的繪製進點陣圖中
3. 將這些點陣圖作為紋理上傳至 GPU
4. 複合多個層來生成最終的螢幕影像(終極layer)。

這和遊戲中的3D渲染類似，雖然我們看到的是一個立體的人物，但這個人物的皮膚是由不同的圖片“貼”和“拼”上去的。網頁比此還多了一個步驟，雖然最終的網頁是由多個點陣圖層合成的，但我們看到的只是一個影印版，最終只有一個層。當然有的層是無法拼合的，比如flash。以愛奇藝的一個播放頁(http://www.iqiyi.com/v_19rrgyhg0s.html)為例，我們可以利用Chrome的Layer皮膚(預設不啟用，需要手動開啟)檢視頁面上所有的層：

我們可以看到頁面上由如下層組成：

OK，那麼問題來了。

假設我現在想改變一個容器的樣式(可以看做動畫的一個步驟)，並且是一種最糟糕的情況，改變它的長和寬——為什麼說改變長和寬是最糟糕的情況呢。通常改變一個物體的樣式需要以下四個步驟：

任何屬性的改變都導致瀏覽器重新計算容器的樣式，比如你改變的是容器的尺寸或者位置(reflow)，那麼首先影響的就是容器的尺寸和位置(也影響了與它相關的父節點自己點相鄰節點的位置等)，接下來瀏覽器還需要對容器重新繪製(repaint)；但如果你改變的只是容器的背景顏色等無關容器尺寸的屬性，那麼便省去了第一步計算位置的時間。也就是說如果改變屬性在瀑布圖中開始的越早(越往上)，那麼影響就越大，效率就越低。reflow和repaint會導致所有受影響節點所在layer的點陣圖重繪，反覆執行上面的過程，導致效率降低。

為了把代價降到最低，當然最好只留下compositing layer這一個步驟即可。假設當我們改變一個容器的樣式時，影響的只是它自己，並且還無需重繪，直接通過在GPU中改變紋理的屬性來改變樣式，豈不是更好？這當然是可以實現的，前提是你有自己的layer

這也是上面硬體加速hack的原理，也是css動畫的原理——給元素建立自己layer，而非與頁面上大部分的元素共用layer。

什麼樣的元素才能建立自己layer呢？在Chrome中至少要符合以下條件之一：

• Layer has 3D or perspective transform CSS properties(有3D元素的屬性)
• Layer is used by <video> element using accelerated video decoding(video標籤並使用加速視訊解碼)
• Layer is used by a <canvas> element with a 3D context or accelerated 2D context(canvas元素並啟用3D)
• Layer is used for a composited plugin(外掛，比如flash)
• Layer uses a CSS animation for its opacity or uses an animated webkit transform(CSS動畫)
• Layer uses accelerated CSS filters(CSS濾鏡)
• Layer with a composited descendant has information that needs to be in the composited layer tree, such as a clip or reflection(有一個後代元素是獨立的layer)
• Layer has a sibling with a lower z-index which has a compositing layer (in other words the layer is rendered on top of a composited layer)(元素的相鄰元素是獨立layer)

很明顯剛剛我們看到的播放頁中的flash和開啟了translate3d樣式的焦點圖符合上面的條件。

同時你也可以勾選Chrome開發工具中的rendering選顯示卡下的Show composited layer borders 選項。頁面上的layer便會加以邊框區別開來。為了驗證我們的想法，看下面這樣一段程式碼：

<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: skyblue;
  }
  @-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>
</body>
</html>

執行時的timeline截圖如下：

可見元素有自己的layer，並且在動畫的過程中沒有觸發reflow和repaint。

最後再看看淘寶首頁，不僅僅只有焦點圖才擁有了獨立的layer：

但太多的layer也未必是一件好事情，有興趣的同學可以看一看這篇文章：Jank Busting Apple’s Home Page。看一看在蘋果首頁太多layer時出現的問題。