UE 网络最佳实践 FAQ

整理自 Unreal Dev Network（UDN）的 Networking Best Practices FAQ，是用 UE 网络功能、压榨网络性能时的一份经验清单。核心原则只有一句：能少发的数据就别发，过网的数据越少性能越好。

通用性能实践

• 尽量减少需要同步的 Actor 数量和属性数量。
• 对变化不频繁的 Actor 调低 NetUpdateFrequency。
• 尽量调小 Net Cull Distance，减少远处 Actor 的更新。
• 如果一个 Actor 里少数属性要高频同步、其余很少更新，考虑把它拆成两个 Actor：高频属性放一个，低频属性放另一个。
• 只在功能确实需要时才用 reliable RPC，能不可靠就不可靠。
• 可以考虑 Oodle 之类的第三方压缩，能省 20–30% 带宽，但需要购买授权。
• 避免在被同步的 Actor 上用 Child Actor Component，它们容易出同步问题。
• 时刻警惕 authority（权威端）：
  • 只在持有对象 authority 的一端修改被同步属性，否则改动会被覆盖或白做。
  • 对象只在它拥有 authority 的那一端 spawn。
• Replication Graph 对「海量同步 Actor」很有帮助，但对规模不大的项目收益有限。

延迟补偿（Lag Compensation）

在 favor-the-shooter（偏向射击者）模型下，这几招能减小延迟影响：

• 碰撞检测通常放客户端做，省服务器算力。
• 服务器只做简单校验（检查射程、角色位置等），防作弊兜底。
• 建议上第三方反作弊，压制客户端侧的漏洞利用。
• 客户端可以先 spawn 一个预测的弹道，等服务器同步回来的真实弹道到达再替换。

控制同步频率

默认情况下 Actor 按其 Replication Rate 频繁同步。对更新不频繁的 Actor，有几种降频手段，各有取舍——具体用哪种，要靠 network profiler 一例一例地测。

NetUpdateFrequency 设为 0：适合更新不频繁、但又频繁到不该关闭通道的 Actor。

• 不再自动发送更新，只能通过 Force Net Update 手动触发，省流量。
• 通道保持打开，后续手动更新没有额外开销。
• Actor 仍留在同步池里，每次仍要被检查是否需要同步。

标记 Actor 为 dormant（休眠）：适合将来可能再更新、但非常不频繁的 Actor。

• 休眠系统会关闭 Actor 的通道，把它移出同步池，放进单独的休眠池。
• 休眠后仍可发送更新，但有开销，应尽量少用。
• 单次更新可通过 Flush Net Dormancy 发送。

对 Actor 调用 TearOff()：适合此后再也不需要同步的 Actor。

• 彻底把 Actor 移出同步池。
• 之后很难再被同步，所以别用在「可能还会更新」的 Actor 上。
• 常用于客户端模拟的布偶（ragdoll）效果。

RepNotify vs. Multicast

大多数情况下 RepNotify 更优：

• RepNotify 支持中途加入（join-in-progress）。
• multicast 里的 RPC 不会发给新连接，所以不支持中途加入。
• RepNotify 走 delta state 压缩，发的数据更少。

网络测试技巧

• 用 PIE 的 dedicated-server 模式测试，更贴近线上环境。
• 用引擎内置的网络模拟设置（丢包、延迟、抖动），别只在完美网络下测。