【性能调优】帧率掉落的排查路径：从现象到根因的固定套路

完整课程入口：996 全套课程体系 ｜ Lua 学习路径 ｜ 幂尔框架 mirs.cn

排查要有固定套路

"服务器卡了"——这类反馈信息量为零。掉帧问题排查最忌东翻西看，正确的做法是按固定路径逐层排除，每一层都有明确的测量手段。本文给出一套在 Lua 游戏项目里反复验证过的排查路径。

第一层：分清 CPU 还是 GC

掉帧只有两大来源：单帧逻辑耗时过高，或 GC 停顿。先做分离测量：在主循环关键节点打点，os.clock() 统计每帧纯逻辑耗时；同时每帧记录 collectgarbage("count")，掉帧时刻若伴随内存锯齿骤降，就是 GC 在回收大量垃圾——两者的解决方向完全不同。

逻辑耗时高 → 走第二层找热点函数；GC 高 → 走第三层找垃圾制造者。

第二层：热点函数定位

简易采样剖析器二十行代码就能写：用 debug.sethook(fn, "", 1e6) 每百万条指令触发一次，回调里 debug.getinfo(2, "Sln") 记录当前函数，跑两分钟统计命中次数 Top20。热点函数现形后逐个审查：循环里有没有全局变量查找（换 local）、有没有重复计算（提前缓存）、有没有可以合并的表访问。经验上，前三个热点修完，80% 的掉帧就消失了。

引擎自带的耗时监控若可用（线程耗时、触发器耗时统计），优先用引擎数据，它比 Lua 侧采样更接近真实开销。

第三层：垃圾制造者清单

GC 频繁说明每帧在制造大量临时对象。常见嫌疑按序排查：循环内字符串拼接（改 table.concat）；循环内创建闭包与临时 table（提到循环外复用）；高频调用 string.format/gsub（缓存结果）；事件派发时打包可变参数（包装成固定 table 复用）。每改一处，用内存曲线验证一次，避免"感觉优化"。

第四层：别漏了非 Lua 因素

逻辑层没问题还卡，向上查渲染（DrawCall 数量、纹理切换、UI 树深度），向下查 I/O（同步写日志、频繁读盘的配置加载）、查网络（主线程阻塞式请求）。掉帧时刻与"某个定时活动、某批玩家行为"相关的话，抓一下该时段的 GM 日志，业务脉冲往往就是元凶。

沉淀为资产

每次排查的结论写进团队 wiki：现象、测量数据、根因、修复方式。半年后你会拥有一份本项目专属的"掉帧套路库"，新人照单排查——性能工程的价值，一半在修复，一半在知识沉淀。

耗时统计

printusetime(play, on, off)

打印脚本总耗时(微秒)，帧率问题的第一步永远是量化，先看脚本耗时占比

printusetime(actor,1)

release_print(msg)

打印消息到控制台，把掉帧时间点与场景标记一起打出来

分帧与定时

setontimerex(id, tick)

添加全局定时器，把一次性大计算拆到多帧

setofftimerex(id)

移除全局定时器，统计周期结束时一定要摘掉定时器，否则本身就是新的掉帧源

ontimerexX(empty)

全局定时器触发(X=触发器ID)，定时器回调里做分片推进

日志

logact(play, logAct, loginfo, nParam1, nParam2, nParam3, nParam4, nParam5)

自定义日志，线上抓帧率数据用自定义日志，控制台输出仅限开发期