假设你的妹子，本来站在你面前一米，你叫她一声，她就过来抱住你，这个过程就是一个动画。动画的原理都是这样的，反正就是要“动”。

即使没接触canvas的时候，我们也用JS写过一些动画，比如常见的图片切换效果。产生动画的原因，是改变元素的形态，比如透明度，坐标等。此刻我们设置元素的left为100，下一秒设置left为101，如此循环，就产生动画了。

而canvas上的动画与HTML元素的动画是不同的。html元素的动画，始终是对一个DOM元素的操作；而在canvas中，没有任何元素。

假设我们用html与canvas来做一个相同的动画：一个红色正方形由网页左边移动到右边。那么：

html动画：通过html与css整出一个正方形，然后不断的设置正方形的left值

canvas动画：先在起点位置绘制一个正方形，然后清空画布，在下一个位置再绘制一个正方形；然后又清空，又在下一个位置绘制一个正方形。。。——如此循环，简单的说就是不停的绘制，不停的清空。

由此看来，好像canvas是个傻子一样。

谁叫canvas无法取得他上面画的元素呢？

那么，如果我的动画要1000个元素同时动怎么办呢？标准答案是不停的重绘这1000个元素。

当然，这种说法是很坑爹的。由于canvas的局限性，所以已经有很多大神们想出了各种办法来提高他的效率。这些办法目的只有一个——尽量的减少重绘。

比如我要写一个马里奥游戏，分拆开来，游戏元素包括：背景，马里奥本人，金币及道具，敌人等等。其中马里奥本人无疑会是动得最欢快的，比如我闲得蛋疼要在原地跳1000下，如果背景与马里奥本人都在一个canvas中，那么可能连背景与要重绘几千次——而背景图无疑会比较大，这样重绘，效率就很低下了。

所以常用的办法是把不经常变化的与经常变化的分开绘制到两个图层上。这就涉及到不同canvas层的交互问题，当然，这篇文章不会讲得这么深。

简单的说，就是——不动就不画，画只画动的。

而早在canvas出现前，就有很多牛人写出了纯HTML的游戏——甚至有值物大战僵尸这种的。现在canvas出来了，我不禁想问一句：在做相同的动画效果时，html版与canvas版，谁的效率更高呢？

说到这里我觉得有必要自己试一下——写代码去了，下一篇文章放出测试代码和结果吧