使用CSS3 will-change提高页面滚动、动画等渲染性能

2015/11/05 · CSS ·
渲染性能

原文出处:
张鑫旭   

四、参考文章

  • Fix scrolling performance with CSS will-change
    property
  • MDN:will-change
  • An Introduction to the CSS will-change
    Property

本文内容均属于外文整理收集,加上自己理解书写。内容并未亲自实践验证,因此,不能保证100%正确,仅供大家学习参考。

如果文中有什么表述不准确的地方,欢迎大力指正,感谢阅读,欢迎交流!

图片 1

本文为原创文章,包含脚本行为,会经常更新知识点以及修正一些错误,因此转载请保留原出处,方便溯源,避免陈旧错误知识的误导,同时有更好的阅读体验。
本文地址:

(本篇完)

CSS3 3D 行星运转动画 + 浏览器渲染原理

2016/04/29 · CSS ·
动画

本文作者: 伯乐在线 –
chokcoco
。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

承接上一篇:《CSS3进阶:酷炫的3D旋转透视》 。

最近入坑 Web 动画,所以把自己的学习过程记录一下分享给大家。

CSS3 3D 行星运转 demo
页面请戳:Demo。(建议使用Chrome打开)

本文完整的代码,以及更多的 CSS3
效果,在我 Github 上可以看到,也希望大家可以点个
star。

嗯,可能有些人打不开 demo
或者页面乱了,贴几张效果图:(图片有点大,耐心等待一会)

CSS3 3D 行星运转效果图

图片 2

随机再截屏了一张:

图片 3

强烈建议你点进
Demo页感受一下
CSS3 3D 的魅力,图片能展现的东西毕竟有限。

然后,这个 CSS3 3D 行星运转动画的制作过程不再详细赘述,本篇的重点放在
Web 动画介绍及性能优化方面。详细的 CSS3 3D
可以回看上一篇博客:《CSS3进阶:酷炫的3D旋转透视》。简单的思路:

  1. 利用上一篇所制作的 3D 照片墙为原型,改造而来;

2.
每一个球体的制作,想了许多方法,最终使用了这种折中的方式,每一个球体本身也是一个
CSS3 3D 图形。然后在制作过程中使用 Sass 编写 CSS 可以减少很多繁琐的编写
CSS 动画的过程;

  1. Demo 当中有使用 Javascript
    写了一个鼠标跟随的监听事件,去掉这个事件,整个行星运动动画本身是纯 CSS
    实现的。

下面将进入本文的重点,从性能优化的角度讲讲浏览器渲染展示原理,浏览器的重绘与重排,动画的性能检测优化等:

 

二、CSS3 will-change粉墨登场

CSS3 will-change属于web标准属性,虽然目前还是草案阶段,但出现已经有些时日了,兼容性这块Chrome/FireFox/Opera都是支持的。

图片 4

这个属性作用很单纯,就是“增强页面渲染性能”。那它是如何增强的呢?

我们可能听听说过,3D
transform会启用GPU加速,例如translate3DscaleZ之类,但是呢,这些属性业界往往称之为hack加速法。我们实际上不需要z轴的变化,但是还是假模假样地声明了,欺骗浏览器,这其实是一种不人道的做法。


GPU即图形处理器,是与处理和绘制图形相关的硬件。GPU是专为执行复杂的数学和几何计算而设计的,可以让CPU从图形处理的任务中解放出来,从而执行其他更多的系统任务,例如,页面的计算与重绘。

will-change则天生为此设计,顾名思意“我要变形了”,礼貌而友好。

几何老师:“同学们注意,我要开始变形了。” 图片 5

哈哈,别笑。真是这样的。

当我们通过某些行为(点击、移动或滚动)触发页面进行大面积绘制的时候,浏览器往往是没有准备的,只能被动使用CPU去计算与重绘,由于没有事先准备,应付渲染够呛,于是掉帧,于是卡顿。而will-change则是真正的行为触发之前告诉浏览器:“浏览器同学,我待会儿就要变形了,你心理和生理上都准备准备”。于是乎,浏览器同学把GPU给拉上了,从容应对即将到来的变形。

这其实很好理解的,对吧,提前预约从容不迫;突然造访手忙脚乱。

MDN上显示该属性语法如下:

CSS

/* 关键字值 */ will-change: auto; will-change: scroll-position;
will-change: contents; will-change: transform; /*
<custom-ident>示例 */ will-change: opacity; /*
<custom-ident>示例 */ will-change: left, top; /*
两个<animateable-feature>示例 */ /* 全局值 */ will-change:
inherit; will-change: initial; will-change: unset;

1
2
3
4
5
6
7
8
9
10
11
12
/* 关键字值 */
will-change: auto;
will-change: scroll-position;
will-change: contents;
will-change: transform;        /* <custom-ident>示例 */
will-change: opacity;          /* <custom-ident>示例 */
will-change: left, top;        /* 两个<animateable-feature>示例 */
 
/* 全局值 */
will-change: inherit;
will-change: initial;
will-change: unset;

其中:
auto
就跟width:auto一样,实际上没什么卵用,昨天嘛,估计就是用来重置其他比较屌的值。

scroll-position
告诉浏览器,我要开始翻滚了。

contents
告诉浏览器,内容要动画或变化了。

<custom-ident>
顾名思意,自定义的识别。非规范称呼,应该是MDN自己的称呼,以后可能会明确写入规范。比方说animation的名称,计数器counter-reset,counter-increment定义的名称等等。

上面展示了2个例子,一个是transform一个是opacity,都是CSS3动画常用属性。如果给定的属性是缩写,则所有缩写相关属性变化都会触发。同时不能是以下这些关键字值:unsetinitialinheritwill-changeautoscroll-position,
或 contents.

<animateable-feature>
可动画的一些特征值。比方说lefttopmargin之类。移动端,非transformopacity属性的动画性能都是低下的,所以都是建议避免使用left/top/margin之流进行唯一等。但是,如果你觉得自己是margin属性奶大的,非要使用之,试试加个will-change:margin说不定也会很流畅(移动端目前支持还不是很好)。

就目前而言,使用的基本上都是:

CSS

.example { will-change: transform; }

1
2
3
.example {
  will-change: transform;
}

一、先来看一个例子

下面这个例子来自某外文,我这里简单转述下。

视差滚动现在不是挺流行的嘛,然后Chris
Ruppel当其使用background-attachment: fixed实现背景图片不随滚动条滚动而滚动效果的时候,发现,页面的绘制性能掉到了每秒30帧,这种帧频人眼已经可以感觉到一定的顿挫感了。

图片 6

后来,参考一些其他同事还是同行的建议,做了一番优化,然后,页面的渲染性能——

图片 7

这优化之前完全就是便秘,屎拉不出来的感觉;而优化之后,完全就是一泻千里,裤子都来不及脱的感觉。

一兄得便秘,在厕所里久久不能如便。
正在他极力努力的时候,看一哥们风一样的冲进厕所,进了他旁边的位置,刚进去就传来一真狂风暴雨,那兄羡慕的对那哥们说:哥们好羡慕你呀!
那哥们说:羡慕啥,裤子还没脱呢。。。

大家肯定会好奇,这到底施了什么魔法,可以让渲染提升如此之显著。3个小tips:

  1. background-attachment: fixed改成了position: fixed,因为前面这玩意滚动实时计算重绘;
  2. 背景图片所在的元素替换为::before伪元素;
  3. 使用了CSS3 will-change加速;

相关代码如下(假设类名是front):

.front::before {
    content: '';
    position: fixed; // 代替background-attachment
    width: 100%;
    height: 100%;
    top: 0;
    left: 0;
    background-color: white;
    background: url(/img/front/mm.jpg) no-repeat center center;
    background-size: cover;
    will-change: transform; // 创建新的渲染层
    z-index: -1;
  }

OK, 主角粉墨登场了,就是will-change, 这是什么鬼?

浏览器渲染展示原理 及 对web动画的影响

小标题起得有点大,我们知道,不同浏览器的内核(渲染引擎,Rendering
Engine)是不一样的,例如现在最主流的 chrome 浏览器的内核是 Blink
内核(在Chrome(28及往后版本)、Opera(15及往后版本)和Yandex浏览器中使用),火狐是
Gecko,IE 是 Trident
,浏览器内核负责对网页语法的解释并渲染(显示)网页,不同浏览器内核的工作原理并不完全一致。

所以其实下面将主要讨论的是 chrome 浏览器下的渲染原理。因为 chrome
内核渲染可查证的资料较多,对于其他内核的浏览器不敢妄下定论,所以下面展开的讨论默认是针对
chrome 浏览器的。

首先,我要抛出一点结论:

使用 transform3d api 代替 transform api,强制开始 GPU 加速

这里谈到了 GPU 加速,为什么 GPU 能够加速 3D
变换?这一切又必须要从浏览器底层的渲染讲起,浏览器渲染展示网页的过程,老生常谈,面试必问,大致分为:

    1. 解析HTML(HTML Parser)
    1. 构建DOM树(DOM Tree)
    1. 渲染树构建(Render Tree)
    1. 绘制渲染树(Painting)

找到了一张很经典的图:

图片 8

这个渲染过程作为一个基础知识,继续往下深入。

当页面加载并解析完毕后,它在浏览器内代表了一个大家十分熟悉的结构:DOM(Document
Object
Model,文档对象模型)。在浏览器渲染一个页面时,它使用了许多没有暴露给开发者的中间表现形式,其中最重要的结构便是层(layer)。

这个层就是本文重点要讨论的内容:

而在 Chrome 中,存在有不同类型的层: RenderLayer(负责 DOM
子树),GraphicsLayer(负责 RenderLayer
的子树)。接下来我们所讨论的将是 GraphicsLayer 层。

GraphicsLayer 层是作为纹理(texture)上传给 GPU 的。

这里这个纹理很重要,那么,

什么是纹理(texture)

这里的纹理指的是 GPU 的一个术语:可以把它想象成一个从主存储器(例如
RAM)移动到图像存储器(例如 GPU 中的 VRAM)的位图图像(bitmap
image)。一旦它被移动到 GPU 中,你可以将它匹配成一个网格几何体(mesh
geometry),在 Chrome 中使用纹理来从 GPU
上获得大块的页面内容。通过将纹理应用到一个非常简单的矩形网格就能很容易匹配不同的位置(position)和变形(transformation),这也就是
3D CSS 的工作原理。

说起来很难懂,直接看例子,在 chrome 中,我们是可以看到上文所述的
GraphicsLayer — 层的概念。在开发者工具中,我们进行如下选择调出 show
layer borders 选项:

图片 9

在一个极简单的页面,我们可以看到如下所示,这个页面只有一个层。蓝色网格表示瓦片(tile),你可以把它们当作是层的单元(并不是层),Chrome
可以将它们作为一个大层的部分上传给 GPU:

图片 10

元素自身层的创建

因为上面的页面十分简单,所以并没有产生层,但是在很复杂的页面中,譬如我们给元素设置一个
3D CSS 属性来变换它,我们就能看到当元素拥有自己的层时是什么样子。

注意橘黄色的边框,它画出了该视图中层的轮廓:

图片 11

 

何时触发创建层 ?

上面示意图中黄色边框框住的层,就是 GraphicsLayer ,它对于我们的 Web
动画而言非常重要,通常,Chrome 会将一个层的内容在作为纹理上传到 GPU
前先绘制(paint)进一个位图中。如果内容不会改变,那么就没有必要重绘(repaint)层。

这样做的意义在于:花在重绘上的时间可以用来做别的事情,例如运行
JavaScript,如果绘制的时间很长,还会造成动画的故障与延迟。

那么一个元素什么时候会触发创建一个层?从目前来说,满足以下任意情况便会创建层:

  • 3D 或透视变换(perspective、transform) CSS 属性
  • 使用加速视频解码的 <video> 元素
  • 拥有 3D (WebGL) 上下文或加速的 2D 上下文的 <canvas> 元素
  • 混合插件(如 Flash)
  • 对自己的 opacity 做 CSS 动画或使用一个动画变换的元素
  • 拥有加速 CSS 过滤器的元素
  • 元素有一个包含复合层的后代节点(换句话说,就是一个元素拥有一个子元素,该子元素在自己的层里)
  • 元素有一个 z-index
    较低且包含一个复合层的兄弟元素(换句话说就是该元素在复合层上面渲染)

层的重绘

对于静态 Web 页面而言,层在第一次被绘制出来之后将不会被改变,但对于 Web
动画,页面的 DOM
元素是在不断变换的,如果层的内容在变换过程中发生了改变,那么层将会被重绘(repaint)。

强大的 chrome
开发者工具提供了工具让我们可以查看到动画页面运行中,哪些内容被重新绘制了:

图片 12

在旧版的 chrome 中,是有 show paint rects
这一个选项的,可以查看页面有哪些层被重绘了,并以红色边框标识出来。

但是新版的 chrome 貌似把这个选项移除了,现在的选项是 enable paint
flashing ,其作用也是标识出网站动态变换的地方,并且以绿色边框标识出来。

看上面的示意图,可以看到页面中有几处绿色的框,表示发生了重绘。注意
Chrome 并不会始终重绘整个层,它会尝试智能的去重绘 DOM 中失效的部分。

按照道理,页面发生这么多动画,重绘应该很频繁才对,但是上图我的行星动画中我只看到了寥寥绿色重绘框,我的个人理解是,一是
GPU 优化,二是如果整个动画页面只有一个层,那么运用了 transform
进行变换,页面必然需要重绘,但是采用分层(GraphicsLayer )技术,也就是上面说符合情况的元素各自创建层,那么一个元素所创建的层运用
transform 变换,譬如 rotate
旋转,这个时候该层的旋转变换并没有影响到其他层,那么该层不一定需要被重绘。(个人之见,还请提出指正)。

了解层的重绘对 Web 动画的性能优化至关重要。

是什么原因导致失效(invalidation)进而强制重绘的呢?这个问题很难详尽回答,因为存在大量导致边界失效的情况。最常见的情况就是通过操作
CSS 样式来修改 DOM 或导致重排。

查找引发重绘和重排根源的最好办法就是使用开发者工具的时间轴和 enable
paint flashing 工具,然后试着找出恰好在重绘/重排前修改了 DOM 的地方。

总结

那么浏览器是如何从 DOM 元素到最终动画的展示呢?

  • 浏览器解析 HTML 获取 DOM 后分割为多个图层(GraphicsLayer)
  • 对每个图层的节点计算样式结果(Recalculate style–样式重计算)
  • 为每个节点生成图形和位置(Layout–回流和重布局)
  • 将每个节点绘制填充到图层位图中(Paint Setup和Paint–重绘)
  • 图层作为纹理(texture)上传至 GPU
  • 符合多个图层到页面上生成最终屏幕图像(Composite Layers–图层重组)

Web
动画很大一部分开销在于层的重绘,以层为基础的复合模型对渲染性能有着深远的影响。当不需要绘制时,复合操作的开销可以忽略不计,因此在试着调试渲染性能问题时,首要目标就是要避免层的重绘。那么这就给动画的性能优化提供了方向,减少元素的重绘与回流。

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注