【性能调优】移动同步与位置校验：AOI 视野内的广播节流

实战应用：用在哪里

玩家移动的同步是网络层最频繁的消息：每秒几十次位置更新，乘以在线人数就是巨大的广播量。位置同步的优化核心是"聚合 + 裁剪"：客户端本地预测移动、服务端按节拍聚合广播、接收端按 AOI 过滤。

广播聚合与节流

服务端不为每次移动立即广播，而是按节拍（每 200ms）聚合同一玩家在该窗口内的最终位置，向 AOI 视野内的玩家广播一次。移动的连续性由客户端插值补足：

-- 每 200ms 的聚合广播
local moving = {}
for uid, sess in pairs(movingPlayers) do
    moving[#moving + 1] = { id = uid, x = sess.x, y = sess.y, dir = sess.dir }
end
if #moving > 0 then
    Broadcast.map(mapId, { type = "move_batch", list = moving })
end

批量消息把 N 次移动合并为一条批量消息，包量下降一个数量级。客户端插值的精度损失用服务端的周期校准补偿（每秒一次精确坐标同步）。

校验与异常处理

位置更新前做三道校验：速度上限（位移/时间差超限拒绝）、阻挡检测（目标点不可达拒绝）、边界裁剪（越界按边界截断）。校验失败的移动请求不广播、不更新坐标，只回一条纠偏消息让客户端拉回——异常处理的目标是让客户端状态收敛到服务端状态，而不是互相覆盖。

实测与调参

某 996 服同屏 100 个移动实体的实测：逐次广播每秒 3200 包，聚合后 460 包（降 86%），客户端的表现差异肉眼不可见。调参的两个旋钮：聚合窗口（200ms）与插值系数（客户端的平滑程度），窗口越大包量越少但同步延迟越高——按玩法类型权衡（战斗场景 100ms、挂机场景 500ms）。

移动包的丢失容忍：位置同步是可丢消息（下一条同步会覆盖），UDP 类传输下丢包不做重发，TCP 类传输下靠聚合降低单包体积。移动同步与关键消息（交易、发放）分通道传输，关键消息的可靠性要求高，移动消息的时效要求高——分通道后各自的参数独立调优，互不拖累。

本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付，内容以官方知识库与真实项目为出处，按版本持续修订。