多人战斗中Lua持续高耗时，是瞬时峰值还是高频调用在作祟

作者：admin
/
时间：昨天 11:23
/
浏览：59 次
/
分类：厚积薄发

1）多人战斗中Lua持续高耗时，应优先排查什么
2）战斗后期温度和功耗下降，判断CPU是否降频

这是第497篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

UWA社区主页：community.uwa4d.com
UWA QQ群：793972859

本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。

实战案例

Q：在50V50的多人战斗测试中，帧率持续偏低，CPU耗时主要集中在Lua逻辑。进一步查看函数堆栈，发现部分函数存在持续高频调用，也有个别函数在单帧出现大量调用。面对这种情况，应该优先排查瞬时调用峰值，还是持续高频调用？

A：应结合函数的实际CPU耗时及其对帧率的影响确定排查优先级，而不能仅凭调用次数判断。对于持续低帧率，应优先关注长期占用较多CPU时间的调用路径；对于偶发卡顿，则应重点检查与卡顿帧对应的瞬时调用峰值。

从函数调用情况来看，主要存在两类现象：

持续高频调用：某条Lua调用路径从每帧100多次增加至300次以上，且相关节点耗时占比较高，需要检查是否存在不必要的重复更新；

瞬时调用峰值：另一条Lua调用路径在个别帧出现约24,000次调用，需要结合对应帧的实际耗时，判断是否造成卡顿。

建议重点排查以下两个方面：
1. 检查函数耗时与调用频率
沿调用堆栈定位主要耗时节点，结合调用次数判断问题是来自重复执行，还是单次执行耗时较高。例如部队寻路、路径更新等逻辑，检查是否需要每帧执行，能否改为按需更新。对于瞬时峰值，则应结合具体操作确认集中调用是否合理；

2. 检查Lua跨层调用
如果高频调用涉及Lua与C#或Unity API之间的交互，需要关注重复调用产生的开销，评估是否能够合并调用或集中处理部分逻辑。优化后，在相同测试条件下对比Lua函数耗时、调用次数及FPS，确认持续开销是否下降，同时检查是否仍存在明显的单帧卡顿。

需要注意，Development包及较多Lua函数打点可能引入额外开销，建议在相同采集条件下验证优化效果。

实战案例

Q：在长时间多人战斗测试中，CPU温度明显高于GPU，设备功耗也处于较高水平。但随着战斗进行，后半段的温度和功耗反而下降，部分CPU核心频率也出现波动。这是否意味着CPU发生了降频，应该如何判断？

A：温度和功耗下降既可能是业务负载减少，也可能与温控降频有关，不能仅凭曲线变化判断，需要结合CPU频率、各模块耗时和具体业务逻辑进行分析判断。

测试中，部分设备CPU温度比GPU高出十几度，设备功耗约为5W，后半段则出现温度、功耗下降及部分CPU核心频率波动的现象。

建议从以下三个方面排查：
1. 对照CPU频率与FPS

重点关注承担游戏主线程任务的CPU核心，检查其频率是否持续下降，以及同期FPS是否出现明显变化。需要注意，单个核心的频率波动不一定代表温控降频，也可能与正常调频或线程调度有关；

2. 对比相近负载下的模块耗时
CPU降频可能影响多个CPU侧模块的执行效率。在UI更新频率、粒子特效规模等业务条件相近的情况下，可以对比UI、粒子系统等模块的CPU耗时。如果多个模块的耗时明显增加，则需要结合设备热状态及线程调度情况，进一步判断是否存在温控或功耗限制；

3. 排查战斗过程中的业务负载变化
温度和功耗下降也可能是实际计算量减少所致，需要确认前后战斗状态是否发生变化。例如，部分战斗玩法存在伤兵机制，随着战斗推进，部分单位不再参与战斗，寻路、AI决策等逻辑的计算量随之减少，CPU负载也可能降低。

建议对照温度下降前后的参战单位数量及相关函数调用次数，确认是否存在明显的业务负载变化。

综合来看，温度和功耗下降不能直接认定为CPU降频，应结合CPU频率、FPS及相近负载下的模块耗时，区分硬件性能受限与业务计算量减少的影响，必要时通过相同业务负载下的对照测试进一步验证。