供游戏性程序员的使用的性能最优化方法

概述

为追踪虚幻3游戏的内容或特定的游戏表现,有一系列有帮助的工具. 一个被用于 Infinity Blade Dungeons 的开发的方法描述于此。

广泛性能调查

首先要跑一遍游戏然后确定哪些是拖慢速度的。 最快的办法是把 STAT UNIT 设置为开启的状态来看看游戏，渲染或GPU是否速度慢。 如有可能应在 测试 版本上运行。 GPU时间可能无法看，但如大于另两项时间可假设等同于总体框架时间。如有质检团队的报告并分配给相关部门则更好。 一需包括在报告内的有用信息包括：

• Average FPS(平均FPS) - 原始平均fps，有时不包括动画或非互动环节。 这里的原始数字并不特别重要，只要运行数值高于vsync（一般为30），但可用来察看趋势。
• % over 30(超过30FPS的百分比) - 超过30fps的时间。 应尽可能高，一般要达到95%或更高。
• Total Hitches(总顿卡数） -花费时间超过100ms的帧数。这个值要尽可能低。
• % Bound by Game and Render（游戏和渲染绑定百分比） - 哪些慢帧是由游戏或渲染线程造成的。 如果这些值非0，您应该查看一下是如何造成的。 GPU绑定使用的百分比一般看不到，但如果其他两个绑定的百分比数字较低，即使高于30%也属于低的范围，GPU处理用时过长是很可能的原因。

游戏和渲染性能

有两个工具可用来追溯游戏和渲染缓慢的原因： Gameplay Profiler 和 Stats Viewer .The Gameplay Profiler(游戏性分析器） 是用来分析游戏线程的最佳工具，Stats Viewer（统计数据查看器）则是用来分析渲染线程的工具。 为获得最准确结果，两个工具都应在游戏的 发布版本 上运行。 为收集需要分析的运行数据，您可以按照UDN的页面上对每个工具操作的步骤来进行，或者由质检团队来按照上述进行设置来运行分析。 他们一般会注意到以毫秒为单位的用时最长的帧。注意帧时再由这些工具计算时并夸大了大约25%，所以不要担心35ms的帧，它们实际上在测试/发行时是30fps. 他们会为Gameplay Profiler(游戏性分析器)创建一个 .gprof 文件的目录并为Stat Viewer（统计数据查看器）创建 .ustats 文件。 您可以随后使用合适的工具来打开它们（一般双击即可,可能需要关联文件)

游戏线程分析

如果您开着 .gprof 文件，您可以开始使用 Gameplay Profiler 查看相关问题。 一种方法是在上方图表中深入挖掘缓慢的帧。 点击一个慢帧，并察看 Frame Actor / Class Call Graph 标签及 Frame Function * 标签。 红色文本是统计信息，绿色文本是脚本调用和更新时间。

使用这些标签，您应该能确认某个特定函数调用是否缓慢，或某个actor或actor们的类是否更新迟缓。 如果看上去actor更新或脚本函数不慢，那么使用标签 Frame Function Summary 来看一下哪个统计调用占用了所有的时间，并看一下帧函数调用图表来确定哪个统计一直运行在层中。 当您能确认那个造成缓慢的统计后，您可以搜索源看一下所用到的字符串，然后找到该统计及使用该统计的代码。 这可能会给您一个提示，或者您也可以向引擎团队寻求帮助。

另一个优化的办法是尝试整体缓慢的函数和对此函数进行整体最优化。 要达到这个目的，查看 Aggr function summary 和 Aggr function call graph 就很好。

您可以选择单独的统计或函数并且它会在上面的图表中以红色标记该区域的哪些帧是慢速的。 一般来说在此处可使用 Exclusive time 来排序，或者使用 World Tick Time 来看最大值，因为这个值包含了所有其他的更新。 当您看到自己感兴趣的区域时，您可以点击停顿该区域的某一帧并尝试深入查看是哪个统计或函数造成了该特定帧的慢速。

渲染线程分析

Stats Viewer 可以让您看到渲染线程，最小的更新和脚本时间的相似信息。 当您打开 .ustat ，您会在右侧看到图表，左侧看到一系列过滤器。 如果您怀疑某个统计，您可以选择它查看该统计图表，但如果查看单独帧将会容易一些。 右键点击右侧的帧并选择 Open call graph 。 这可以查看单独的帧并让您查看变慢的元素，标记为红色。 当您看到一处后，您可以把它添加到总体图表中来看一下该统计造成游戏变慢的频率有多少。

常见性能问题

这些通用工具可用来追溯问题，能知道过去有哪些东西拖慢将会对您很有帮助。 下面是一份列表，列举了去年里遇到的问题，您的操作可能有所变化：

• Platform specific issues(平台特定问题） - 这些往往表明游戏或渲染的大量统计时间没有任何更多可用的细节。 这包含了着色器编译，声音问题，内存延迟等。一旦您确认了哪个统计确认了迟缓时间，您可以使用平台特定的本地分析器或与引擎团队讨论来获得额外的帮助。
• Script call overhead（脚本调用内存消耗） - 这条在游戏分析器中会很快出现，也很容易通过调整游戏逻辑或移动特定慢速函数到本地来解决。
• GC Time - GC Mark 和 GC Sweep 经常在游戏分析器/统计数据查看器中呈现为大的周期性的延迟. 如果在release（发行）模式下运行而没有 -NoVerifyGC 则该延迟会变得大得多，所以先要看那个值。 这些是不可能完全消除的，但是最优化GCable对象数量是主要目标。把更多的东西移入启动包并减少对象计数是很好的目标。
• Pathfinding and line checks（寻路和线性检测） - 寻路调用和线性检测经常在游戏线程中表现缓慢。 最优化此处的最容易的办法是少做一些。在游戏代码中要注意多余的寻路调用或线性检测。
• DLE Tick time（动态光照更新时间） - 在一些场景中动态光照效果的更新时间往往很高。确认只给实际需要的对象做动态光照环境，并对不需要动态光照的任何为actor放置的动态光照环境复位 bDynamic 。 在手机平台上，您可能需要进一步的优化，比如对您想要做lightmass效果而不想要动态对象的灯取消动态合成标记。
• Particle Time(粒子时间） -单独的粒子系统更新的性能消耗往往很大。您可以从游戏分析器中找出粒子系统并让美工对此最优化。或者，您可能需要改变游戏逻辑来减少它们的产生，比如如果一次攻击杀死10个敌人，您只需要在一帧内死亡的前2个敌人上做死亡粒子。 Update Bounds time 表明粒子系统需要固定的边界，而动态光照环境更新时间表明它可能正在做不必要的光照更新。这是和内容及游戏非常有关的。看一下 ParticleTickStats 获得更多细节。另外，太多的粒子可能会显示为渲染线程的 Particle update time ，而这可以通过LOD(层次细节度)或剔除来削减可见粒子的数量。
• Death and explosions（死亡和爆炸） - 死亡和爆炸的缓慢是由于不同的原因造成，一般是需要做组件更新，粒子生成和一些逻辑或AI更新。您可能需要把一些元素延迟到下一帧，或如果很多东西一起死亡则您需要把它们一起移除。
• Component Update time（组件更新时间） - 特定组件更新时间可能很长，比如骨骼网格。您需要看一下这种类型的组件，也许能把他们移到更为简单的组件类型（比如，100带顶点动画的静态网格比100 骨骼网格消耗的资源更少）
• Interp actor update time（Interp actor更新时间） -Interp actor更新起来可能在动态光照环境时间和运动时间上非常消耗资源。一个共同的修复方式是让关卡设计师在非游戏对象上标记"不要侵占" ，因为那会使停止慢速碰撞检测。
• Transparency Drawing（绘画的透明度） - 透明的物体经常在渲染线程中变得很慢，尤其是粒子。让美工确认没有叠加很多透明对象，并用LOD大量清除透明对象。
• Too Much Stuff（加入过多物体） -一般来说，美工和关卡设计喜欢在游戏里放很多东西。一般放置很多敌人（>10）或放置大量的网格物将使整体拖慢，并需要内容方面的最优化。