如何读懂UWA性能报告?—物理篇
- 作者:admin
- /
- 时间:2016年07月27日
- /
- 浏览:6922 次
- /
- 分类:厚积薄发
接着昨天渲染模块的讲解,今天为大家梳理下物理模块。一般来说,该模块的开销都是比较小的,但秉着“勿以恶小而为之,勿以善小而不为”的原则,我们将结合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测评报告中的动画模块,感谢各位开发者的关注。