打開實體子產品的界面，我們可以看到更詳細的性能資料，下圖所示的是某卡牌回合制手遊在紅米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。
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上都設有Rigidbody，是以當UI Widgets擺在同一深度并存在互相疊加的情況時，會造成較多不必要的Contacts。但實際上UI根本不需要任何實體計算，是以大家需要看看能否把UI層之間的碰撞檢測關掉。那是否有方法确定這些開銷是NGUI造成的呢？推薦的做法是：通過報表，看到趨勢圖中的較高值後去找它對應的場景圖，如果發現對應的場景都是UI，就可以判斷Physics的碰撞矩陣中UI和UI之間是互相碰撞的。
2. OntriggerXXX（如OntriggerEnter）。這種情況一般是在腳本中觸發了其他的邏輯調用，例如在主角被碰撞進而受到傷害時，建立一個傷害數字的UI，這些均有些執行個體化的邏輯計算，當然這些也會算到Physics開銷中。是以如果你報告中的實體子產品的資料都是正常的，但是實體開銷依然很大，則需要大家再着重檢測這個部分邏輯代碼了。
原文出處：侑虎科技
本文作者：admin
轉載請與作者聯系，同時請務必标明文章原始出處和原文連結及本聲明。