企业官网建设流程全解析

1. 同屏百人：先把动画的账单算清楚

Unity3D 多人战场 Animation 优化这个话题，我在几个不同规模的项目里都经历过。从最开始只要画面表现完整、不考虑成本，到后来人数从十几涨到五六十、再涨到上百，性能预算被一点点挤薄，最后不得不用大量时间拆分性能开销。多人战场和单机动作游戏最大的区别在于：单机里角色只有一两个，动画开销再高也只占几毫秒；战场里屏幕上一眼望去全是人，每一个都在跑动画状态机、每一帧都在上传骨骼矩阵、每一帧都在做蒙皮计算，这些成本是线性叠加的，一旦数量上去，动画部分会直接占掉一半的主线程时间。

这篇文章属于实打实的工程总结，不涉及引擎入门。我会按“资源侧怎么减、运行时怎么管、渲染侧怎么省、网络侧怎么降级”四条线来讲，适合已经能跑通 Animator、但一进战场就掉帧的开发者参考。里面会给出具体的参数取值、可用的代码片段、我自己踩过的坑，以及那些官方文档不会写、只有实际做过多人项目才会意识到的细节。先说明一个基本判断：动画优化的收益主要来自“结构性的省略”，而不是“把某个参数调小一点”。如果不该更新的角色仍然在更新，调整参数只能带来很有限的改善。

1.1 三类开销必须分开看

我见过太多团队一上来就修改压缩参数，结果帧率没有明显变化。因为他们优化的对象选错了。多人战场里一个角色的动画成本大致分三块，且三者不在同一个线程、不在同一个模块里：

这三块我建议你在性能分析器里分别取得函数级数据，不要只看一个总帧时间。Unity 的 Profiler 在 CPU 模块下有几个关键标记：Animator.Update、MeshSkinning.Update、DirectorUpdate、PreLateUpdate.ScriptRunBehaviourUpdate。你的目标是把Animator.Update压到总预算的 20% 以内，MeshSkinning.Update尽量转成 GPU 侧计算。这两个目标一旦达不成，后面所有画面表现上的取舍都要让路。

顺带说一个很多人都忽略的点：Animator.Update的成本和状态机复杂程度强相关，而不只是和骨骼数相关。一个 30 根骨骼、但挂了 8 层 Layer、每层一堆 AnyState 转移的角色，很可能比一个 80 根骨骼、只有两层简单混合树的角色更贵。原因是求值阶段要做状态转移判定、参数比对、权重插值，这些都消耗 CPU，并且逻辑分支多，缓存也不友好。

1.2 性能分析器要这样用才有意义

我的习惯是先做一次“空场景满配”的压力测试：把战场逻辑剥掉，只留下 N 个角色在屏幕内循环跑动画，N 从 20 递增到 120，每 20 个记一次数据。这样拉出来的曲线特别直观——如果 20 到 40 的增量是 3 ms，40 到 60 的增量还是 3 ms，说明成本是纯线性的，那就该做“减少更新数量”这类优化；如果增量在某个点突然变大，通常是批次被打断、变体切换、或者布料/IK 开始触发，那就先去查那几个模块。

这里有个实操细节：Profiler 的采样深度要设到能看见Animator.Update的单次耗时分布，而不是只看平均值。我做过的项目里出现过一种情况，平均每角色 0.08 ms 看着还行，但采样里有一批角色单帧达到 0.6 ms，原因是这批角色刚好同时触发了状态切换、同时加载了新的动画片段，导致同一帧里出现明显尖峰。平均掉这个尖峰，你会得出“还行”的错误结论，实际玩起来的感受是每隔两秒就卡一下。要看的是最慢的那一帧，而不是平均。

还有个小技巧：打一个测试包，在其中加一个开关，按一下就把同屏角色数翻倍，再按一下减半。这样你可以在真机上几秒内来回验证改动效果，比每次重新打包跑固定场景高效太多。多人战场的性能问题往往是环境相关的，编辑器里的数据和真机差距非常大，尤其在移动端的中低端机型上，主线程预算本来就紧张，编辑器里看着 60 帧，真机上可能只有 35 帧。

2. 资源侧：把成本降低在导入之前

资源侧的优化是最不容易反悔的：一旦资源按高标准做好了，后面怎么调运行时参数都不会失控。反过来，如果模型带着 200 根骨骼、每个动画片段 30 秒、蒙皮权重 4 个影响，你在运行时怎么优化都只是把这个损失补回来一部分。所以我的习惯是把资源侧的规则提前确定下来，并写进美术规范。

2.1 骨骼数量与蒙皮精度的取舍

战场角色的骨骼数量要按“镜头距离”定，不能按“这个角色我很喜欢”定。我的经验值是这样：

这张表不是拍脑袋。骨骼数量直接影响三件事：动画求值时每根骨骼都要做局部变换、蒙皮阶段每个顶点要采样一堆骨骼矩阵、骨骼矩阵上传时数据量线性增长。以 45 根骨骼、4x3 矩阵上传为例，单角色每帧 45 × 12 × 4 = 2160 字节，100 个角色就是 216 KB/帧，60 帧下约 12.7 MB/s。这个量级在桌面端无所谓，在移动端是实打实的内存带宽占用，而且这部分带宽和纹理采样、顶点读取是抢的。

蒙皮影响数从 4 降到 2 的视觉代价，在手肘、膝盖、肩部这几个位置最容易暴露。我的做法是让美术在这几个关节处手动补充权重过渡，而不是盲目全降到 2。实测下来，肩部和髋部保留 3 个影响、其余部位 2 个影响，视觉上几乎看不出差别，但顶点着色器的采样次数能降一档。这个调整需要配合模型检查脚本，把超过阈值的影响数直接打印出来，谁超标谁改，比口头约定有效得多。

2.2 导入设置里那几个真正影响性能的选项

模型导入面板上项目很多，但真正对多人战场有决定性影响的是下面这几项，我按重要性排序：

• Optimize GameObject（优化游戏对象）：这一项必须打开。它会把模型的骨骼层级从场景里“抽走”，不再为每根骨骼创建 Transform 对象，而是通过内部索引映射。一个 45 骨骼的角色，如果不开，场景里就会多出 45 个 GameObject，100 个角色就是 4500 个对象，光是层级遍历和 Transform 更新就够呛。开了之后，骨骼变换在原生层完成，主线程省下大量开销。代价是你不能再通过transform.Find("Bip001/Spine")这种方式取骨骼，必须用Animator.GetBoneTransform(HumanBodyBones.Spine)或者提前缓存引用。

• Import BlendShapes（导入混合形状）：战场角色除非要做面部表情，否则一律关掉。BlendShape 的开销非常隐蔽，它在 CPU 侧做顶点插值，每个 BlendShape 都要遍历一遍顶点缓冲区，100 个角色各自挂几个 BlendShape，主线程会莫名其妙多出好几毫秒，而且在性能分析器里不容易一眼看出来。

• Import Cameras / Lights（导入相机与灯光）：一律关。这不是性能问题，是干净度问题。多人战场里场景对象本来就多，误带的相机和灯光会干扰剔除和渲染。

• Mesh Compression（网格压缩）：建议设成 Off 或 Low。它的目的是减小包体和内存，但高压缩等级会让顶点数据变成非对齐格式，GPU 读取时需要额外解码，在低端机上反而更慢。战场上同屏角色多，顶点吞吐才是关键，不要为了省几 MB 内存影响顶点读取速度。

• Weld Vertices（焊接顶点）：打开。能减少顶点数，同时提升顶点缓存命中率。但要注意 UV 接缝和硬边会被拆开，焊不掉的部分不用强行追求。

• Skin Weights（蒙皮权重影响数）：按上一节的表格设，Standard 是 4，可以手动改成 2 或 3。这个设置改完之后一定要让美术重新确认关节形变，因为它是破坏性的，改小了再调回来需要重新导入。

提示：Optimize GameObject 打开后，如果你用了依赖骨骼 Transform 的第三方插件（比如挂点、武器插槽、特效跟随），要提前排查。我遇到过一次武器挂点错位的问题，排查了很久才发现是挂点脚本拿的是导入前的 Transform 引用，优化后那批对象已经不存在了。

2.3 动画压缩：误差参数要按“关节”而非“整段”来定

动画压缩是资源侧收益最大的一环，也是最容易被设置错的。Unity 提供三种模式：Keyframe Reduction（关键帧精简）、Keyframe Reduction and Compression（精简+压缩）、Optimal（最优）。多人战场我一般都选 Keyframe Reduction，配合合理的误差值。

误差参数有三个：Rotation Error（度）、Position Error（百分比）、Scale Error（百分比）。很多人直接填 0.5、0.5、0.5 就结束了，实际上这三个值的含义差别很大。Rotation Error 是角度误差，单位是度，0.5 度在视觉上基本不可见；Position Error 是相对于模型包围盒尺寸的百分比，0.5 意味着允许 0.5% 的位置偏差，对一个 2 米高的角色来说就是 1 厘米，跑步时脚部可能会轻微滑动；Scale Error 除非有缩放动画，否则可以设得很大甚至忽略。

我的实测取值是这样的：

这里有个计算值得说清楚：一段 30 帧每秒、时长 1 秒的跑步动画，原始有 30 个关键帧。Rotation Error 设 0.5 度时，精简算法会尝试删掉那些删除后误差仍在阈值内的帧。实际测试中，膝盖、手肘这类旋转变化剧烈的关节通常保留 10~15 帧，脊柱、头部这类变化平缓的关节能压到 3~5 帧。整体数据量大概能降到原来的 35%~45%。如果设成 2.0 度，能压到 20% 左右，但脚部落地那几帧会有明显的“糊”感，特别是在第三人称近距离视角下看得出来。

还有一个常被忽略的点：动画片段的帧率本身。原始数据如果是 60 帧每秒，导入时可以把采样率降到 30 帧，直接减半。绝大多数战场动画在 30 帧采样下完全够用，动作游戏的重击、闪避可能需要 60 帧，但跑步、待机这类循环动画没必要。这个设置在片段的 Inspector 里能找到，改完记得让动画师确认一下快速动作有没有丢帧感。

3. 运行时：把 Animator 的更新量压下来

资源侧做完，接下来是运行时。这块是收益最直接的地方，因为你可以决定“哪些角色这一帧不更新”。多人战场最典型的错误就是让屏幕外、背后、远处的角色全部保持完整更新，这在单机游戏里也浪费，在战场里会直接占满主线程性能预算。

3.1 剔除模式要按角色距离分档

Animator.cullingMode有三个值：AlwaysAnimate、CullUpdateTransforms、CullCompletely。默认是AlwaysAnimate，这个默认值在战场里是浪费性能的主要原因。

• AlwaysAnimate：完全不管可见性，一直更新。只适合主角、以及必须在屏幕外继续计算的单位（比如需要精确碰撞判定的角色）。
• CullUpdateTransforms：不可见时停止写入 Transform，但状态机逻辑还在跑。适合“屏幕外也需要保持状态进度”的单位，比如技能冷却、状态机计时。
• CullCompletely：不可见时完全停更，连状态机都停。适合绝大多数杂兵。

但要注意，剔除判断依赖渲染器的包围盒。如果包围盒设得不准，或者角色在屏幕边缘只露出一角，剔除可能不生效。我的做法是自己写一层距离与视锥判断，而不是完全交给引擎的可见性系统。原因很简单：引擎的可见性判断在渲染管线里，而动画更新在更早的阶段，两者的时序不一定对得上，靠自己判断更可控。

// 简易动画更新调度器：按距离与视锥分档 public enum AnimTier { Full = 0, LogicOnly = 1, Frozen = 2 } public class AnimTierController : MonoBehaviour { public Animator animator; public SkinnedMeshRenderer skinned; public float fullDist = 25f; // 25 米内全量更新 public float logicDist = 60f; // 60 米内只跑逻辑 private Camera mainCam; private static readonly int Tier = Shader.PropertyToID("_AnimTier"); void Awake() { mainCam = Camera.main; // 冻结档位下，包围盒不要再被引擎每帧重算 if (skinned != null) skinned.updateWhenOffscreen = false; } void LateUpdate() { Vector3 v = mainCam.transform.position - transform.position; float d = v.magnitude; AnimTier tier; if (d <= fullDist) tier = AnimTier.Full; else if (d <= logicDist) tier = AnimTier.LogicOnly; else tier = AnimTier.Frozen; ApplyTier(tier); } void ApplyTier(AnimTier tier) { switch (tier) { case AnimTier.Full: animator.cullingMode = AnimatorCullingMode.AlwaysAnimate; animator.enabled = true; break; case AnimTier.LogicOnly: // 状态机继续跑，但不再写 Transform animator.cullingMode = AnimatorCullingMode.CullUpdateTransforms; animator.enabled = true; break; case AnimTier.Frozen: animator.cullingMode = AnimatorCullingMode.CullCompletely; // 卸载蒙皮计算，只保留可见性 if (skinned != null) skinned.forceRenderingOff = true; break; } } }

这段代码看着简单，但有两个细节要注意。第一，forceRenderingOff是渲染层开关，不影响动画求值，用它把远处角色的绘制也一起关掉，能省下不少批次。第二，不要每帧都调用ApplyTier里的三个赋值，实际项目中我会缓存当前档位，档位变化时才写，避免不必要的属性 setter 调用。属性 setter 在多角色场景下的累积开销不小。

3.2 状态机结构优化：Layer 与 AnyState 要慎用

状态机结构对性能的影响，比大多数人以为的大得多。我做过一次对比测试：同一个角色，一套是 3 层 Layer、每层都有独立的混合树；另一套是压平后的单层状态机加参数控制。结果前者的Animator.Update耗时是后者的 1.8 倍。原因有三个：每层 Layer 都要独立求值并做权重混合；Layer 之间如果用了 Avatar Mask，还要额外做掩码过滤；AnyState 的转移条件每帧都要对所有状态判一遍。

关于 AnyState，我的原则是能不用就不用。它是“从任意状态跳到某状态”的快捷方式，但代价是每帧都要评估，而且很容易写出多个 AnyState 互相争抢的过渡，导致状态机在同一帧里反复切换。战场上如果每个角色都用两三个 AnyState 处理受击、死亡、控制效果，100 个角色就是几百次判定。更麻烦的是 AnyState 触发的过渡会打断当前的混合，即使最后没有真正切换，也会造成额外的求值开销。

替代方案有两种。一是把受击、控制这类高优先级状态放到独立的一层，用 Layer Weight 控制显隐，主层继续跑移动逻辑，这样不需要状态转移，只是权重叠加。二是用代码检查标志位再显式调用Animator.CrossFade，把转移逻辑从状态机移到脚本层，状态机只负责当前状态的播放。后者在多人战场里尤其合适，因为受击、死亡这些事件本来就是服务器或战斗逻辑驱动的，由代码统一调度反而更好管理。

Avatar Mask 也是个双刃剑。它的作用对象是 Layer，用来只影响上半身或下半身，好处是可以做“跑动中射击”这种叠加，代价是每个使用 Mask 的 Layer 都要多一次权重计算和骨骼筛选。我的经验是：一个角色最多用一层 Mask（通常是上半身），再做更细的叠加就该考虑用 Playable API 手动混合了，因为多层 Mask 的嵌套开销在人多时会明显放大。

3.3 降频更新：最有效的优化手段

如果只能选一个优化手段，我会选降频。理由是它不改变资源质量、不影响视觉精度，纯粹是把“不需要每帧算”的东西改成“几帧算一次”。远处的角色，视距在 40 米开外，屏幕上的投影可能只有 30 像素高，每帧更新和每三帧更新一次的视觉差别接近零，但 CPU 开销直接降到三分之一。

具体做法是给每个角色分配一个相位偏移，避免所有角色在同一帧集中更新。这一点非常关键：如果你只是简单地“每三帧更新一次”，而没有错开相位，那么每三帧里就会有一帧所有角色同时更新，形成周期性的帧率波动，玩起来是一顿一顿的。错开相位后，更新量会被均匀分摊到每一帧。

// 按相位错开的多角色动画降频调度 public class AnimTickScheduler : MonoBehaviour { [Range(1, 6)] public int updateEveryNFrames = 3; public Animator animator; private int phase; void Start() { // 用实例 ID 做哈希，保证分布均匀且每次运行稳定 phase = Mathf.Abs(GetInstanceID()) % updateEveryNFrames; } void Update() { // 按帧号取模，只有落在自己相位上的帧才真正求值 if (Time.frameCount % updateEveryNFrames != phase) return; animator.enabled = true; } void LateUpdate() { // 求值完成后立刻关掉，下一帧不再自动更新 if (Time.frameCount % updateEveryNFrames == phase) animator.enabled = false; } }

这段写法依赖一个不太为人知的细节：Animator.enabled = false之后，动画会停留在最后一帧的状态，不再推进。所以“打开求值、求值完关闭”的效果等价于“这一帧推进了一次”。这样做的额外好处是：Animator.enabled的开关本身比持续运行动画求值便宜得多。

不过这种做法有个明显的副作用：动画事件（Animation Event）会在求值的那一帧集中触发。如果你的动画事件里挂了伤害判定、音效播放，降频会导致判定时机整体延后，并且可能在一帧内触发多次。解决方案是把动画事件从动画片段里拿掉，改用基于时间的代码判定，或者至少让事件只做“标记”，真正的逻辑在下一帧统一处理。

3.4 参数写入的隐性成本

Animator.SetFloat、SetBool这些接口看着无害，实际每次调用都要做字符串哈希（除非用整数哈希）、参数查找、脏标记设置。在战场上，如果你在每个角色的 Update 里无脑地每帧写十几个参数，累积起来是一笔不小的开销。

我的做法是三条：第一，所有参数名在静态类里提前Animator.StringToHash算好，用整数版本；第二，只在值真正变化时写，不要在 Update 里无条件写；第三，能用SetBool就不用SetFloat再在状态机里做大于判断，布尔判定比浮点比较便宜。

static class AnimParams { public static readonly int Speed = Animator.StringToHash("Speed"); public static readonly int IsDead = Animator.StringToHash("IsDead"); public static readonly int Hit = Animator.StringToHash("Hit"); } // 只在变化时写入 float lastSpeed; void UpdateSpeed(float s) { if (Mathf.Approximately(s, lastSpeed)) return; lastSpeed = s; animator.SetFloat(AnimParams.Speed, s); }

还有一个容易忽略的点：混合树里的参数如果参与一维或二维混合，参数变化会触发混合权重的重新计算，这个计算量比单纯的状态判定高。所以跑步速度这类连续变化的参数，建议做量化处理，比如把 0~1 的速度值量化到 0.1 的步长，减少无效的混合重算。视觉上完全看不出来，但 CPU 侧会稳定一些。

4. 渲染侧：骨骼矩阵与蒙皮的优化空间

4.1 把骨骼上传的数据量算清楚

这一块很多开发者没算过账，但只要算一次就明白该往哪优化。Unity 默认情况下每根骨骼要上传一个 4x3 的矩阵（3 行 4 列，12 个 float），某些路径下是 4x4（16 个 float）。我们按 4x3 算：

• 单角色 45 根骨骼：45 × 12 × 4 字节 = 2160 字节 ≈ 2.1 KB
• 100 个角色：约 211 KB / 帧
• 60 帧下：约 12.7 MB / 秒

如果骨骼数翻倍到 90 根，这个数字直接变成 25 MB/秒。它走的是 CPU 到 GPU 的总线上传，和纹理流送、顶点缓冲共用带宽。在移动端，这个量级已经能明显影响帧率了，而且它是持续的、每帧都有的，不像纹理那样是一次性加载。

所以“减骨骼”这件事的收益不只是蒙皮计算，还包括上传带宽。这也是我在 2.1 节把远处的单位压到 15~25 根骨骼的原因。另外，如果某些角色确实需要精细骨骼但只在中近距离出现，可以准备两套模型（高模和低模），用 LODGroup 切换。切换时要注意 Animator 的绑定要跟着换，不能只换 Mesh。

4.2 GPU Skinning 什么时候值得开

GPU Skinning 的原理是把蒙皮计算从 CPU 挪到顶点着色器里，骨骼矩阵打包成纹理或常量缓冲上传，每个顶点自己计算变换。开启方式在 Player Settings 的图形设置里，另外材质所用的 Shader 必须支持 GPU 蒙皮变体。

它的收益和限制都很明确。收益是主线程的MeshSkinning.Update会大幅下降，100 个角色能省出好几毫秒。限制有三条：第一，开启后 CPU 侧拿不到蒙皮后的顶点数据，如果你有基于网格的精确点击判定、或者需要BakeMesh做快照（比如死亡后的布娃娃切换），会受影响；第二，部分低端设备的 GPU 性能本来就不宽裕，把计算挪过去可能让 GPU 变成瓶颈，这种情况在低端安卓机上确实出现过；第三，它和某些自定义 Shader 的兼容性需要逐个验证。

我的判断标准是：如果性能分析器里MeshSkinning.Update占主线程超过 2 ms，且 GPU 侧还有余量，就开。开了之后必须重新测一遍帧率，不要只看主线程数据，因为 GPU 侧的瓶颈在主线程视角下是看不出来的，得用 GPU 性能分析工具或者看整体帧率。

更激进的方案是 Compute Shader 蒙皮：把骨骼矩阵组织成结构化缓冲，用 Compute Shader 批量计算所有角色的顶点，输出到顶点缓冲，再用Graphics.DrawMeshInstanced或DrawProcedural绘制。这个方案的收益最大，因为可以真正合批，把上百个角色压成个位数的绘制调用；但工程复杂度也最高，需要自己管理顶点缓冲的生命周期、处理 LOD 切换、还要写一套和骨骼动画数据对接的管线。除非你的战场规模真的到了几百个单位同屏，否则不建议一开始就走这条路。

4.3 LOD 与“骨骼 LOD”的配合

LODGroup 大家都知道，但用在动画角色上有个细节经常被忽略：切换 LOD 时动画是否连续。如果高低模用的是同一个 Animator 和同一套骨骼，切换后动画会跳一下，因为骨骼数量和层级不同。解决办法是让低模完全对齐高模的骨骼命名和层级，只删减顶点和材质，不删骨骼；或者干脆让低模不走骨骼动画，改用顶点动画纹理，切换时做一次短时间的过渡淡出。

关于 LOD 的切换距离，我的经验值（以第三人称战场、角色身高 1.8 米为基准）：

这些值必须结合你自己的镜头高度和视野角调整。俯视角战场的可视距离和第三人称完全不一样，俯视角下 40 米外的角色投影可能只有十几像素，直接剔除都没问题。判断依据应该是“屏幕投影高度”，而不是绝对距离。我通常会让角色在屏幕上的投影低于 24 像素时就切到最低 LOD，低于 12 像素就完全剔除。这个阈值可以在运行时根据相机参数动态算，比写死距离更靠谱。

5. 网络与表现：远端单位的动画优化

5.1 远端玩家的动画不需要和本地一样精细

多人战场里，本地玩家控制的角色需要完整的输入响应和动画表现，但其他玩家的角色，你其实只需要“看起来对”。这里有两个可观的优化空间：一是降低远端角色的动画更新频率，二是简化远端角色的状态机。

更新频率上，本地角色保持每帧更新，远端角色根据距离和重要程度分档：近距离 30 帧、中距离 15 帧、远距离 10 帧甚至 5 帧。动画在低频更新之间靠插值补足，视觉上不会有明显问题，因为远端角色的动作变化本来就慢，玩家也不会盯着看细节。

状态机上，远端角色可以砍掉大量本地才需要的逻辑：跳跃的前摇、落地缓冲、转向动画的细分、各种受击方向变体。远端只需要保证“跑、站、攻击、死亡”这几个核心状态正确，其他都可以退化到最接近的通用状态。我做过一次统计，远端角色砍掉这些细分状态后，状态机节点数从 60 多个降到 20 个以内，单角色求值成本下降约 40%。

5.2 网络同步到动画的最小信息集

远端角色的动画状态不需要精确同步，只需要同步“能被玩家感知的部分”。我在项目里采用的方案是同步一个很小的结构：

// 远端单位动画状态压缩包，共 6 字节 public struct RemoteAnimState { public byte stateId; // 0=待机 1=移动 2=攻击 3=受击 4=死亡 public byte speedQ; // 速度量化，0~255 映射 0~8 m/s public ushort dirQ; // 朝向量化，0~65535 映射 0~360 度 public ushort timeQ; // 当前状态已播放时长，单位 10ms，最大 655 秒 }

6 个字节，按 20 Hz 同步，单人每秒 120 字节，50 个远端单位就是 6 KB/s。这个量级在战场上完全可以接受，而且能保证远端角色的状态切换及时、朝向准确。

关键点在于stateId只传枚举，不传具体的动画片段名和归一化时间，后者由接收端根据片段时长自己算。这样即使两端动画片段时长有细微差别，也不会因为时间戳对不上而导致抖动。速度量化到 0~255 映射 0~8 m/s，精度约 3 cm/s，足够驱动混合树了；朝向用 ushort 量化，精度约 0.0055 度，远超实际需要，其实用 byte 也行，但保留 ushort 是为了让旋转平滑一些。

5.3 大规模单位的方案选择

当同屏单位数量超过 150，前面这些手段的组合效果会开始变得不够用。这时候要考虑换一套渲染和动画模型。常见的两条路：

第一条是顶点动画纹理。把动画烘焙成一张纹理，每个顶点在纹理里查自己对应时间点的位置偏移，在顶点着色器里做位移。这样做的好处是不用骨骼、不用蒙皮、可以完全合批，同屏几百个单位能压到个位数的绘制调用。限制是动画不能动态混合（除非你手动烘焙混合结果），不能做运行时 IK，而且要额外占纹理内存。适合大规模杂兵、群众演员这类不需要精细表现的场景。

第二条是动画实例化方案，把相同动画的多个实例共享同一份骨骼数据，只保留各自的根变换，渲染时用实例化绘制。它比顶点动画纹理保留了骨骼结构，能做有限的状态切换，但要求所有实例播放同一个片段、同一个时间轴，所以只适合“整齐划一”的群体，比如列队行进的部队。

这两条路都有个共同前提：这部分单位必须和玩家可控单位分开管理，走独立的更新与渲染路径。混在一起管理会让代码复杂度急剧上升，而且优化收益会被稀释。我的做法是在场景里划分两个系统，一个管精细角色（玩家、精英怪、Boss），一个管群体单位，用不同的更新频率、不同的渲染路径，中间用统一的显示接口对接。这样即使群体系统整个替换掉，也不会影响精细角色那套逻辑。

6. 常见问题与排查实录

6.1 帧率突然掉一半，从哪查起

这个问题我被问过很多次。动画相关的卡顿，排查顺序我一般是这样走的：先看是不是所有角色同时进入了某个状态，再看是不是某个片段加载触发了同步加载，最后看剔除是不是失效了。

最常见的三个原因：第一，所有角色用了同一个相位做降频，导致每 N 帧集中更新一次，表现为规律性卡顿，解决办法就是 3.3 节的哈希相位；第二，某个动画片段没有提前加载，第一次播放时同步加载资源，卡一下之后就正常了，解决办法是把战场上会用到的片段全部预加载，或者在加载界面统一加载；第三，剔除判断失效，屏幕外角色还在全量更新，这种在性能分析器里表现为Animator.Update一直很高，但你看不出哪个角色在浪费，解决办法是加一个临时的调试面板，把每个角色的当前档位和屏幕投影尺寸打出来，一眼就能看到漏网的。

6.2 动画抖动与滑步的成因

抖动通常来自三个地方。一是降频更新但没有插值，角色在低频更新之间位置是跳变的，视觉上就是一顿一顿的，解决办法是对根变换做独立的高频更新，只对骨骼动画降频；二是状态机在相邻两帧反复切换，表现为剧烈的抖动，通常是过渡条件写成了“大于等于”和“小于”这种边界重叠，改成带一点回滞的区间就能解决；三是骨骼矩阵上传和渲染时序对不上，在 GPU Skinning 下偶尔出现，检查一下是否用了自定义 Shader 但没处理好蒙皮变体。

滑步是另一个高频问题，尤其是远端角色。成因是动画的位移速度和实际移动速度不一致。本地角色可以靠 Root Motion 对齐，远端角色没有输入，只能靠同步的速度值去调混合树。我的做法是在混合树里按速度分几档，每档对应一个动画播放速率（Animator.speed），让脚部落地频率和实际位移匹配。这个调参过程比较枯燥，需要一个档位一个档位试，但效果很直接，调完之后滑步感基本消失。

6.3 排查速查表

6.4 几条只有真做过才会知道的经验

第一条：不要等到人数上来再优化。多人战场的动画性能问题是非线性的，你在 20 个单位时觉得“还有余量”，到 60 个时可能就完全垮掉，而且垮掉的原因往往不是一个，而是三个因素叠加。我建议在项目早期就把 80 个单位的压力场景搭起来，每周跑一次，把性能曲线当成一个持续跟踪的指标。

第二条：优化参数要写进规范，不要靠记忆。骨骼数上限、蒙皮影响数、动画采样率、压缩误差、LOD 距离，这些值一旦定下来就写进美术和策划都能看到的文档里。我见过太多项目后期返工，原因是早期某个角色用了 120 根骨骼，后面所有角色都跟着“参考”它，等发现的时候已经做完了三十个模型。

第三条：降频和剔除一定要做可视化调试。在场景视图里用颜色标记角色的当前档位，绿色全量、黄色逻辑、红色冻结，再画一个圆表示各档半径。这个调试工具花不了两个小时，但能让整个团队直观理解性能预算的分配，沟通成本会大幅下降。

第四条：验收标准要包含“最坏情况”。多人战场的最坏情况不是“人多”，而是“人多并且同时触发状态变化”，比如一波 AOE 同时命中 40 个单位，全部进入受击状态、全部触发状态切换和特效。这个场景的帧率表现才是真正的验收标准，只测静态站桩是没有意义的。

我个人在实际项目里体会最深的一点是，动画优化做到最后，拼的不是技术手段有多花哨，而是对“哪些东西可以被省略”的判断力。每一次省略都要能回答一个问题：玩家在这个距离、这个视角下，真的能察觉到差别吗？如果不能，那就该省。这个判断需要反复看真机、反复对比，比堆参数、抄方案重要得多。