接着昨天渲染模块的讲解，今天为大家梳理下物理模块。一般来说，该模块的开销都是比较小的，但秉着“勿以恶小而为之，勿以善小而不为”的原则，我们将结合UWA的性能报告，再给大家强调下必须注意的几个优化点。

当然，纸上得来终觉浅，绝知此事要躬行，www.uwa4d.com等你来体验。

---

抛砖引例

打开物理模块的界面，我们可以看到更详细的性能数据，下图所示的是某卡牌回合制手游在红米2上的性能表现：

我们可以看到报告中的四个考核值为：“CPU均值”、“Contacts数量峰值”、“静态碰撞体峰值” 和 “动态碰撞体峰值”。需要说明的是动态碰撞体是指带有RigidBody的Collider，而静态碰撞体指不带有RigidBody的Collider。

“CPU均值” 目前主要是Physics.Simulate每帧的平均CPU耗时，一般我们建议在3ms以下。但同时我们也需要关注测试的主体范围（5%~95%）内的数值，通过UWA报告右上角的“分析 & 建议”即可查看，该游戏的主体范围值集中在0.1~3.5ms之间，相对偏高了。

另外，我们可以在报告中看到物理函数Physics.Simulate的趋势图，即Unity引擎中物理引擎的主要性能体现（Unity 5.x版本中多了个Processing，其实就是把Simulate拆开了）。对于Unity引擎而言，其4.x版本所使用的物理引擎为Nvidia PhysX 2.8，5.x版本所使用的物理引擎为Nvidia PhysX 3.3。

---

引起 Physics.Simulate 开销较大的几个因素

1.Rigidibody
该组件可使得游戏对象在物理系统的控制下运动。对于移动设备而言，建议Rigidibody数量控制在50以下。同时需要注意的是，大家常常会用Rigidbody组件配合CapsuleCollider，通过RigidBody.velocity来移动。这些会造成物理计算，特别是网格有很多Mesh Colider的时候，物理计算相当高。因此，我们建议尽量用Transform.Position代替物理计算。如果大家的地形是凹凸不平又要有重力的表示，也可以用Navmesh去做，它所引起的工作量在于烘焙Navmesh，并且尽可能地贴合地表 ，但是可以完全不用物理计算。

2.Contacts & Colider
Contacts数量为碰撞对（Contact Pair）数量。任意两个发生碰撞的碰撞体都会产生一个“碰撞对”。一般来说，Contacts数量越大，则表明碰撞物体的数量越多，即物理系统的CPU开销越大。那么碰撞体数量控制在多少以下比较合适呢？ 一般来说，碰撞体数量（静态碰撞体和动态碰撞体两者）均控制在100以下，当然越低越好。

---

几个注意点

1. 如果你是用NGUI制作UI，则在NGUI界面打开后，往往会有Physics一下涨高的情况。这是因为NGUI为了实现点击事件的检测，在每个UI上都设有BoxCollider，所以当UI Widgets摆在同一深度并存在相互叠加的情况时，会造成较多不必要的Contacts。但实际上UI根本不需要任何物理计算，所以大家需要看看能否把UI层之间的碰撞检测关掉。那是否有方法确定这些开销是NGUI造成的呢？推荐的做法是：通过报表，看到趋势图中的较高值后去找它对应的场景图，如果发现对应的场景都是UI，就可以判断Physics的碰撞矩阵中UI和UI之间是相互碰撞的。

2. OntriggerXXX（如OntriggerEnter）。这种情况一般是在脚本中触发了其他的逻辑调用，例如在主角被碰撞从而受到伤害时，创建一个伤害数字的UI，这些均有些实例化的逻辑计算，当然这些也会算到Physics开销中。所以如果你报告中的物理模块的数据都是正常的，但是物理开销依然很大，则需要大家再着重检测这个部分逻辑代码了。

今天的分享就到这里，明天我们继续讲解UWA测评报告中的动画模块，感谢各位开发者的关注。