[转]Javascript高性能动画与页面渲染

时间 2019-11-20

标签 javascript 高性能动画页面渲染栏目 JavaScript 繁體版

原文原文链接

No setTimeout, No setInterval

做者李光毅发布于 2014年4月30日javascript

若是你不得不使用setTimeout或者setInterval来实现动画，那么缘由只能是你须要精确的控制动画。但我认为至少在如今这个时间点，高级浏览器、甚至手机浏览器的普及程度足够让你有理由有条件在实现动画时使用更高效的方式。css

什么是高效

页面是每一帧变化都是系统绘制出来的(GPU或者CPU)。但这种绘制又和PC游戏的绘制不一样，它的最高绘制频率受限于显示器的刷新频率(而非显卡)，因此大多数状况下最高的绘制频率只能是每秒60帧(frame per second，如下用fps简称)，对应于显示器的60Hz。60fps是一个最理想的状态，在平常对页面性能的测试中，60fps也是一个重要的指标，the closer the better。在Chrome的调试工具中，有很多工具都是用于衡量当前帧数：html

易传媒使用Docker云化的技术实践

京东618大促下的数据驱动个性化推荐

如何构建软硬件结合的人工智能产品研发体系

中国创新型互联网企业走向海外的技术机遇与挑战

LinkedIn成员分类平台大数据应用的最佳实践

垂直同步问题

这里请再容许我引入另外一个常量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所解决的问题。

从上一节咱们能够总结出实现平滑动画的两个因素

时机(Frame Timing)：新的一帧准备好的时机
成本(Frame Budget)：渲染新的一帧须要多长的时间

这个Native API把咱们从纠结于多久刷新的一次的困境中解救出来(其实rAF也不关心距离下次屏幕刷新页面还须要多久)。当咱们调用这个函数的时候，咱们告诉它须要作两件事： 1. 咱们须要新的一帧；2.当你渲染新的一帧时须要执行我传给你的回调函数

那么它解决了咱们上面描述的第一个问题，产生新的一帧的时机。

那么第二个问题呢。不，它无能为力。好比能够对比下面两个页面：

对比两个页面的源码，你会发现只有一处不一样：

// 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，以便节省性能)，并把计算的结果告诉咱们。这一般是性能消耗量大的工做。

但若是咱们并不是当即须要获得结果呢？

上面的代码有两处不足，

更新背景颜色的代码过于提早，根据前一个例子，咱们知道，即便在这里告知了浏览器我须要更新背景颜色，浏览器至少也要等到js运行完毕才能调用UI线程；
假设后面部分的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。浏览器渲染的流程以下：

获取 DOM 并将其分割为多个层(RenderLayer)
将每一个层栅格化，并独立的绘制进位图中
将这些位图做为纹理上传至 GPU
复合多个层来生成最终的屏幕图像(终极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时出现的问题。

参考文章：

感谢王保平对本文的审校。

原文：

http://www.infoq.com/cn/articles/javascript-high-performance-animation-and-page-rendering/