记一次序列帧动画预渲染解决方案

发表于 2年以前 | 总阅读数：614 次

背景

主要在最近的免单突袭活动中，利用了大量的动画特效。但是有一个钥匙碎裂的动画特别卡，一开始对问题的定义是不是页面上的序列帧动画太多，导致canvas 占用了大量内存，因为播放这个序列帧动画的时候，测试反应安卓手机卡的像幻灯片。但是苹果手机却没事。

原理

我们先看下序列帧动画渲染的原理

第一步是将多张图片转成一张雪碧图这里其实已经确定了动画的帧数
然后用 canvas 去渲染每一帧

大家看下这张图：

显示其实也就是我们canvas 的容器，而上面的 1-6 其实就是一张图，所以序列帧动画的原理就是将1-6 这张图通过canvas drawImage api 每一帧进行截取，然后进行渲染。表面看是没啥问题，很简单的逻辑渲染，但是重新绘制的过程，实质上是一个不断刮白-重画的过程。但在屏幕上完成这一系列操作是需要一定时间的，而且屏幕上的图形越复杂，所花的时间就越长，我们肉眼可见的刮白-重画操作，在使用过程中就会让就会直接感觉到屏幕的闪烁。这就为啥在钥匙爆裂那几张动画卡顿。

为了验证我的猜想，我将素材中的整体图片使用2x 图去渲染，在问题机型表现的卡顿几乎都是没有了，但是随之带来的一个问题就是图片的质量就不是很高。这种对于开发而言，就是要设计妥协，说图片太大。但是这种对于用户体验来说，就不太好。所以就有了目前调研的预渲染 canvas , 其实就是在渲染之前将这些 canvas 渲染好

双缓存画布

现在我们有一幅图需要放在Canvas中，使用drawImage()方法，有三种写法：

// 将image放到目标canvas指定位置
void ctx.drawImage(image, dx, dy); 

// 将image放到目标canvas指定位置，指定宽高渲染
void ctx.drawImage(image, dx, dy, dWidth, dHeight);

// 将image裁剪之后放到目标canvas指定位置，指定宽高渲染
void ctx.drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight);

第一种方法只是把图片原样放到Canvas中，第二种方法指定宽高就意味着放大或者缩小图片后再放进去，第三种是将图片裁剪后再放大或者缩小放到canvas中，这三种写法操复杂度作依次增加，性能开销也随之增大。

而如果使用离屏渲染（即我们所说的双缓存画布），我们可以预先把图片裁剪成想要的尺寸，然后将该内容保存起来，绘制的时候直接使用第一种写法直接将图片放入Canvas中。

// 在离屏 canvas 上绘制var offscreencanvas = document.createElement('canvas');// 宽高赋值为想要的图片尺寸

offscreencanvas.width = dWidth;

offscreencanvas.height = dHeight;// 裁剪

offscreencanvas.getContext('2d').drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight);// 在视图canvas中绘制

viewcontext.drawImage(canvas, x, y);

双缓存画布技术的核心在于系统需要在内存中开辟一块与当前画面等大的“逻辑屏幕“。我们的画图和动画操作都会先作用于这块”逻辑屏幕“中，当一个操作在这块”逻辑屏幕“上完成之后，再把整块”逻辑屏幕“投放到我们的屏幕上。

测试

我们先看下没有使用预渲染的 canvas 3x 图

很明显在爆裂的这几幁动画，会卡顿，好像就是卡住了一样。

使用了预渲染之后我们看下播放的视频

背后的原理其实很简单看下这张图：

我们提前做好所有序列帧的在目标canvas 的切割，在这样的过程之下，我们是无法看到整个图形在屏幕上的重绘过程，从而解决了闪烁问题。就好像看动漫一样，不用双缓存技术，就是画一帧看一帧，肯定会卡顿。而用了双缓存技术，会事先把每一帧画好，不断翻动展示出来。这里大家可以联想到 react 的双缓存 fiber 树哦，就能理解了。