UE5 Debug的一些心得

1、BUG粗略可分为两类：

一种是显性的，编译直接就通不过，必须马上解决。

第二种是隐性的，新功能完成后，编译成功顺利运行，洋洋自得，而问题隐藏在幕后，测试之后才逐渐发现有问题，

从代码角度是没毛病的，没报错，但不符合设计需求。

而随着工程复杂度的上升，找问题，甚至快速看懂以往的代码都变得越来越困难，尤其是逻辑很复杂的系统，有注释的话好一些。这也拖慢了DEBUG的速度，连发现BUG在哪里都是个难题。

2、低级错误。就个人而言，以往的BUG中有很大概率最终发现是低级错误，

比如功能相似的变量或BP命名相似，结果用错了，则必然不符合需求。

查了一圈都没毛病，最终才发现是用错了，如果早点发现，则节约大量时间。

从命名上就要规避，要区分开来。

没用的要删掉，或名字改为冷门的，以减少误操作。

比如修改过程中某个分支判断的真假接反，也会导致不符合需求，密密麻麻一大堆而屏幕显示内容少加大了失误概率。

3、地方不对。虽然理论上放哪里都行，但实际上重要逻辑放在UI，或物件里，则就容易出问题，虽然不报错，但达不到效果。

而放在FPC、GM等重要地方就能发挥作用，换个地方就不行。

原因之一就是物体与UI很可能一开始并没有加载，所以相关参数也无法传出去，逻辑是废的。

---------------

11、1月中旬版本里出现突然的卡顿，

经过多日的排查，最终发现是gate定时器没有暂停导致，

重复刷东西，导致大量堆叠，大量特效堆叠，且没有定时反激活，二者合在一起导致卡顿。

所有定时器都需要检查，如果Actor没有销毁，就一定要定时暂停定时器。

特效也需要检查，要定时反激活。

12、Tick相关优化

尽量用定时器，而不是Tick。很多逻辑可以拆出来到定时器里。

如果用Tick，需要加时间限制，默认无限制，改为0.034=30帧，节约CPU算力。

很多不需要频繁更新的逻辑，0.1、0.3就足够了。

虽然大部分时候都是GPU拖后腿，CPU一般都是10-30的负载，并不高，

但有时候GPU负载不高时也照样卡顿，可能就是逻辑缺乏优化导致。

13、代码查重

初期版本开发的逻辑，由于技术不熟练，或考虑欠长远，到后面就会引发一些逻辑重复，需要定期检查与去重。如HP导致游戏失败的相关逻辑，后来统一放在GM里。

14、新功能导致的问题

加入新功能时，可能为了图方便，直接修改主逻辑，而导致原来的内容出问题，如模式1。

一些地方需要特殊处理。

复杂度的上升，出错概率大增，考虑不周导致。