H5动画卡顿优化

最近在做一个H5活动，页面中会有横向滚动通知比赛结果，这个通知循环滚动所有战绩，在IOS上动画正常，但是在Android手机上，部分会出现滚动的动画卡顿现象。

在网上找了很多资料，写动画时注意以下几点：

1. 尽量使用transform实现动画，避免使用height,width,margin,padding,left等；

2. 要求较高时，可以开启浏览器GPU硬件加速：让浏览器在渲染动画时从CPU转向GPU

   webkit-transform: translate3d(0,0,0);
   -moz-transform: translate3d(0,0,0);
   -ms-transform: translate3d(0,0,0);
   -o-transform: translate3d(0,0,0);
   transform: translate3d(0,0,0);
   或
   webkit-transform: translateZ(0);
   -moz-transform: translateZ(0);
   -ms-transform: translateZ(0);
   -o-transform: translateZ(0);
   transform: translateZ(0);
   //值为0并没有真正使用3D效果，但浏览器却因此开启了GPU硬件加速模式。
   //通过开启GPU硬件加速虽然可以提升动画渲染性能或解决一些棘手问题，但使用仍需谨慎，使用前一定要进行严谨的测试，否则它反而会大量占用浏览网页用户的系统资源，尤其是在移动端，肆无忌惮的开启GPU硬件加速会导致大量消耗设备电量，降低电池寿命等问题

3. 如动画过程有闪烁（通常发生在动画开始的时候），可以尝试下面的Hack：

   通过-webkit-transform:transition3d/translateZ开启GPU硬件加速之后，有些时候可能会导致浏览器频繁闪烁或抖动，可以尝试以下办法解决之：
   -webkit-backface-visibility:hidden;
   -webkit-perspective:1000;
   
   即：
   -webkit-backface-visibility: hidden; /*元素旋转时隐藏背面*/
   -moz-backface-visibility: hidden;
   -ms-backface-visibility: hidden;
   backface-visibility: hidden;
     
   -webkit-perspective: 1000;
   -moz-perspective: 1000;
   -ms-perspective: 1000;
   perspective: 1000;
   //-webkit-transform-style: preserve-3d; /*保留3D空间*/
   
   

4. 尽可能少的使用box-shadows与gradients

box-shadows与gradients往往都是页面的性能杀手，尤其是在一个元素同时都使用了它们.

尽可能的让动画元素不在文档流中，以减少重排

position: fixed;
position: absolute;

我们一起来看下CSS3动画其中一些属性性能消耗图：

性能消耗图，由此可见最受欢饮和性能最好的莫过于transform和opacity了

原因：CSS动画属性会触发整个页面的重排relayout、重绘repaint、重组recomposite
Paint通常是其中最花费性能的，尽可能避免使用触发paint的CSS动画属性，这也是为什么我们推荐在CSS动画中使用webkit-transform: translateX(3em)的方案代替使用left: 3em，因为left会额外触发layout与paint，而webkit-transform只触发整个页面composite（这也是为什么推荐在CSS动画中使用webkit-transform: translateX(500px)的方案代替使用left: 500px）；

 

如何监测动画帧速率

推荐两种实时监测网页渲染帧速率的方法：

1.Chrome的DevTool中TimeLine的Frame模块
新版本看

层？重绘？回流和重布局？图层重组？

首先要了解CSS的图层的概念（Chrome浏览器）

浏览器在渲染一个页面时，会将页面分为很多个图层，图层有大有小，每个图层上有一个或多个节点。在渲染DOM的时候，浏览器所做的工作实际上是：
1. 获取DOM后分割为多个图层
2. 对每个图层的节点计算样式结果（Recalculate style--样式重计算）
3. 为每个节点生成图形和位置（Layout--回流和重布局）
4. 将每个节点绘制填充到图层位图中（Paint Setup和Paint--重绘）
5. 图层作为纹理上传至GPU
6. 符合多个图层到页面上生成最终屏幕图像（Composite Layers--图层重组）

Chrome中满足以下任意情况就会创建图层：
* 3D或透视变换（perspective transform）CSS属性
* 使用加速视频解码的<video>节点
* 拥有3D（WebGL）上下文或加速的2D上下文的<canvas>节点
* 混合插件（如Flash）
* 对自己的opacity做CSS动画或使用一个动画webkit变换的元素
* 拥有加速CSS过滤器的元素
* 元素有一个包含复合层的后代节点（一个元素拥有一个子元素，该子元素在自己的层里）
* 元素有一个z-index较低且包含一个复合层的兄弟元素（换句话说就是该元素在复合层上面渲染）

需要注意的是，如果图层中某个元素需要重绘，那么整个图层都需要重绘。比如一个图层包含很多节点，其中有个gif图，gif图的每一帧，都会重回整个图层的其他节点，然后生成最终的图层位图。所以这需要通过特殊的方式来强制gif图属于自己一个图层（translateZ(0)或者translate3d(0,0,0)），CSS3的动画也是一样（好在绝大部分情况浏览器自己会为CSS3动画的节点创建图层）

层和CSS动画

简化一下上述过程，每一帧动画浏览器可能需要做如下工作：
1. 计算需要被加载到节点上的样式结果（Recalculate style--样式重计算）
2. 为每个节点生成图形和位置（Layout--回流和重布局）
3. 将每个节点填充到图层中（Paint Setup和Paint--重绘）
4. 组合图层到页面上（Composite Layers--图层重组）

如果我们需要使得动画的性能提高，需要做的就是减少浏览器在动画运行时所需要做的工作。最好的情况是，改变的属性仅仅印象图层的组合，变换（transform）和透明度（opacity）就属于这种情况

现代浏览器如Chrome，Firefox，Safari和Opera都对变换和透明度采用硬件加速，但IE10+不是很确定是否硬件加速

触发重布局的属性

有些节点，当你改变他时，会需要重新布局（这也意味着需要重新计算其他被影响的节点的位置和大小）。这种情况下，被影响的DOM树越大（可见节点），重绘所需要的时间就会越长，而渲染一帧动画的时间也相应变长。所以需要尽力避免这些属性

一些常用的改变时会触发重布局的属性：
盒子模型相关属性会触发重布局：
* width
* height
* padding
* margin
* display
* border-width
* border
* min-height

定位属性及浮动也会触发重布局：
* top
* bottom
* left
* right
* position
* float
* clear

改变节点内部文字结构也会触发重布局：
* text-align
* overflow-y
* font-weight
* overflow
* font-family
* line-height
* vertival-align
* white-space
* font-size

这么多常用属性都会触发重布局，可以看到，他们的特点就是可能修改整个节点的大小或位置，所以会触发重布局

别使用CSS类名做状态标记

如果在网页中使用CSS的类来对节点做状态标记，当这些节点的状态标记类修改时，将会触发节点的重绘和重布局。所以在节点上使用CSS类来做状态比较是代价很昂贵的

触发重绘的属性

修改时只触发重绘的属性有：
* color
* border-style
* border-radius
* visibility
* text-decoration
* background
* background-image
* background-position
* background-repeat
* background-size
* outline-color
* outline
* outline-style
* outline-width
* box-shadow

这样可以看到，这些属性都不会修改节点的大小和位置，自然不会触发重布局，但是节点内部的渲染效果进行了改变，所以只需要重绘就可以了

手机就算重绘也很慢

在重绘时，这些节点会被加载到GPU中进行重绘，这对移动设备如手机的影响还是很大的。因为CPU不如台式机或笔记本电脑，所以绘画巫妖的时间更长。而且CPU与GPU之间的有较大的带宽限制，所以纹理的上传需要一定时间

触发图层重组的属性

透明度竟然不会触发重绘？

需要注意的是，上面那些触发重绘的属性里面没有opacity（透明度），很奇怪不是吗？实际上透明度的改变后，GPU在绘画时只是简单的降低之前已经画好的纹理的alpha值来达到效果，并不需要整体的重绘。不过这个前提是这个被修改opacity本身必须是一个图层，如果图层下还有其他节点，GPU也会将他们透明化

强迫浏览器创建图层

在Blink和WebKit的浏览器中，一当一个节点被设定了透明度的相关过渡效果或动画时，浏览器会将其作为一个单独的图层，但很多开发者使用translateZ(0)或者translate3d(0,0,0)去使浏览器创建图层。这种方式可以消除在动画开始之前的图层创建时间，使得动画尽快开始（创建图层和绘制图层还是比较慢的），而且不会随着抗锯齿而导出突变。不过这种方法需要节制，否则会因为创建过多的图层导致崩溃

Chrome中的抗锯齿

Chrome中，非根图层以及透明图层使用grayscale antialiasing而不是subpixel antialiasing，如果抗锯齿方法变化，这个效果将会非常显著。如果你打算预处理一个节点而不打算等到动画开始，可以通过这种强迫浏览器创建图层的方式进行。

transform变换是你的选择

我们通过节点的transform可以修改节点的位置、旋转、大小等。我们平常会使用left和top属性来修改节点的位置，但正如上面所述，left和top会触发重布局，修改时的代价相当大。取而代之的更好方法是使用translate，这个不会触发重布局。

JS动画和CSS3动画的比较

我们经常面临一个抉择：是使用JavaScript的动画还是使用CSS的动画，下面将对比一下这两种方式。

JS动画

缺点：JavaScript在浏览器的主线程中运行，而其中还有很多其他需要运行的JavaScript、样式计算、布局、绘制等对其干扰。这也就导致了线程可能出现阻塞，从而造成丢帧的情况。

优点：JavaScript的动画与CSS预先定义好的动画不同，可以在其动画过程中对其进行控制：开始、暂停、回放、中止、取消都是可以做到的。而且一些动画效果，比如视差滚动效果，只有JavaScript能够完成。

CSS动画

缺点：缺乏强大的控制能力。而且很难以有意义的方式结合到一起，使得动画变得复杂且易于出问题。
优点：浏览器可以对动画进行优化。它必要时可以创建图层，然后在主线程之外运行。

前瞻

Google目前正在探究通过JS的多线程（Web Workers）来提供更好的动画效果，而不会触发重布局及样式重计算。

 

浏览器内部

现代的浏览器通常会有两个重要的执行线程，这2个线程协同工作来渲染一个网页：

• 主线程
• 合成线程

一般情况下，主线程负责：

• 运行JavaScript。
• 计算HTML 元素的 CSS 样式。
• 页面的布局
• 将元素绘制到一个或多个位图中
• 将这些位图交给合成线程

相应地，合成线程负责：

• 通过 GPU将位图绘制到屏幕上
• 通知主线程更新页面中可见或即将变成可见的部分的位图
• 计算出页面中哪部分是可见的
• 计算出当你在滚动页面时哪部分是即将变成可见的
• 当你滚动页面时将相应位置的元素移动到可视区域

长时间执行 JavaScript 或渲染一个很大的元素会阻塞主线程，在这期间，它将无法响应用户的交互。

相反，合成线程则会尽量去响应用户的交互。当一个页面发生变化时，合成线程会以每秒60 帧的间隔去不断重绘这个页面，即使这个页面不完整。(小于60肉眼就可以感觉出了，用上面的工具观察FPS，越大越好)

举个例子，当用户滚动页面时，合成线程会通知主线程更新页面中最新可见部分的位图。但是，如果主线程响应地不够快，合成线程不会保持等待，而是马上绘制已经生成的位图，还没准备好的部分用白色进行填充。

GPU

刚才我提到合成线程会使用 GPU将位图绘制到屏幕上，接下来让我们快速了解一下 GPU。

目前，大多数手机、 平板电脑、 和计算机都配备了GPU芯片。它有着非常专业的定位，这意味着GPU非常擅长做某些事情（比如绘图），但在其他方面则没什么优势。

GPU的快在于：

1. 绘制位图到屏幕上
2. 一遍又一遍地绘制相同的位图
3. 将同一位图绘制到不同位置，执行旋转以及缩放处理

GPU 的慢在于：

1. 将位图加载到它的内存中

transition: height

现在，我们已经对渲染页面的软硬件都有一些初步的理解了，接下来让我们来看看浏览器的主线程和合成线程石如何协同工作来执行一个 CSS Transition的。

假设我们要一个元素的height从 100 px 变成 200 px，就像这样：

div {
    height: 100px;
    transition: height 1s linear;
}

div:hover {
    height: 200px;
}

主线程和合成线程将按照下面的流程图执行相应的操作。注意在橘黄色方框的操作可能会比较耗时，在蓝色框中的操作是比较快速的。（译注：懒得重新画图，流程图中的内容略过不译，下同）

正如你所看到，在上图中有很多橘黄色方框，意味着，浏览器需要做大量的工作，也就是说这个动画可能会变得卡顿。

在动画的每一帧中，浏览器都要执行布局、 绘制、 以及将新的位图提交给 GPU。我们知道，将位图加载到 GPU 的内存中是一个相对较慢的操作。

浏览器需要做大量工作的原因在于每一帧中元素的内容都在不断改变。改变一个元素的高度可能导致需要同步改变它的子元素的大小，所以浏览器必须重新计算布局。布局完成后，主线程又必须重新生成该元素的位图。

transition: transform

可以说，height属性的transition是比较消耗性能的，那么有什么更好的方案呢？

假设我们需要将一个元素的尺寸缩小一半，并使用CSS transform属性来完成缩放，使用CSS transition属性来做缩放动画，就像这样：

div {
    transform: scale(0.5);
    transition: transform 1s linear;
}

div:hover {
    transform: scale(1.0);
}

让我们看看这种情况下的流程图：

这次我们可以看到少了很多橙色的方框，意味着动画变得更流畅了！那么，为什么执行一个元素的transform动画会跟height动画表现得不一样呢？

根据定义，CSS 的transform属性不会更改元素或它周围的元素的布局。transform属性会对元素的整体产生影响，它会对整个元素进行缩放、旋转、移动处理。

这对浏览器来说是个好消息 ！浏览器只需要一次生成这个元素的位图，并在动画开始的时候将它提交给GPU去处理 。之后，浏览器不需要再做任何布局、 绘制以及提交位图的操作。从而，浏览器可以充分利用 GPU 的特长去快速地将位图绘制在不同的位置、执行旋转或缩放处理。

 

结论

动画给予了页面丰富的视觉体验。我们应该尽力避免使用会触发重布局和重绘的属性，以免失帧。最好提前申明动画，这样能让浏览器提前对动画进行优化。由于GPU的参与，现在用来做动画的最好属性是如下几个：
* opacity
* translate
* rotate
* scale

也许会有一些新的方式使得可以使用JavaScript做出更好的没有限制的动画，而且不用担心主线程的阻塞问题。但在那之前，还是好好考虑下如何做出流畅的动画吧。

参考：

http://blogs.adobe.com/webplatform/2014/03/18/css-animations-and-transitions-performance/

https://blog.csdn.net/leer168/article/details/25917093

https://www.cnblogs.com/xdoudou/p/4524758.html

http://www.jiangweishan.com/article/CSS3AnimationXingneng.html