此文章為網上轉載收集而成，非原創文章，請尊重別人的勞動成果，讓分享成為一種美德，歡迎轉載。另外，文章在表述和代碼方面如有不妥之處，歡迎批評指正。同時大家有更好的優化方案，或者自己獨立見解的優化想法，也請發相關郵件於我，我將持續更新這篇文章，努力將「淺談」轉變為「深入」！觀前提示：本文篇幅較長，請耐心觀看或收藏
本文連結https://blog.csdn.net/qq_23420435/article/details/110109812
當前版本：V0.0.0
更新時間：2020-11-25
更新內容：首次整合更新
更新管理：小小Unity收集整合
18328685848@163.com
----轉載收集整合 小小Unity章節四《Unity3D性能優化——初識Unity-Statistics》
https://blog.csdn.net/wdmzjzlym/article/details/51335915
----萌萌的一天當運行一個U3D場景後，可以在界面右上方看到一個叫做"Status"的按鈕，點開它就會出現一個重疊界面顯示出實時統計數據，比如下圖這種樣子：
如果你是一名U3D開發新手，或者對此功能非常不熟悉，那麼你可能會在遊戲優化過程中遇到很多麻煩。接下來的篇幅著重講講該窗口的作用和必要的相關名詞解釋。
Statistics窗口，全稱叫做 Rendering Statistics Window，即渲染統計窗口（或渲染數據統計窗口）,窗口中羅列出關於聲音、圖像、網絡狀況等多種統計信息
FPS(Time per frame andFPS):frames per seconds表示引擎處理和渲染一個
遊戲幀所花費的時間,該數字主要受到場景中渲染物體數量和 GPU性能的影
響，
FPS數值越高，遊戲場景的動畫顯示會更加平滑和流暢。一般來說，超過
30FPS的畫面人眼不會感覺到卡，由於視覺殘留的特性，光在視網膜上停
止中用後人眼還會保持1/24秒左右的時間，因此遊戲畫面每秒幀數至少要
保證在30以上。另外，Unity中的FPS數值僅包括此遊戲Scene裡更新和渲
染的幀，編輯器中繪製的Scene和其它監視窗口的進程不包括在內。
CPU:獲取到當前佔用CPU進行計算的時間絕對值，或時間點，如果Unity
主進程處於掛斷或休眠狀態時，CPU time將會保持不變。
Render thread:GPU渲染線程處理圖像所花費的時間，具體數值由GPU性
能來決定，
Batches:即Batched Draw Calls,是Unity內置的Draw Call Batching技術。
首先解釋下什麼叫做「Draw call」，CPU每次通知GPU發出一個glDrawElements（OpenGl中的圖元渲染函數)或DrawIndexedPrimitive（DirectX中的頂點繪製方法）的過程稱為一次Draw call,一般來說，引擎每對一個物體進行一次DrawCall，就會產生一個Batch,這個Batch裡包含著該物體所有的網格和頂點數據，當渲染另一個相同的物體時，引擎會直接調用Batch裡的信息，將相關頂點數據直接送到GPU,從而讓渲染過程更加高效，即Batching技術是將所有材質相近的物體進行合併渲染。
對於含有多個不同Shader和Material的物體，渲染的過程比較耗時，因為會產生多個Batches。每次對物體的材質或者貼圖進行修改，都會影響Batches裡數據集的構成。因此，如果場景中有大量材質不同的物體，會很明顯的影響到GPU的渲染效率。這裡說幾點關於Batches優化相關的方案。
雖然Unity引擎自帶Draw Call Batching技術，我們也可以通過手動的方式合併材質接近的物體；
儘量不要修改Batches裡物體的Scale，因為這樣會生成新的Batch。
為了提升GPU的渲染效率，應當儘可能的在一個物體上使用較少的材質，減少Batches過多的開銷；
對於場景中不會運動的物體，考慮設置Static屬性,Static聲明的物體會自動進行內部批處理優化。
關於Tris和Verts,突然想到一些問題，這裡需要多嘴說幾句：
Camera的渲染性能受到Draw calls的影響。之前說過，對一個物體進行渲染，會生成相應的Draw call，處理一個Draw Call的時間是由它上邊的Tris和Verts數目決定。儘可能的合併物體，會很大程度的提高性能。舉個很簡單例子，比如場景一種有1000個不同的物體，每個物體都有10個Tris；場景二中有10個不同的物體，每個物體有1000個Tris。在渲染處理中，場景一中會產生1000個Draw Calls，它的渲染時間明顯比場景二慢。
Unity stats 視圖中的 Tris 和 Verts 並不僅僅是視錐中的梯形內的 Tris 和 Verts，而是Camera中 field of view所有取值下的tris和verts，換句話說，哪怕你在當前game視圖中看不到這個 cube，如果當你把 field of view調大到 179 過程中都看不到這個cube，stats面板才不會統計，GPU才不會渲染，否則都會渲染，而且unity不會把模型拆分，這個模型哪怕只有1個頂點需要渲染，unity也會把整個模型都渲出來。（參考自Mess的《Unity Camera組件部分參數詳解》）
之前有童鞋問過我，新建一個空的場景，裡邊沒有添加任何物體，為什麼Status面板上顯示有1.7k Tris以及5.0kVerts。這是因為空的場景自帶默認的天空盒。點擊Windows---Lighting打開Lighting下的Scene面板，把Skybox裡的材質設為空，比如像我下圖這樣：**
可以看到，場景中的Tris數量變為2，Verts數量變為了4，這是由於攝像機存在的關係，刪掉它，你就會發現Tris 和 Verts 都變為0了。
Screen:獲得當前Game屏幕的解析度大小，後邊的2.1MB表示總的內存使用數值。
SetPass calls：又碰到一個神奇的詞「SetPass calls」。如果你是一個Unity的
老用戶，你可能會注意到原來的Stats面板的第一項是「Draw calls」，然而到
了Unity5.X版本，Stats上沒有了「Draw calls」，卻多出來一項」SetPass calls「,
那麼這個玩意到底是做什麼的？？？(你猜.... )← ←！
感覺又要說一大堆東西了之前有講到Batches,比如說場景中有100個gameobject,它們擁有完全一樣的Material,那麼這100個物體很可能會被Unity裡的Batching機制結合成一個Batch。所以用「Batches」來描述Unity的渲染性能是不太合適的，它只能反映出場景中需要批處理物體的數量。那麼可否用「Draw calls」來描述呢？答案同樣是不適合。每一個「Draw calls」是CPU發送個GPU的一個渲染請求，請求中包括渲染對象所有的頂點參數、三角面、索引值、圖元個數等，這個請求並不會佔用過多的消耗，真正消耗渲染資源的是在GPU得到請求指令後，把指令發送給對應物體的Shader,讓Shader讀取指令並通知相應的渲染通道（Pass）進行渲染操作。