摘要：本文已完結，請看下文求索的動畫快于嗎為何續本文源自對問題動畫性能優于的原理是什么的回答。是這樣的嗎請看下文求索的動畫快于嗎為何續

  
本文已完結，請看下文： > 求索：GSAP的動畫快于jQuery嗎？為何？/續 

本文源自對問題《GSAP js動畫性能優于jQuery的原理是什么？》的回答。GSAP是一個js動畫插件，它聲稱“20x faster than jQuery”，是什么讓它這么快呢？

每當有這樣的問題的時候，我們可以通過以下步驟來確定一個未知的解決方案的性能優化是怎么做到/偽造的：

黑盒：從官方用例來看，究竟有多快，快在哪兒

白盒：看看官方用例之內，框架怎么做到優化的

do { 提出假設，自己構建用例測試 } while (假設沒有得到驗證);

得出結論

文中提到的timer、recalculate、layout、repaint、composite layer，需要瀏覽器內部運行相關的基礎知識。見：

《瀏覽器的渲染原理簡介》

《瀏覽器的工作原理：新式網絡瀏覽器幕后揭秘》

首先我們打開chrome，并開啟官網的H5動畫速度測試頁面：http://www.greensock.com/js/speed.html。

頁面中用js計算出的fps很不準確，還是以瀏覽器的統計為準。

在jQuery和GSAP兩個框架下打開，然后點run，然后f12審查元素，進入Timeline頁面，點record。過了100frame以后暫停，然后進入頁面點擊stop。

以下是jQuery的結果：100幀6.53s，平均FPS：15幀/秒
（也可以自己算出來 100frames ÷ 6.53s ≈ 15.3FPS）

以下是GSAP的結果：100幀2.22s，平均FPS：45幀/秒。比jQuery快2倍呢。

來對比一下100幀里面各個流程的耗時（單位：秒）：

我們來看看前3幀里面兩個框架都發生了什么：

jQuery：

GSAP：

看來GSAP比起jQuery主要的性能優化在下面這兩個類目：

JS：主要是timer，jQuery里面，每幀大概有10~20個timer被觸發（并維持在67ms左右）；GSAP每幀不超過6個timer（并短于30ms）；

渲染：jQuery沒有layout步驟，但是GSAP有，而且每次都影響到整個文檔；jQuery的recalculate步驟，每次僅影響1個元素；而GSAP每次影響到170左右的元素。

GSAP的渲染詳情內容：

jQuery的渲染詳情內容：

這樣看來，timer造成了很大的區別，而渲染部分本應沒有太大區別（layout由于動畫部分是position:absolute，影響范圍不大），但是二者的最終差異也比較大，我們只有通過源碼和用例看到區別了。

先看看測試頁面jQuery和GSAP的用例：

//jQuery
jQuery.easing.cubicIn = $.easing.cubicIn = function( p, n, firstNum, diff ) { //we need to add the standard CubicIn ease to jQuery
   return firstNum + p * p * p * diff;
}
jQuery.fx.interval = 10; //ensures that jQuery refreshes at roughly 100fps like GSAP, TweenJS, and most of the others to be more even/fair.
tests.jquery = {
  milliseconds:true,
  wrapDot:function(dot) {
    return jQuery(dot); //wrap the dot in a jQuery object in order to perform better (that way, we don"t need to query the dom each time we tween - we can just call animate() directly on the jQuery object)
  },
  tween:function(dot) {
    dot[0].style.cssText = startingCSS;
    var angle = Math.random() * Math.PI * 2;
    dot.delay(Math.random() * duration).animate({left:Math.cos(angle) * radius + centerX, 
           top:Math.sin(angle) * radius + centerY, 
           width:32, 
           height:32}, duration, "cubicIn", function() { tests.jquery.tween(dot) });
  },
  stop:function(dot) {
    dot.stop(true);
  },
  nativeSize:false
};

//GSAP (TweenLite) top/left/width/height
tests.gsap = {
  milliseconds:false,
  wrapDot:function(dot) {
    return dot; //no wrapping necessary
  },
  tween:function(dot) {
    var angle = Math.random() * Math.PI * 2;
    dot.style.cssText = startingCSS;
    TweenLite.to(dot, duration, {css:{left:Math.cos(angle) * radius + centerX, 
                      top:Math.sin(angle) * radius + centerY, 
                      width:32, 
                      height:32},
                   delay:Math.random() * duration,
                   ease:Cubic.easeIn,
                   overwrite:"none",
                   onComplete:tests.gsap.tween,
                   onCompleteParams:[dot]});
  },
  stop:function(dot) {
    TweenLite.killTweensOf(dot);
  },
  nativeSize:false
};

function toggleTest() {
   inProgress = !inProgress;
   var i;
   if (inProgress) {
      currentTest = tests[engineInput.value];
      size = (currentTest.nativeSize ? "16px" : "1px");
      centerX = jQuery(window).width() / 2;
      centerY = (jQuery(window).height() / 2) - 30;
      startingCSS = "position:absolute; left:" + centerX + "px; top:"
         + centerY + "px; width:" + size + "; height:" + size + ";"; 
      radius = Math.sqrt(centerX * centerX + centerY * centerY);
      duration = Number(durInput.value);

      createDots();
      i = dots.length;
      while (--i > -1) {
         currentTest.tween(dots[i]);
      }
   }
}

jQuery部分除了時間函數"CubicIn"我們平常用不上以外，其他的部分都符合我們的正常使用習慣。注意到jQuery的jQuery.fx.interval，也就是MsPF（millisecond per frame，我編的單位）被調到了10，換言之，FPS是100。

  
“以讓測試更加公平”，注釋說。
  
  
雪姨：“好大的口氣”
  
  

讓我們接著看源碼……

之前的觀測結果表明：JS部分中，主要是timer：jQuery里面，每幀大概有10~20個timer被觸發，并維持在67ms左右；GSAP每幀不超過6個timer，同時每幀短于30ms。

我在自己的一個空白頁面引用了jQuery的1.10.2的未壓縮版，然后用chrome打開頁面，并在console輸入jQuery.Animation，回車，查看它的定義。并一步步查看其中我覺得有可能會帶我到定時器的函數定義，直到得到結果。

在這個過程中，我知道了，jQuery的Animation采用的定時器是setInterval：

jQuery.Animation = function Animation( elem, properties, options ) {
  // 上部分省略...
  jQuery.fx.timer(
    jQuery.extend( tick, {
      elem: elem,
      anim: animation,
      queue: animation.opts.queue
    })
  );

  // attach callbacks from options
  return animation.progress( animation.opts.progress )
    .done( animation.opts.done, animation.opts.complete )
    .fail( animation.opts.fail )
    .always( animation.opts.always );
}

jQuery.fx.timer = function ( timer ) {
   if ( timer() && jQuery.timers.push( timer ) ) {
      jQuery.fx.start();
   }
} 

jQuery.fx.start = function () {
  if ( !timerId ) {
    timerId = setInterval( jQuery.fx.tick, jQuery.fx.interval );
  }
} 

jQuery.fx.interval = 13;

就算我們不在這個項目里調節jQuery.fx.interval到10，原生的jQuery.fx.interval居然是一13ms/frame，換算成FPS就是77，要知道有一些瀏覽器的繪制上限是60FPS，即1000ms ÷ 60frame ≈ 16.7 ms/frame，這個interval會要求一些瀏覽器在繪制上限內執行1.3次，瀏覽器每隔幾幀會丟棄掉其中的1次，而這就造成了額外的損耗，這也是在上面的現象中jQuery里面timer過分耗時，被喚起的次數在20次左右的原因。

而GSAP沒有猜錯的話，應該是用到requestAnimationFrame(以及低版本IE下的setTimeout作為polyfill)，并盡可能剪短定時器內部內容（jQuery處于兼容性考慮，會做大量條件判斷，這方面自然會敗給GSAP），來壓榨定時器性能的。

我們在源碼中搜requestAnimationFrame，在TweenLite.js中：

/* Ticker
 */
var _reqAnimFrame = window.requestAnimationFrame, 
_cancelAnimFrame = window.cancelAnimationFrame, 
_getTime = Date.now || function() {return new Date().getTime();},
_lastUpdate = _getTime();

//now try to determine the requestAnimationFrame and cancelAnimationFrame functions and if none are found, we"ll use a setTimeout()/clearTimeout() polyfill.
a = ["ms","moz","webkit","o"];
i = a.length;
while (--i > -1 && !_reqAnimFrame) {
  _reqAnimFrame = window[a[i] + "RequestAnimationFrame"];
  _cancelAnimFrame = window[a[i] + "CancelAnimationFrame"] || window[a[i] + "CancelRequestAnimationFrame"];
}

_class("Ticker", function(fps, useRAF) {
  var _self = this,
    _startTime = _getTime(),
    _useRAF = (useRAF !== false && _reqAnimFrame),
    _fps, _req, _id, _gap, _nextTime,
    _tick = function(manual) {
      _lastUpdate = _getTime();
      _self.time = (_lastUpdate - _startTime) / 1000;
      var overlap = _self.time - _nextTime,
        dispatch;
      if (!_fps || overlap > 0 || manual === true) {
        _self.frame++;
        _nextTime += overlap + (overlap >= _gap ? 0.004 : _gap - overlap);
        dispatch = true;
      }
      if (manual !== true) {
        //make sure the request is made before we dispatch the "tick" event so that
        //timing is maintained.
        //Otherwise, if processing the "tick" requires a bunch of time (like 15ms)
        //and we"re using a setTimeout() that"s based on 16.7ms,
        //it"d technically take 31.7ms between frames otherwise.
        _id = _req(_tick);
      }
      if (dispatch) {
        _self.dispatchEvent("tick");
      }
    };
  // ...
  _self.wake = function() {
    if (_id !== null) {
      _self.sleep();
    }
    _req = (_fps === 0) ? _emptyFunc : (!_useRAF || !_reqAnimFrame) ? function(f) { return setTimeout(f, ((_nextTime - _self.time) * 1000 + 1) | 0); } : _reqAnimFrame;
    if (_self === _ticker) {
      _tickerActive = true;
    }
    _tick(2);
  };
}

這段代碼是非常典型的requestAnimationFrame的polyfill。并且在polyfill部分，計算了瀏覽器的繪制上限的時間間隔，也符合我之前的猜測。

之前的觀測結果表明，渲染部分，jQuery沒有layout步驟，但是GSAP有，而且每次都影響到整個文檔；jQuery的recalculate步驟，每次僅影響1個元素；而GSAP每次影響到170左右的元素。

從觀測結果來看，GSAP做的是化零為整，一次性重新布局全部元素的活兒（一次性改變它們的top、left值，甚至有可能是重新替換了一整個DOM內部的全部HTML）。

是這樣嗎？GSAP的源碼太過龐大，我們怎么構造對代碼結構的感性認識呢？

我把官方用例保存到了本地，用的是xxx.htm，這樣會生成一個xxx_files文件夾，里面有所有引用的資源文件。（很有意思，png沒有保存下來）。然后我用沒有壓縮過的源代碼文件替代了TweenLite.min.js和CSSPlugin.min.js。

現在我再生成一次timeline：

這個時候觸發Recalculate style的代碼行數與調用棧非常清晰了。我點進p.setRatio@CSSPlugin.min.js:2066，在當前行新建一個斷點，然后刷新頁面：

調用棧與上下文都出現了，這個時候的源碼是清晰可讀的。上下文是沒有innerHTML或者$.html之類的代碼，我在這里知道，沒有采用一次性刷新innerHTML的方法（事實上，這樣做的代價也很高）。這里每一步改變的都是CSSStyleDeclaration，但這個CSSStyleDeclaration沒有連接到相應元素。

仔細閱讀調用棧每一層的上下文之后，我做出了它分層的依據：

對jQuery的測試用例做同樣的事情，可以看到，在最底端，也就是觸發recalculate的一端，style直接引用的是DOM元素的style。

jQuery.extend.style = function( elem, name, value, extra ) {
  var ret, type, hooks,
    origName = jQuery.camelCase( name ),
    style = elem.style;
  name = jQuery.cssProps[ origName ] || ( jQuery.cssProps[ origName ] = vendorPropName( style, origName ) );
  hooks = jQuery.cssHooks[ name ] || jQuery.cssHooks[ origName ];

  if ( value !== undefined ) {
    //style里面的一大堆判斷省略
    style[ name ] = value;
  }
}

畫出相應的架構：

意識到了嗎，jQuery是過程化的，每個函數/類代表一個需要管理/控制兼容性的需求。

綜上所述，我們得到以下假設：

jQuery的定時器采用的是setInterval，受到瀏覽器重繪上限的控制，而GSAP采用requestAnimationFrame，完全將重繪交給瀏覽器管理，以獲得更好地重繪性能

jQuery每次都是多帶帶修改一個DOM的style，而GSAP是計算離線的style，然后再賦給DOM。這導致了不一樣的時間開銷。

jQuery沒有集中繪制，每個DOM都在一個事件回調函數上下文中處理，有多少個DOM就有多少個上下文；GSAP有集中繪制。同時jQuery是過程化的，GSAP是面向對象的。這讓jQuery非常難以做到集中控制繪制。jQuery會將DOM的引用一路傳遞到最終改變DOM的style函數中，這在調用過程中也會非常浪費空間。這些也都導致了不一樣的時間開銷。

是這樣的嗎？

請看下文： 求索：GSAP的動畫快于jQuery嗎？為何？/續