總结使用UnityD优化游戏运行性能的经验.docVIP

流畅的游戏玩法来自流畅的帧率，而我们即将推出的动作平台游戏《Shadow Blade》已经将在标准iPhone和iPad设备上实现每秒60帧视为一个重要目标。 以下是我们在紧凑的优化过程中提升游戏运行性能，并实现目标帧率时需要考虑的事项。--当基本游戏功能到位时，就要确保游戏运行表现能够达标。我们衡量游戏运行表现的一个基本工具是Unity内置分析器以及Xcode分析工具。使用Unity分析器来分析设备上的运行代码真是一项宝贵的功能。我们总结了这种为将目标设备的帧率控制在60fps而进行衡量、调整、再衡量过程的中相关经 一、遇到麻烦时要调用“垃圾回收器”（Garbage Collector，无用单元收集程序，以下简称GC） 由于具有C/C++游戏编程背景，我们并不习惯无用单元收集程序的特定行为。确保自动清理你不用的内存，这种做法在刚开始时很好，但很快你就公发现自己的分析器经常显示CPU负荷过大，原因是垃圾回收器正在收集垃圾内存。这对移动设备来说尤其是个大问题。要跟进内存分配，并尽量避免它们成为优先数，以下是我们应该采取的主要操作： 1.移除代码中的任何字符串连接，因为这会给GC留下大量垃圾。 2.用简单的“for”循环代替“foreach”循环。由于某些原因，每个“foreach”循环的每次迭代会生成24字节的垃圾内存。一个简单的循环迭代10次就可以留下240字节的垃圾内存。 3.更改我们检查游戏对象标签的方法。用“if (go.CompareTag (“Enemy”)”来代替“if (go.tag == “Enemy”)” 。在一个内部循环调用对象分配的标签属性以及拷贝额外内存，这是一个非常糟糕的做法。 4.对象库很棒，我们为所有动态游戏对象制作和使用库，这样在游戏运行时间内不会动态分配任何东西，不需要的时候所有东西反向循环到库中。 5.不使用LINQ命令，因为它们一般会分配中间缓器，而这很容易生成垃圾内存。 二、谨慎处理高级脚本和本地引擎C++代码之间的通信开销。 所有使用Unity3D编写的游戏玩法代码都是脚本代码，在我们的项目中是使用Mono执行时间处理的C#代码。任何与引擎数据的通信需求都要有一个进入高级脚本语言的本地引擎代码的调用。这当然会产生它自己的开销，而尽量减少游戏代码中的这些调用则要排在第二位。 1.在这一情景中四处移动对象要求来自脚本代码的调用进入引擎代码，这样我们就会在游戏玩法代码的一个帧中缓存某一对象的转换需求，并一次仅向引擎发送一个请求，以便减少调用开销。这种模式也适用于其他相似的地方，而不仅局限于移动和旋转对象。 2.将引用本地缓存到元件中会减少每次在一个游戏对象中使用 “GetComponent” 获取一个元件引用的需求，这是调用本地引擎代码的另一个例子。 三、物理效果 1.将物理模拟时间步设置到最小化状态。在我们的项目中就不可以将让它低于16毫秒。 2.减少角色控制器移动命令的调用。移动角色控制器会同步发生，每次调用都会耗损极大的性能。我们的做法是缓存每帧的 3.修改代码以免依赖“ControllerColliderHit” 回调函数。这证明这些回调函数处理得并不十分迅速。 4.面对性能更弱的设备，要用skinned mesh代替physics cloth。cloth参数在运行表现中发挥重要作用，如果你肯花些时间找到美学与运行表现之间的平衡点，就可以获得理想的结果。 5.在物理模拟过程中不要使用ragdolls，只有在必要时才让它生效。 6.要谨慎评估触发器的“onInside”回调函数，在我们的项目中，我们尽量在不依赖它们的情况下模拟逻辑。 7.使用层次而不是标签。我们可以轻松为对象分配层次和标签，并查询特定对象，但是涉及碰撞逻辑时，层次至少在运行表现上会更有明显优势。更快的物理计算和更少的无用分配内存是使用层次的基本原因。 8.千万不要使用Mesh对撞机。 9.最小化碰撞检测请求（例如ray casts和sphere checks），尽量从每次检查中获得更多信息。 四、让AI代码更迅速 我们使用AI敌人来阻拦忍者英雄，并同其过招。以下是与AI性能问题有关的一些建议： 1.AI逻辑（例如能见度检查等）会生成大量物理查询。可以让AI更新循环设置低于图像更新循环，以减少CPU负荷。 五、最佳性能表现根本就不是来自代码！ 没有发生什么情况的时候，就说明性能良好。这是我们关闭一切不必要之物的基本原则。我们的项目是一个侧边横向卷轴动作游戏，所以如果不具有可视性时，就可以关闭许多动态关卡物体。 1.使用细节层次的定制关卡将远处的敌人AI关闭。 2.移动平台和障碍，当它们远去时其物理碰撞机也会关闭