我们曾在四年前对于Unity的主流模块的性能优化知识点逐一做过讲解，俗称“小白版”。随着这几年引擎本身、硬件设备、制作标准等等的升级，UWA也不断更新优化规则和方法并持续输出给广大开发者。作为"升级版"的性能优化手册，【Unity性能优化系列】将力图以浅显易懂的表达，让更多开发者可以受用。本期我们来继续分享物理模块相关的知识点。
在Unity自带的物理引擎中，物理模块的耗时主要来自FixedUpdate.PhysicsFixedUpdate和逻辑代码中的射线检测、碰撞检测等。FixedUpdate.PhysicsFixedUpdate函数的耗时构成主要有两部分：一个是Physics.Processing，一个是Physics.Simulate。一般来说，我们要关注这两个函数的堆栈，通过堆栈函数的调用次数、耗时占比来进一步定位原因。常见的影响性能的因素和优化对策有这些：
一、项目是否确实需要物理模块
首先，我们需了解Unity上Auto Simulation选项的开关机制。在Unity 2017.4以前无该选项，引擎会根据项目是否存在物理内容自动开启或关闭；在Unity 2017.4及以后该选项开放，默认为开启状态。
很多项目往往没有关注到物理模块开关与否，造成不必要的性能浪费。建议研发团队根据项目情况考虑是否开启物理模块，亦可考虑通过其它方案替代物理模块作用，以节省物理部分的耗时。
二、控制物理调用次数
在UWA的真人真机测评报告的物理模块中，我们可以看到物理更新次数的统计。
物理调用次数需着重关注以下两个参数：
1）Fixed Timestep
其决定了FixedUpdate的更新间隔，该值越大，每帧物理更新调用次数越少。但物理更新频率过低可能会造成部分机制异常，建议团队在可接受范围内尽量调高Fixed Timestep数值。
2）Maximum Allowed Timestep
这里我们需要先知道物理系统本身的特性，即当游戏上一帧卡顿时，Unity会在当前帧非常靠前的阶段连续调用N次FixedUpdate.PhysicsFixedUpdate，Maximum Allowed Timestep的意义就在于限制物理更新的次数。
Maximum Allowed TimeStep决定了单帧物理最大调用次数，该值越小，单帧物理最大调用次数越少。在Fixed Timestep为20ms的前提下，将Maximum Allowed Timestep从333ms下调为100ms，那么无论卡顿情况如何，该帧最多只会调用5次，而不是最多17次。
另外建议大家先优化其他模块，这样可以减少下一帧的物理更新次数。
三、Contact数量是否合理
Contact数量异常通常有以下两种情况：
1）Contact数量过多
需考虑是否存在不必要的物理碰撞检测，例如盾牌与地面的碰撞。
2）Contact数量为0且存在物理耗时
Contact数量为0代表项目中没有碰撞或者Trigger，在不使用布料模拟等其他物理特性的情况下，可以考虑将物理模块关闭，即关闭AutoSimulation。
四、减少Raycast使用
Raycast，也就是我们常说的射线检测，其耗时与射线数量成正比。要控制Raycast的耗时，最简单的办法就是控制射线数量。
但部分项目确实需要较多的Raycast，例如弹幕游戏中Raycast数量往往较多，这种情况下可以通过Job System下的RaycastCommand将Raycast的耗时从主线程转移到子线程上，进而减少其耗时。
五、Auto Sync Transforms
勾选Auto Sync Transforms后，发生Physics Query时，Unity会将Rigidbody/Collider的Tranform变化同步到物理引擎，如Position，Scale等。另外勾选AutoSimulation时，Unity会在每次物理更新的时候自动同步一次Rigidbody和Collider，所以当关闭AutoSimulation后，如果项目中使用了射线检测或者NGUI，通常需要Auto Sync Transforms进行勾选，否则会发生射线检测结果不准确或者UI事件不响应的情况。
同步操作在一般情况下的性能开销很低，通常只在超大场景，且有大量物体均加载到场景中，才会出现较高的耗时问题。
六、逻辑代码相关
这里的逻辑代码指的是MonoBehavior脚本中的void FixedUpdate函数，在Profiler中通常会显示为xxx.FixedUpdate，此函数的调用次数会受到物理更新次数的影响。
比如场景中有10个挂载了Monster.cs的小怪，且该脚本在void FixedUpdate中写了逻辑代码。那么在当前帧物理更新次数为3时，在Profiler中会看到这一帧的Monoster.FixedUpdate调用了10*3=30次。
通常我们建议尽量将代码写入到Update函数中，这样可以减少对应逻辑的执行次数，从而减少逻辑代码的耗时。
以上就是在优化物理模块性能时需要关注的一些问题和对应的方法，如何操作还需要大家结合项目实际情况。当然我们UWA已经开发的GOT Online和本地资源检测都已经提供了很丰富的检测功能，希望能成为大家优化物理模块的神助攻。