客户端每秒收到几十条网络消息,每条消息要找到对应的处理函数:路由表的实现方式决定分发的性能。散列路由表(消息号直接索引处理函数)把单条分发从遍历的线性成本降到哈希的常数成本,消息洪峰下的帧率稳定依赖这个设计。
---协议号的路由表
local handlers = {}
function MsgDispatch.register(msgID, handler)
handlers[msgID] = handler
end
function MsgDispatch.dispatch(msgID, payload)
local h = handlers[msgID]
if h then
local ok, err = pcall(h, payload)
if not ok then
SL:Print("消息处理异常 " .. msgID .. ":" .. tostring(err))
end
else
SL:Print("未注册的消息号 " .. msgID)
end
end
路由表的键是协议号,值是处理函数,注册与分发都是 O(1) 的哈希操作。pcall 包裹每个处理函数,单个消息的处理异常不中断后续消息的处理,异常的日志带协议号方便定位。未注册的消息号打日志而不是静默丢弃,协议的遗漏在开发期就能发现。
---同帧多条消息的合并处理
local pending = {}
function MsgDispatch.queue(msgID, payload)
pending[#pending + 1] = { id = msgID, p = payload }
end
function MsgDispatch.flush()
for _, m in ipairs(pending) do
MsgDispatch.dispatch(m.id, m.p)
end
pending = {}
end
同帧到达的多条消息先进队列,帧末统一 flush 分发,分发的高峰被削平。消息的优先级分层:战斗相关的消息插队处理,聊天与特效类的消息排队,优先级让战斗的响应不受聊天洪峰的影响。处理函数的注册在界面初始化时完成,未销毁界面的处理函数在界面销毁时注销。
分发的耗时分布监控,单条分发的耗时超过 5 毫秒即告警,处理函数的粒度要求轻量。
路由表的遍历兜底曾经处理了未注册的消息号,消息号的拼写错误被静默吞掉,未注册的告警日志让协议的遗漏显形。pcall 的错误信息曾经不带协议号,排障时无法定位是哪条消息的处理出错,错误的上下文补充协议号与载荷摘要。
路由表的注册与注销在界面基类里统一管理,界面的销毁自动注销其消息处理,泄漏的处理函数是内存与逻辑的双重隐患。消息的载荷校验:处理函数对载荷的字段做类型断言,坏数据在入口报错而不是在深处的业务逻辑里爆。性能的基线:单条消息的端到端处理(网络到达到界面更新)控制在 16 毫秒内。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 师门贡献是师门商店的流通货币,它的获取速率直接决定师门玩法的生命周期:速率太快,师门商店两周被搬空,玩法速朽;太慢…
设计初衷 开服三个月后老玩家数值翻倍,新玩家进服面对的是一堵墙:任务打不动、组队没人带、排行榜望不到顶。世界等级是全服动态难…
设计初衷 扫荡券解决的是成熟玩家的重复劳动:第 40 次打同一个副本不是挑战是打卡。但扫荡定价是个精细活:太便宜,手玩变成纯…
底层原理 模块的可变状态直接暴露在表字段里,任何代码都能改——红名单被误写、计数器被清零,都是“公开可写”惹的祸。闭包隔离的…
底层原理 正排索引回答“这个玩家有什么”,倒排索引回答“谁有这个东西”。运营场景里反查需求极高频:排查裁决之杖的流通去向、回…
底层原理 柯里化把“多参数函数”变成“逐个喂参数的函数链”:f(a, b, c) 变成 f(a)(b)(c),每一步返回一个…