VIP 等级变化时,头顶徽章、属性面板加成、特权列表三处界面要同时刷新。分散刷新的写法容易漏一处,事件驱动的联动刷新让属性变更自动推给所有订阅的界面,一处触发、处处更新。
-- 服务端推送 VIP 变更
function pushVipChange(actor, level)
sendluamsg(actor, 7500, level, 0, 0, "vip")
end
-- 前端订阅 VIP 变更事件
SL:RegisterLuaNetMsg(7500, function(p1)
SL:onLUAEvent("VIP_CHANGED", { level = p1 })
end)
服务端的 sendluamsg 推送等级变化,前端收到后转发成内部事件 VIP_CHANGED。内部事件的订阅者各自响应:徽章控件换贴图、属性面板改加成数字、特权列表刷新状态,三个界面互不知道对方存在。
-- 徽章控件的订阅
SL:RegisterLUAEvent("VIP_CHANGED", "badgeLayer", function(data)
local badge = GUI:Image_Create(badgeLayer, "vipBadge", 10, 10, "vip_" .. data.level .. ".png")
GUI:Image_loadTexture(badge, "vip_" .. data.level .. ".png")
end)
-- 属性面板的订阅
SL:RegisterLUAEvent("VIP_CHANGED", "attrPanel", function(data)
GUI:Text_setString(attrText, "VIP" .. data.level .. " 加成生效中")
end)
订阅接口(RegisterLUAEvent)带来源标签,界面销毁时按标签注销(UnRegisterLUAEvent),泄漏的订阅在窗口重建后会重复触发。事件的发布与订阅的解耦:服务端推送只发一次,前端几个界面订阅就有几个响应,扩展一个新界面不需要动发布方。徽章的贴图按等级命名,等级变化的贴图热切换让升级的瞬间有可见反馈。
事件的发布数与订阅响应数对账,响应数少于订阅数即为订阅泄漏的信号。
事件名的拼写不一致曾经让订阅收不到发布(VIP_CHANG 与 VIP_CHANGED),事件名的常量表统一管理。订阅的注销遗漏在快速开关面板的场景高发,注销的配对检查进了界面基类的销毁流程。
前端事件的命名规范与后端协议的命名规范同构,跨端的对照表降低联调成本。事件驱动的刷新替代轮询后,CPU 的空转开销下降一个数量级,性能与架构的收益重合。联动刷新的测试用例覆盖所有订阅方,新增订阅方必须补进回归清单。
本文由 996 技术组基于 996 引擎官方知识库与浮生梦老师课程体系整理。团队长期从事传奇类引擎 Lua 后端逻辑、客户端界面与商业版本交付,内容以官方知识库与真实项目为出处,按版本持续修订。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
设计初衷 付费玩家不是一个人群,是四层结构各异的群体:白嫖党、月卡党、中产党、大R党。大R(月消费 3000 元宝以上)贡献…
设计初衷 传送是全服使用频次最高的功能(人均每日 6.2 次),也是最没有存在感的收费点——玩家对它的态度是"顺手付了"。定…
底层原理 弱值表(__mode = "v",值被弱引用)之外还有弱键表(__mode = "k",键被弱引用):键不被表挽留…
设计初衷 战法道互相克制是传奇的魂:战士近身爆发(烈火剑法)、法师远程群攻、道士续航消耗,三角循环转起来才有博弈。胜率失衡的…
业务场景 基础仓库 40 格,裁决之杖收藏家们叫苦不迭。扩容方案:每页 10 格、最多扩 4 页到 80 格,第 1 页 1…
底层原理 math.random 不承诺完美均匀,而爆率、抽奖、抽签全部建立在"均匀"假设上。均匀性是可检验的:n 个桶各掷…