事件的回调、策略的选择、状态的分支处理——每个点都建一张函数表太重,但每个点都写 if-else 又太散。闭包作为轻量的行为载体,在回调密度高的场景里,内存与灵活性的平衡点刚刚好。
---闭包回调:按需生成,随用随弃
local function makeHandler(evtType, cfg)
-- 闭包捕获配置,返回处理函数
return function(payload)
if payload.type ~= evtType then return end
if cfg.threshold and payload.value < cfg.threshold then
return
end
cfg.callback(payload.value)
end
end
---注册事件的处理
function Events.on(evtType, cfg, callback)
Events.bus[evtType] = Events.bus[evtType] or {}
table.insert(Events.bus[evtType],
makeHandler(evtType, cfg))
end
闭包作为回调的载体:捕获配置的上下文,返回的函数自带行为——不需要为每种事件定义独立的类或表结构。回调的注册按事件类型挂进总线,触发的分发直接调用闭包——分发的路径短,没有中间的查找与反射。闭包的轻量是有数据支撑的:一万个小闭包的内存开销在几百 KB 量级,与每个事件定义一个类的方案相比,内存的占用低一个数量级。
---闭包的注销:退订的成对管理
local subs = {}
function Events.subscribe(evtType, handler)
subs[evtType] = subs[evtType] or {}
table.insert(subs[evtType], handler)
return #subs[evtType] -- 返回订阅的句柄
end
function Events.unsubscribe(evtType, handle)
local list = subs[evtType]
if list and list[handle] then
list[handle] = nil -- 置 nil 即释放闭包
return true
end
return false
end
闭包的注销是内存安全的关键:订阅时返回句柄,退订时凭句柄清空对应的槽位——退订后的闭包没有任何引用,GC 自由回收。闭包与退订的配对纪律:注册接口返回句柄、退订接口接受句柄,两边的协议对称,泄漏的口子从接口的设计上封住。退订的自动化:界面销毁时批量退订该界面的全部订阅,成对的清理不用逐个手动调用。闭包捕获的上下文越大,泄漏的代价越高——捕获的纪律是只捕获必要的最小上下文,大对象通过参数传递而不是闭包捕获。
订阅与退订的配对断言:每个 subscribe 必须有对应的 unsubscribe,未配对的计数进告警;闭包数量的周期采样,只增不减的曲线是泄漏的信号。
退订的句柄曾经是索引值,中间的退订让索引错位,后续的退订删错了回调,句柄改为唯一的 ID。闭包捕获的大表曾经被序列化进存档,存档的体积暴涨,捕获的上下文排除不可序列化的对象。事件的重复订阅曾经没有去重,同一回调被注册两次事件触发两次,订阅的去重校验。
事件总线的订阅退订协议进编码规范,句柄的管理有模板。闭包的内存占比进性能的周报,异常的增长有数据的痕迹。退订的自动化与界面的生命周期绑定,框架层兜底内存的安全。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
实战应用:用在哪里 行会内部的物资交换长期靠喊话:谁有强效太阳水、谁收祝福油,喊话靠缘分看见。行会商会日把内部交易固定成市集…
实战应用:用在哪里 角色存档直接输出到展示接口时,内部字段(GM 标记、风控计数、内部编号)会被一并带出去,轻则泄露信息,重…
实战应用:用在哪里 排查一个玩家的异常行为,要在十几种日志里来回 grep,一次排查半小时起步。日志检索工具按角色名聚合所有…
实战应用:用在哪里 开服首日的问题七成是低级失误:礼包配置没发、传送点没开、公告没挂。开服检查单把首日开放前的三十项检查固化…
实战应用:用在哪里 祖玛阁深处有一间密室,墙上有四块浮雕,按正确顺序踩亮才能打开暗格,顺序每天随机。序列触发设计让解谜每日一…
实战应用:用在哪里 点击传送后站在黑屏里等五秒,是切图体验最差的来源:地图资源在传送确认后才开始加载,加载完才渲染。切图预热…