《Unity游戏优化》笔记(2)[21/02/03_周三][P20]

目录

1.2 性能分析的最佳方法 (P15)

---

请假回老家过年了。

1.2 性能分析的最佳方法 (P15)

良好的代码实践和项目资源管理通常使性能问题的根源查找变得相对简单，唯一的真正问题是如何改进代码。

许多代码并不总是以最干净的方式编写，我们肯定要时不时地分析较差的代码。有时被迫为了速度而实现一个笨拙的解决方案，我们并不总是有时间回去重构所有代码，以遵循最佳实践。实际上，以性能优化的名义所做的许多代码更改往往显得非常奇怪或晦涩难懂，常使代码库更难阅读。

软件开发的通用目标是使代码简洁，功能丰富且快速。实现3个几乎不可能的。

我们的目标是使用基准分析来观察应用程序，寻找问题行为的实例，然后使用指令注入工具在代码中寻找关于问题源自何处的线索。

如果简单地挑战并验证前面的假设，就可以更快的找到问题的根源。

一份任务清单有助于让我们专注于这个问题，而不是浪费时间去追逐所有的“幽灵”。

检查表：

• 验证目标脚本是否出现在场景中
• 验证脚本在场景中出现的次数是否正确
• 验证事件的正确顺序
• 最小化正在进行的代码更改
• 尽量减少内部干扰
• 尽量减少外部干扰

1.2.1 验证脚本是否出现

搜索脚本：t:<monobehaviour name>

将显示一个包含GameObject的短列表。

注意GameObjects是否仍然处于激活状态。

1.2.2 验证脚本次数

使用短列表方法来验证计数

防止这样的偶然错误对提高工作效率至关重要，因为经验表明，如果没有明确地不允许某件事，那么无论出于什么原因，某个地方的某个人就会在某个时候做这件事。这可能会花费一个令人沮丧的下午去查找问题，而最终发现那是人为错误导致的。

1.2.3 验证事件的顺序

Unity应用程序主要执行从本机代码到托管代码的一系列回调，Awake(),Start(),Update(),FiexedUpdate()

我们不能对调用相同类型的事件的顺序进行细粒度控制，无法确定调用的顺序。

Unity的日志器非常昂贵，如果使用开频繁，可能会导致一些不必要的性能峰值。更好的作法是，只针对代码库中最相关的部分进行有针对性的日志记录。

协程通常用于编写一些事件序列的脚本，它们何时触发取决于所使用的yield类型。最难调试/最不可预测的类型可能是WaitForSeconds yield类型。

在协调程序启动和结束之间调用的Update()回调数量是可变的。一旦协同程序启动，最好保持他的简单性和独立性，不受其他行为的影响。

1.2.4 最小化正在进行的代码更改

为了查找性能问题而对应用程序进行代码更改最好谨慎进行，因为随着时间的推移，更改很容易被忘记。Unity的调试控制台窗口日志记录在CPU和内存中都非常昂贵。

1.2.5 最小化内部影响

Untiy编辑器有它自己的小怪癖或者细微差别

1.如果一帧需要很长时间去处理，比如游戏出现明显卡顿，那么Profiler可能无法获取结果并记录在Profiler窗口中。

2.启动Profiler时不要忘记返回编辑器的Game窗口

3.垂直同步（或称为VSync）可能产生不必要的混乱，更难发现真正的问题。

4.确保性能下降不是因为大量的异常和错误消息导致的。就算隐藏不同日志级别类型，也需要CPU和内存来执行。启用所有日志选项是一个很好的实践。

1.2.6 最小化外部影响

应该再次检测没有后台进程（或者其他应用程序）消耗CPU周期或占用大量内存。