做 UE 角色动画蓝图做得多了，你会发现一个特别扎心的现象：角色动得越丰富，AnimGraph 里的节点连线越像蜘蛛网，跑起来也越肉。明明只是加了一个瞄准叠加、一个换弹蒙太奇、一个上下半身混合，帧率就能掉下去一截。这个问题的核心，往往不在美术资源，而在于同一个状态机输出在动画蓝图里被引用了好几遍，每一遍都在重复计算。今天要聊的，就是专门用来解决这类重复计算的“缓存姿势”（Cache Pose）节点，以及我拿它实战优化一个角色蓝图的全过程。这篇内容更适合两种人：正在跟动画蓝图性能较劲的 UE 开发者，以及刚学会状态机、想搞清楚下一步怎么优化性能的新手。
1. 先从性能账算起：为什么“复用”不等于“免费”
1.1 动画蓝图里那条“看似共享”的连线
很多人在 AnimGraph 里接线都很随意：一个状态机输出引脚，拖三根线出去，分别接到瞄准叠加、蹲伏混合、蒙太奇插槽。看起来是一个输出被三处复用，心里想的是“同一个姿势我只算一次，剩下的都是引用，应该不贵吧”。但在引擎的实际评估流程里，路径并没有那么简单。动画蓝图虽然是一个有向图，很多节点也需要按序评估，但如果一个节点的输出被多个下游节点需要，而这个节点本身又没有做缓存，那下游每个节点在求值时都可能触发上游链路重新计算一次。换句话说，你看到的一条线，在每一帧可能被走了好几遍。
我当时在一个模拟项目的角色蓝图里，移动状态机输出被接了三个地方，打开性能分析一看，这个状态机每帧被求值了三次，每次内部还要处理两三个状态的混合、过渡条件、曲线更新。三次加起来，比整个 AnimGraph 其他所有节点还贵。这其实属于很典型的“复用陷阱”：连线复用只是拓扑层面的复用，不是计算层面的复用。
1.2 缓存姿势解决什么问题
缓存姿势节点（Cache Pose）就是为这种场景准备的。它的工作方式很直接：节点把自己的输入姿势在第一次被求值时存成一份快照，同一帧内后续再有别的节点引用它，直接读取快照，不再往上游跑。这样，移动状态机每帧只需要真正求值一次，后面接三个、四个消费者都只拿快照。
打个不太严谨的比方：状态机是厨房，Output 是刚出锅的菜。你以为把同一道菜的菜谱发给三个客人，就能一次做好三份；实际上如果没有缓存，厨房会按照菜谱重新炒三遍。Cache Pose 相当于提前把菜盛好放在保温柜里，谁要就直接端，不用再开火。
当然它缓存的是“整个姿势”，不是某个骨骼或某个混合的局部结果。所以使用场景很明确：当同一个子图的输出要被多个下游节点引用，而这个子图本身的求值成本又不低时，用 Cache Pose 包住它最合适。
2. Cache Pose 节点入门：位置、用法与命名
2.1 在哪找节点，怎么连
如果你还没用过这个节点，操作步骤其实很少：
- 打开动画蓝图 AnimGraph。
- 在节点搜索框输入“Cache Pose”，拖入图中。
- 把它连到需要复用的姿势链路上。一般来说，是放在某个状态机输出之后、后续分支开始之前。
- 选中节点，在细节面板中重命名。我习惯用“CachePose_”做前缀，比如 CachePose_BaseMove。
- 把原本从状态机输出接出去的线，全部改接到这个 Cache Pose 的输出引脚上。
这里有个容易被忽略的点：Cache Pose 不是一个“自动替换所有引用”的开关，它只是一个需要手动接入的节点。你必须在接入后，手动把下游节点的输入引脚重新连接，否则原来的连线还指向旧节点，缓存没有覆盖到。
2.2 Cache Bone 与 Cache Pose 的分工
很多教程会把 Cache Bone 和 Cache Pose 一起提，但两者的粒度完全不同。Cache Pose 缓存的是整个姿势结果，适合缓存状态机输出这种大块头；Cache Bone 缓存的是骨骼空间里的某个骨骼变换，通常用在多个 IK 节点、多个后处理节点都要读取同一块骨骼数据时。实际项目里两者可以组合用：Cache Pose 缓存基础移动，Cache Bone 缓存手部骨骼，再分给不同 IK 求解器。需要记住的是，二者都是“同一帧内的复用”，不是跨帧缓存。
2.3 为什么命名和注释不是小事
我在真实项目里踩过一个很浪费时间的坑：优化完的动画蓝图里放了三个 Cache Pose，名字全是默认的“CachePose”，没人知道哪个缓存的是基础移动，哪个缓存的是瞄准姿势。结果 UI 调到一半找错了节点，改了缓存内容，角色动画变得莫名其妙。从那以后我给自己定了两条规矩：第一，所有缓存节点必须用业务语义命名，比如 CachePose_BaseMove / CachePose_AimPose；第二，在 AnimGraph 里用注释框把缓存区框起来，写上类似“CACHE：基础移动，只计算一次”的说明。这样过几个月再回来维护，哪怕只看了注释框也能立刻恢复上下文。
3. 实战：用缓存姿势改造一个角色蓝图
3.1 优化前：找出重复开销
拿我当时处理的模拟项目举例。角色有地面移动状态机，包含站立、走路、跑步三个状态，每个状态里都做了上下半身混合；角色肩膀上还有一把武器，需要瞄准叠加；另外有换弹动画和蹲伏覆盖。原始 AnimGraph 的接法很常见：移动状态机输出同时被三个节点引用，分别是 Layered Blend Per Bone、Blend by Bool、Slot 蒙太奇插槽。
优化前我先做了一次性能定位。使用的工具是 Unreal Insights：
- 进入 PIE 模式，打开 Insights，勾选动画相关 channel；
- 让角色循环播放一段包含走路、跑步、瞄准、蹲伏的动作；
- 抓帧后进入 Animation Insights，查看 AnimGraph 总耗时和节点耗时分布。
结果很清楚：AnimGraph 每帧总耗时 2.6ms 左右，其中移动状态机相关的重复求值占了很大比重。这个数据一出来，改方案就变得顺理成章：给状态机输出加缓存。
3.2 确定缓存位置
确定缓存位置的原则是：缓存放在被多个消费者共享的“公共上游”之后。对当前蓝图，公共上游是移动状态机，消费者是三个下游节点，所以缓存尽量贴近状态机输出，但不要包到状态机内部。改完之后，节点逻辑变成这样：
StateMachine_BaseMove -> CachePose_BaseMove -> LayeredBlendPerBone（上半身瞄准叠加） -> BlendByBool（蹲伏/站立切换） -> SlotNode（换弹等蒙太奇）文字描述一下：移动状态机每帧只求值一次，输出写入 Cache Pose；后面三个分支分别读取这份快照。Layered Blend Per Bone 用 CachePose_BaseMove 作为基础姿势，再叠加上半身瞄准；Blend by Bool 根据动画蓝图里的 bool 变量决定输出蹲伏还是默认跑动姿势；Slot 节点则负责播放换弹这类蒙太奇。
3.3 改造后的接线方法
先看 Layered Blend Per Bone。把这个节点拖进 AnimGraph 后，需要指定分支骨骼，比如手臂骨骼，然后设置叠加姿势的来源。这里把 Local Pose 输入接到 CachePose_BaseMove，叠加姿势接瞄准相关的姿势序列或 AimOffset。这样每次手臂被叠加时，拿到的底座是这份缓存快照，而不是让状态机再算一次。
再看 Blend by Bool。它是根据条件二选一的节点，布尔输入可以接动画蓝图的变量，比如 bIsCrouching。True 分支放蹲伏动画，False 分支放 CachePose_BaseMove。使用缓存后，当角色蹲下再站起来，基础移动状态机不会被重复跑，只有选择结果在变化。
最后是 Slot 节点。Slot 节点的作用是播放动画蒙太奇，比如换弹、挥手。把 Slot 的输入接到 CachePose_BaseMove，蒙太奇播放时会临时覆盖基础姿势；蒙太奇结束，又回到缓存的移动姿势。这里顺序上我一般把 Slot 放在 Layered Blend 和 Blend by Bool 之后，也就是到输出姿势的最后一步，避免蒙太奇播放时被后续混合节点再叠一层。
改完之后的实测数据（本机场景，仅供参考）：
| 指标 | 优化前 | 优化后 |
|---|---|---|
| AnimGraph 每帧耗时 | 2.6ms | 1.1ms |
| 移动状态机求值次数/帧 | 3 次 | 1 次 |
| 游戏线程帧率 | 85fps | 102fps |
3.4 一个容易踩的坑：缓存层级不对
有一个很常见的错误做法，是把 Cache Pose 直接塞进状态机内部，比如在走路、跑步每个状态里都放一个 Cache Pose。这会让状态机内部的混合和时间采样变得混乱，尤其是过渡动画播放时，不同状态可能各自保留自己的缓存快照，结果看起来像角色“卡顿”或“瞬移”。正确做法是把缓存放在状态机输出之后，状态机内部的逻辑保持原样，让它正常处理状态切换，输出的结果由缓存统一接管。
4. 常见问题与排查技巧实录
4.1 加了缓存后动画“定住”了
这是初学者最容易遇到的。现象是某个动态效果，比如换弹蒙太奇、面部表情变化，加了 Cache Pose 后不再播放，像被冻结在某一段。排查思路很简单：看看这个动态分支在拓扑上是不是被缓存包住了。如果 Slot 节点本身位于 Cache Pose 的上游或内部，那么缓存快照里记录的只是第一帧求值结果，后续动态播放当然不会更新。解决方式是把 Slot 等重要动态节点移到缓存外部，用 Cache Pose 只保存静态底座。
4.2 加了缓存后反而更卡
我也遇到过反向效果。原因通常有两个：第一，被缓存的子图本身太简单，求值成本很低，但 Cache Pose 节点本身也要维护缓存，得不偿失；第二，被缓存的子图包含大量动态骨骼修改、物理模拟、IK 求解，这些内容即使在缓存内也仍然需要每帧更新，缓存并没有减少实际开销，反而增加了额外管理。判断方法仍是用 Profiler：如果加了缓存后节点调用次数没有明显下降，或者 Animation 总耗时没有下降，就说明缓存位置不对或粒度不对。
4.3 状态机过渡表现异常
表现是角色从走路切到跑步时，过渡动画出现“迟滞”或“不连续”。排查后一般会发现，问题不在 Cache Pose 本身，而是把它放得过于靠近状态机内部，干扰了过渡时间的采样。状态机内部有自己的一套时间推进和混合机制，缓存不应该打断这个过程。安全做法是把它放在状态机输出端，并且不要在过渡相关链路上共用两个不同的缓存名。
4.4 版本和调试工具差异
Cache Pose 在 UE4.26 到 UE5 系列里行为一致性还不错。调试时我推荐优先用 Unreal Insights 的动画通道，比控制台命令更直观。控制台命令也可以配合用：
stat anim：观察动画系统整体耗时；stat unit：看游戏线程、渲染线程、GPU 的帧耗时。
需要提醒一点：在 Debug 状态下动画蓝图可能走不到最优路径，数据会比运行版本偏高，所以对比优化效果时要用同一套场景和同一套配置，否则很容易误判。
4.5 常见问题速查表
| 现象 | 可能原因 | 排查建议 | 解决方案 |
|---|---|---|---|
| 动态动画被冻结 | Slot/动态混合被包进缓存内部 | 检查拓扑关系 | 把动态节点移到缓存外 |
| 性能没有下降 | 缓存粒度不对或子图太简单 | 抓帧对比调用次数 | 取消缓存，或调整边界 |
| 过渡动画异常 | 缓存放在状态机内部 | 查看状态机内部连接 | 移到状态机输出之后 |
| 找不到对应缓存 | 节点命名不清晰 | 检查细节面板 | 统一命名，加注释框 |
5. 从缓存姿势到动画蓝图整体性能调优
5.1 Cache Pose 和 Cache Bone 组合使用
在比较复杂的人形角色里，上下半身往往有不同的逻辑。比如角色持枪瞄准时，上半身要做瞄准叠加，下半身要保留移动状态。这种情况下，移动状态机的输出用 Cache Pose 缓存一份；同一帧里，如果上半身多个节点都要读取手臂骨骼变换，再配合 Cache Bone 缓存手臂骨骼。这样整条主链路只求值一次，骨骼缓存又减少了 IK 和多路后处理之间的重复读取。两者不是替代关系，而是配合关系。
5.2 一帧内缓存与跨帧更新的界限
需要反复强调的是，Cache Pose 缓存的生命周期只有一帧。它解决的是“同一帧里多处引用导致重复求值”的问题，不是“让某个姿势在后续帧里都保持不变”的问题。如果你希望角色在远处降低动画更新频率，那是另一套机制，比如骨骼网格体的更新策略或 LOD。不要把两者混在一起理解。我之前见过有人试图用 Cache Pose 做跨帧帧率优化，结果角色动作变得断断续续，这就是用错了工具。
5.3 什么时候不值得用 Cache Pose
不是所有 AnimGraph 都需要加缓存。如果某个子图只有一个下游消费者，或者子图本身是单个 Pose 节点，加上 Cache Pose 基本没有收益，反而增加节点数。更好的做法是先跑一遍 Profiler，找到引用次数高、耗时占比大的子图，再有针对性地加缓存。我在实际优化中通常先保留一张原始的拓扑截图，然后每加一个缓存节点，就在性能数据里做一次前后对比。这样做几次之后，就能积累出比较清晰的使用直觉。
最后分享几个偏个人的体会。第一次用 Cache Pose 时，我图省事，把一个 Slot 所在的整段链路都包进了缓存，结果所有蒙太奇都不播了，排查了将近两个小时才发现是拓扑位置的问题。后来我习惯在动手之前先画一张简单的数据流图，把“哪个姿势需要复用、哪些节点必须动态更新”标清楚，再进 AnimGraph 接线。另一个比较实用的习惯是给所有缓存节点统一加“CachePose_”前缀，并把它们放在同一个注释框里，注释框里写上“此区域只计算一次，改动需谨慎”。这套做法不仅让自己少踩坑，也方便后来接手的同事一上来就能看懂整张图。如果你现在正好被动画蓝图性能问题卡住，建议不要急着删节点或优化美术资源，先抓一帧性能数据，看看是不是同一个状态机在反复求值。很多时候，一个 Cache Pose 放在正确的位置，就够用了。
