动效方案对比

一、先掰清楚术语（这里最容易混）#

"用 sprite 做动画"这句话在中文里指两件完全不同的事：

你说的"拆解出来做动画"是第二种。而"sprite 动画"这个词通常指第一种。 两者经常被拿来对比，但它们其实不在同一个维度上——第三节会说明为什么。

二、三个方案#

业界关于这两者的取舍讨论很多，可参考 frame-by-frame vs skeleton 的对比帖 与 Spine 还是帧动画的中文讨论。

三、本项目实测#

3.1 方案 C 已经被否决#

详见 docs/动效验证-序列帧.md 第一节。

3.2 方案 B 已经在用，但天花板被原图锁住了#

小鸡现在是 4 个零件。量了一下哪些像素能独立运动：

可独立运动的像素合计 58.4%。

剩下 41.6% 是一整块刚体。而且 head 是横切下来的——原图里这只小鸡是"一坨"（头身连在一起）， 没有脖子，只能在 52% 高度横着切一刀。

3.3 体积与运行期开销（这是最关键的一组数）#

以 30 只动物同屏为例（docs/核心玩法.md 里那个待解决问题）：

烘焙按实际尺寸出图后，纹理内存小 2.9 倍，磁盘体积小 70 倍（压缩算法对小图更友好）。

四、结论：这两个方案不是二选一#

它们不在同一个维度上——一个是制作方式，一个是运行方式：

制作期：拆件（骨骼）
   │  可调、体积小、改一个动作不用重画
   │  策划说"摆幅再大点"→ 改个数字，立刻看效果
   ▼
烘焙（离线把每一帧渲染成图）
   │
   ▼
运行期：按屏幕上同时有几个来定
   ├─ 少数大角色（主界面那只）  → 直接跑骨骼，反正就几个
   └─ 大量小角色（田里 30 只）  → 用烘焙好的序列帧，1 次绘制/只

这才是答案。 拆件负责"好做、好改"，序列帧负责"好渲染、体积小"。 两边各拿自己最擅长的那一半。

五、给美术的硬要求：角色要"画成可拆的"#

这是这一节里唯一需要改变出图方式的地方。

现在这样（不好拆）#

头身连成"一坨"，没有脖子、没有腰，只能在 52% 高度横着切一刀。 切面落在纯色区域才看不出来，所以只能切一层。

下一批应该这样#

六、同屏几十个相同物体：实测#

这一节回答那个具体问题：屏幕上几十只一模一样的动物同时播放动画，哪个方案更快？

"相同"这个词是关键——它意味着所有实例共享同一份素材，于是可以合批、可以实例化。 如果是几十个各不相同的角色，下面的结论全部作废。

7.1 测试条件#

• 场景：430×764 竖屏（手机尺寸），每只按 48px 高显示，16 帧循环、相位错开
• 三个数量：30 / 60 / 120 只
• 每帧结束强制同步一次（readPixels）——不这么做量到的只是"录命令"的时间，不是真正的光栅化
• 素材：docs/art/anim/ 下的零件图与烘焙序列帧，脚本在 tools/art/bench/（跑法见该目录的 README）

7.2 结果（ms/帧，越低越好）#

7.3 三个结论#

① 合批与否，差了一个数量级

同样 120 只：

WebGL 不合批 · 拆件   10.58 ms   ← 每只每个零件都单独一次 drawArrays
WebGL 合批  · 拆件    0.89 ms   ← 全部四边形拼成一个顶点缓冲，只发一次
                      ↑ 差 12 倍

"零件多 = draw call 多"这个直觉只在没有合批的时候成立。 真实 2D 引擎（Cocos / Laya / Egret）都会按纹理合批，所以这条基本不成立。

② 合批之后，拆件只比序列帧慢 1.4 ~ 2 倍

差距来自顶点数（拆件 24n 个顶点 vs 序列帧 6n），不是 draw call。 在 60fps 的 16.7ms 预算里，这点差距完全不是瓶颈。

③ 所以真正的决定性因素不是帧率，是内存

同一套动作，按 48px 烘焙出来长这样（左上角标了实际像素尺寸，右边是放大 6 倍的样子）：

放大 6 倍看细节还在不在：

7.4 但如果是 Canvas 2D，序列帧是压倒性的#

微信小游戏两种后端都支持。Canvas 2D 下没有任何合批，每次 drawImage 都是独立开销：

120 只时拆件要吃掉 6ms，是 16.7ms 预算的 36%——这时候就必须上烘焙了。

七、同屏上千上万：瓶颈会转移#

几十个和几万个是两个完全不同的问题。数量上去以后，第三节和第六节讨论的东西全部不再是瓶颈。

8.1 结论先行#

8.2 业界在用的方案#

对2D 精灵来说，VAT 是多余的——精灵本来就是一张四边形，把 16 帧打在图集里、 用实例化 + 顶点着色器算 UV 偏移，就等价于 VAT 干的事，而且更简单。

8.3 实测：成本模型#

在 1024×768 视口下测了 12 组（数量 × 尺寸），线性拟合：

每帧耗时(ms) ≈ 0.0221 × 实例数  +  14.8 × 百万像素

残差最大 4.5 ms / 486 ms，拟合得很准：

8.4 怎么实现：帧号交给顶点着色器算#

这是上万规模下最有用的一招。要点是每帧只更新一个 uniform，不动顶点缓冲：

// 每实例属性：iD = (x, y, phase, scale)，iUVStep = (1/列数, 1/行数)
attribute vec2 aPos;      // 四边形角点 0..1
attribute vec4 iD;
attribute vec2 iUVStep;

uniform float uTime;      // 秒
uniform float uFPS;
uniform float uFrames;    // 总帧数
uniform vec2  uGrid;      // (列数, 行数)

varying vec2 vUV;

void main() {
  // ★ 帧号在 GPU 上算，CPU 每帧只需要 gl.uniform1f(uTime, t)
  float fi = floor(mod(uTime * uFPS + iD.z, uFrames));
  float cx = mod(fi, uGrid.x);
  float cy = floor(fi / uGrid.x);

  vUV = vec2(cx, cy) * iUVStep + aPos * iUVStep;
  vec2 world = iD.xy + aPos * iD.w;         // iD.z 是相位，让每只错开
  gl_Position = vec4(world / uResolution * 2.0 - 1.0, 0.0, 1.0);
}

实例缓冲的构造（只做一次）：

const d = new Float32Array(n * 6);
for (let i = 0; i < n; i++) {
  const o = i * 6;
  d[o]     = x[i];          // 位置
  d[o + 1] = y[i];
  d[o + 2] = (i * 3) % 16;  // 相位：错开播放，否则上万个动作完全同步会很假
  d[o + 3] = size;          // 尺寸
  d[o + 4] = 1 / cols;      // 每帧在 UV 上的步进
  d[o + 5] = 1 / rows;
}
gl.bufferData(gl.ARRAY_BUFFER, d, gl.STATIC_DRAW);   // ← 一次
// 之后每帧只有：
gl.uniform1f(uTimeLoc, t);
gl.drawArraysInstanced(gl.TRIANGLES, 0, 6, n);

8.5 CPU 侧根本不用担心#

单独量了纯 JS 侧（硬件无关）：

十万个物体重建整个 buffer 也只要 0.81 ms。 所以"每帧重建 buffer 太贵"是个伪命题—— 真正该省的是别的地方。不过既然静态 buffer 更简单（少写代码），就用静态的。

8.6 优化清单（按收益排序）#

8.7 这套用在小农场上意味着什么#

我们的场景是"田里几百株作物 + 几十只动物"，远没到上万的量级。 第六节的结论不变（烘焙序列帧）。但有两个可以现在就做的：

• 作物如果要做几百株摇摆，用实例化 + 着色器算相位，成本几乎为零 （摇摆不需要美术，sin(uTime + phase) 直接改顶点就行）。
• 飘字 / 金币 / 粒子这类"同一张图重复几百次"的东西，直接按本章的实例化写法做。

---

八、本项目的决定#

下一步：

• 把四个动物从原图切零件（小兔的长耳朵、小猪的卷尾巴会有更明显的次级运动）。
• 给 waddle.py 加一个 --bake-size 参数 —— 已完成，用法是 --bake 48。
• 下一批角色出图时，按第五节那张表分层出图，不要再画成"一坨"。
• 用同一套基准脚本，量一下真机（微信开发者工具 / 真机）上的数字。 测试机没有 GPU，第七节那些绝对值来自软件光栅化，只能看趋势。
• 给作物摇摆做一版实例化 + 着色器算相位的实现（几百株的成本几乎为零）。

---