好久没写了，其实可写的还是挺多，主要还是懒吧...

最近公司项目使用小程序做序列帧动画，大概有 116 张图，共9.6M。

比较闲的日子里实验了一番，主要有以下几种方法，

1. css background-image + animation

2. css background-position + animation

3. js background-image

4. js background-position

5. js img src

6. canvas drawImage

结果当然是 canvas 性能最优咯，不会出现掉帧和卡屏的情况，其中最不推荐第一种

所以这次项目也就准备尝试下微信小程序的 canvas 会不会有别样的风味

基本上和 html 的 canvas 区别不大，方法名略有不同，再就是需要一个 draw 方法才会绘制。

canvas.getContext('2d') 等于 wx.createCanvasContext(canvas)。

一般 wx.createCanvasContext 放在 onReady 还是 onShow 并没有什么区别（手里机型太少，没试太多）

接着就开始了填坑之路：

1. Image 对象问题，只需直接使用图片路径

官方案例给的是 wx.chooseImage 返回的缓存文件，显然不是我们要的；

在 html 中如果想 drawImage 那就需要一个 Image 对象，需要先 new Image() 或者获取到 dom 中的 <img>，

那么小程序该怎么办呢，我略一沉凝，准备试它一下，直接使用了图片路径，

ctx = ctx ? ctx : wx.createCanvasContext('imgs');
url = 'https://sum.kdcer.com/test/sw_shake/0/0 (1).jpg';
ctx.drawImage(url, 0, 0, 300, 500);  // 直接使用图片路径
ctx.darw()

唔，非常美妙，调试器上是正常的。url 为相对路径也是可以的。

当然，这个时候预加载就是个问题，只能在 wxml 中去 for 出所有的图片并 bindload 了

2. 图片路径不能有特殊符号

上面的情况虽然调试器通了，但手机预览时还是没有任何图片绘制上去呀（其他点线绘制是存在的）。

然后去博客寻找了番，开始我是怀疑可能直接使用图片路径是不支持这种远程资源的（仅能用小程序内部的相对路径）。

于是我采用了 downloadFile 这种方法再次尝试。

wx.downloadFile({
  url: url,
  success: function (res) {
    ctx.drawImage(res.tempFilePath, 0, 0, 300, 500);
    ctx.draw();
  }
})

 结果返回给我的 res.tempFilePath 是个 .htm 结尾的文件，报出 http 400（请求无效）的错误。

我怀疑问题出在了文件本身，于是我改了下文件名，由 0 (1).jpg 改为 1.jpg，就能正常访问了。

后来进行了一些实验，暂时还只发现了 空格+括号 这一种命名会失败。

drawImage 如果直接使用图片路径其实是可以访问远程资源的，只是加载的慢，图片异步没法绘制上去了。

所以更为推荐使用 downloadFile 这种方式来先加载图片再绘制。

比较坑的是，downloadFile 不能下载相对路径的图片，这让我想优化把一部分图片放进小程序变得无比麻烦（其实2M资源放进去小程序就会变得非常卡）。

3. downloadFile 文件数限制

官方表示，downloadFile 这个 api 最大并发限制为 10 个，

意味着直接 for 个 116 下是会报错的。

因此需要换用为递归的方式去预加载图片。

我写的递归不见得都适用，就不放出来了，应该没什么难点的。

（推荐先用 html 写通递归，不然小程序编辑器死循环了很扎心）

4. downloadFile 合法域名的配置

开发完成后出现了小程序仅有打开了调试工具才能正常运行的情况，

后来经过同事点拨，原来还要设置 downloadFile 的合法域名，这个修改就简单了。

每个月只能修改 5 次的限制应该不会造成什么影响。

5. requestAnimationFrame 问题

为了更好的动画优化，当然少不了 requestAnimationFrame 的存在。

然而，安卓机的小程序是有的，苹果机小程序却根本没有这个方法。

好在我们可以写段回退兼容，放在 Page 的外面。

if (typeof requestAnimationFrame == 'undefined') {
  var lastTime = 0;
  var requestAnimationFrame = function (callback) {
    var currTime = new Date().getTime();
    var timeToCall = Math.max(0, 16 - (currTime - lastTime));
    var id = setTimeout(function () { callback(currTime + timeToCall); }, timeToCall);
    lastTime = currTime + timeToCall;
    return id;
  };
}
if (typeof cancelAnimationFrame == 'undefined') {
  var cancelAnimationFrame = function (id) {
    clearTimeout(id);
  };
}

6. fps 性能问题

小程序一直吹嘘着接近原生的流畅体验，但这次帧动画的项目中显然打脸了。

html 版的 canvas 每 15ms 绘制一次都是小 case，但小程序则需要 50ms 以上的间隔。否则会出现间断性白屏。

60fps 和 20fps 虽然在 html 中有很大差距，但在小程序中 20fps 并没有太影响用户的浏览体验。

毕竟 js 的运算和 webview 的通信本身就不是多快的一件事，而如果单单只考虑 webview 和 html 的话那当然有差距。

总的来说，填坑的路是比较烦人的，

后一个问题解决了又开始想，是不是前一个问题其实本来是对的，然后又回去重来一遍，

最后的最后，来来回回，才能彻底填平这个坑。