記一次基於Unity的Profiler性能分析

A. WaitForTargetFPS: 
      Vsync(垂直同步)功能所，即顯示當前幀的CPU等待時間 
   B. Overhead： 
      Profiler整體時間-全部單項的記錄時間總和。用於記錄尚不明確的時間消耗，以幫助進一步完善Profiler的統計。 
        C. Physics.Simulate： 
      當前幀物理模擬的CPU佔用時間。 
   D. Camera.Render： 
      相機渲染準備工做的CPU佔用量 
   E. RenderTexture.SetActive： 
      設置RenderTexture操做. 
      底層實現：1.比對當前幀與前一幀的ColorSurface和DepthSurface. 
               2.若是這兩個Buffer一致則不生成新的RT，不然則生成新的RT，並設置與之相對應的Viewport和空間轉換矩陣. 
   F. Monobehaviour.OnMouse_ ： 
      用於檢測鼠標的輸入消息接收和反饋，主要包括：SendMouseEvents和DoSendMouseEvents。（只要Edtor開起來，這個就會存在） 
   G. HandleUtility.SetViewInfo： 
      僅用於Editor中，做用是將GUI和Editor中的顯示看起來與發佈版本的顯示一致。 
H. GUI.Repaint： 
      GUI的重繪(說明在有使用原生的OnGUI) 
   I. Event.Internal_MakeMasterEventCurrent： 
      負責GUI的消息傳送 
   J. Cleanup Unused Cached Data： 
      清空無用的緩存數據，主要包括RenderBuffer的垃圾回收和TextRendering的垃圾回收。 
         1.RenderTexture.GarbageCollectTemporary:存在於RenderBuffer的垃圾回收中，清除臨時的FreeTexture. 
         2.TextRendering.Cleanup:TextMesh的垃圾回收操做 
   K. Application.Integrate Assets in Background： 
      遍歷預加載的線程隊列並完成加載，同時，完成紋理的加載、Substance的Update等. 
   L. Application.LoadLevelAsync Integrate： 
      加載場景的CPU佔用，一般若是此項時間長的話70%的多是Texture過長致使. 
   M. UnloadScene： 
      卸載場景中的GameObjects、Component和GameManager，通常用在切換場景時. 
   N. CollectGameObjectObjects： 
      執行上面M項的同時，會將場景中的GameObject和Component彙集到一個Array中.而後執行下面的Destroy. 
   O. Destroy： 
      刪除GameObject和Component的CPU佔用. 
   P. AssetBundle.LoadAsync Integrate： 
      多線程加載AwakeQueue中的內容，即多線程執行資源的AwakeFromLoad函數. 
   Q. Loading.AwakeFromLoad： 
      在資源被加載後調用，對每種資源進行與其對應用處理. 
 

 

2. CPU Usage 
   A. Device.Present: 
      device.PresentFrame的耗時顯示，該選項出如今發佈版本中. 
   B. Graphics.PresentAndSync： 
      GPU上的顯示和垂直同步耗時.該選項出如今發佈版本中. 
   C. Mesh.DrawVBO： 
      GPU中關於Mesh的Vertex Buffer Object的渲染耗時. 
   D. Shader.Parse： 
      資源加入後引擎對Shader的解析過程. 
   E. Shader.CreateGPUProgram： 
      根據當前設備支持的圖形庫來創建GPU工程. 
3. Memory Profiler 
 
   A. Used Total: 
      當前幀的Unity內存、Mono內存、GfxDriver內存、Profiler內存的總和. 
   B. Reserved Total: 
      系統在當前幀的申請內存. 
   C. Total System Memory Usage: 
      當前幀的虛擬內存使用量.（一般是咱們當前使用內存的1.5~3倍) 
   D. GameObjects in Scene: 
      當前幀場景中的GameObject數量. 
   E. Total Objects in Scene: 
      當前幀場景中的Object數量(除GameObject外，還有Component等). 
   F. Total Object Count: 
      Object數據 + Asset數量. 
 
4. Detail Memory Profiler 
   A. Assets: 
      Texture2d:記錄當前幀內存中所使用的紋理資源狀況，包括各類GameObject的紋理、天空盒紋理以及場景中所用的Lightmap資源. 
   B. Scene Memory: 
      記錄當前場景中各個方面的內存佔用狀況，包括GameObject、所用資源、各類組件以及GameManager等（天般狀況經過AssetBundle加載的不會顯示在這裏). 
   A. Other: 
      ManagedHeap.UseSize:代碼在運行時形成的堆內存分配，表示上次GC到目前爲止所分配的堆內存量. 
      SerializedFile(3): 
      WebStream:這個是由WWW來進行加載的內存佔用. 
      System.ExecutableAndDlls:不一樣平臺和不一樣硬件獲得的值會不同。 
  
 
5. 優化重點 
   A. CPU-GC Allow: 
      關注原則：1.檢測任何一次性內存分配大於2KB的選項 2.檢測每幀都具備20B以上內存分配的選項. 
   B. Time ms: 
      記錄遊戲運行時每幀CPU佔用（特別注意佔用5ms以上的）. 
   C. Memory Profiler-Other: 
      1.ManagedHeap.UsedSize: 移動遊戲建議不要超過20MB. 
      2.SerializedFile: 經過異步加載(LoadFromCache、WWW等)的時候留下的序列化文件,可監視是否被卸載. 
      3.WebStream: 經過異步WWW下載的資源文件在內存中的解壓版本,比SerializedFile大幾倍或幾十倍,重點監視.**** 
   D. Memory Profiler-Assets: 
      1.Texture2D: 重點檢查是否有重複資源和超大Memory是否須要壓縮等. 
      2.AnimationClip: 重點檢查是否有重複資源. 
      3.Mesh： 重點檢查是否有重複資源. 
 

6. 項目中可能遇到的問題 
 
   A. Device.Present: 
      1.GPU的presentdevice確實很是耗時，通常出如今使用了很是複雜的shader. 
      2.GPU運行的很是快，而因爲Vsync的緣由，使得它須要等待較長的時間. 
      3.一樣是Vsync的緣由，但其餘線程很是耗時，因此致使該等待時間很長，好比：過量AssetBundle加載時容易出現該問題. 
      4.Shader.CreateGPUProgram:Shader在runtime階段（非預加載）會出現卡頓(華爲K3V2芯片). 
   B. StackTraceUtility.PostprocessStacktrace()和StackTraceUtility.ExtractStackTrace(): 
      1.通常是由Debug.Log或相似API形成. 
      2.遊戲發佈後需將Debug API進行屏蔽. 
 
   C. Overhead: 
      1.通常狀況爲Vsync所致. 
      2.一般出如今Android設備上. 
   D. GC.Collect: 
      緣由: 1.代碼分配內存過量(惡性的) 2.必定時間間隔由系統調用(良性的). 
      佔用時間：1.與現有Garbage size相關 2.與剩餘內存使用顆粒相關（好比場景物件過多，利用率低的狀況下，GC釋放後須要作內存重排) 
   E. GarbageCollectAssetsProfile: 
      1.引擎在執行UnloadUnusedAssets操做(該操做是比較耗時的,建議在切場景的時候進行). 
      2.儘量地避免使用Unity內建GUI，避免GUI.Repaint過渡GC Allow. 
      3.if(other.tag == GearParent.MogoPlayerTag)改成other.CompareTag(GearParent.MogoPlayerTag).由於other.tag爲產生180B的GC Allow. 
   F. 少用foreach，由於每次foreach爲產生一個enumerator(約16B的內存分配)，儘可能改成for. 
   G. Lambda表達式，使用不當會產生內存泄漏. 
   H. 儘可能少用LINQ： 
      1.部分功能沒法在某些平臺使用. 
      2.會分配大量GC Allow. 
   I. 控制StartCoroutine的次數： 
      1.開啓一個Coroutine(協程)，至少分配37B的內存. 
      2.Coroutine類的實例 -- 21B. 
      3.Enumerator -- 16B. 
   J. 使用StringBuilder替代字符串直接鏈接. 
   K. 緩存組件: 
      1.每次GetComponent均會分配必定的GC Allow. 
      2.每次Object.name都會分配39B的堆內存.