蓝图性能：从慢到不慢

蓝图不是"天生慢"，但它的写法自由度高，容易写出 hotspot。这一节讲怎么让热点蓝图不拖帧。

蓝图为什么慢（以及什么时候不慢）

  • 现代蓝图（UE5）的 VM 执行已经很快，普通业务逻辑不是瓶颈；
  • 真正的代价在：大量对象 × 高频事件（每个 Tick 跑）、循环里做重活、类型操作（Cast）与容器分配。
操作 相对代价 建议
简单属性读写 极低 放心用
数学运算（向量） 低 没问题
Cast 中 减少次数，缓存结果
数组操作（Add 含分配） 中 热点处预分配
在 Tick 里 ForEach 大数组 高 改 C++ / 降低频次
蓝图 nativization（C++ 转译） — 开发期可用；部署建议直接 C++

热点治理四步

  1. 找：stat dumpTicks / Insights 找出蓝图 Tick 的耗时榜；
  2. 降频：能改间隔先改间隔（成本最低）；
  3. 去 Cast：Tick 里反复 Cast 同一个对象 → 缓存一次；
  4. 下沉：最热的那个函数用 C++ 实现同名接口（蓝图层无感）。

蓝图的调试与测量

  • 蓝图编辑器自带性能分析：右键节点 → "查找性能问题" / 慢节点高亮（Script Profiler）；
  • 蓝图调试面板可看执行栈，配合慢节点定位；
  • stat blueprint 看蓝图 VM 的整体开销。

见过最夸张的案例：一个 UI 蓝图每 Tick 执行 200 次字符串拼接生成任务文本，占游戏线程 3ms。改成"数据变化时才更新文本"后降为 0ms。蓝图的问题往往不是语言，是调用频率。