這裡暫且討論使用Mac對iOS裝置進行除錯的方法。至於Android平臺，會有細節但不是非常重要的不同。

為什麼需要聯機Profile？

大部分情況，直接在工作機（PC、Mac）用Unity針對工程進行Profile就能查出效能的瓶頸。
但在不同的裝置會有不同的效能表現、甚至一些裝置由於硬體設計的原因，導致一些效能瓶頸只有在特定裝置上才會表現出來。
針對這些裝置相關的效能問題，需要進行聯機Profile。

Profile的手段概述

iOS裝置通過USB連線Mac後，對其進行Profile手段有三種：

• Unity進行Profile
  
• XCode進行Profile
  
• XCode在debug模式時的“GPU Report”
  

3種Profile手段的特點

上面的3種Profile有以下特點：

• Unity或者XCode的profile能準確地顯示各項功能/函式消耗。
  • 但這兩種方式本身會引起大量的profile overhead，會引起裝置上的“虛卡”，所以它倆的所描述的更多是功能/函式間的相對大小關係。
  • 建議優先使用Unity的Profile，因為它的顯示資訊比XCode的Profile更加實用。
• XCode的“GPU Report”開銷較小，資料能真實地反應裝置執行情況，所以能收集絕對的整體消耗大小。

3中Profile手段的具體步驟

Unity進行Profile準備步驟

1. 通過USB連線除錯裝置和Mac
2. 在Build Settings裡如下圖選擇“Development Build”和“Autoconnect Profiler”，然後點選“Build”或者“Build And Run”
   
3. 構建中途，Unity會呼叫XCode自動進行編譯、自動進行執行。
4. 裝置執行我們的app了之後，在Unity開啟Profiler面板，並且如下圖選擇“iOS profiler over USB”，也就開始進行profile了。
   
5. Unity進行Profile準備步驟結束。

XCode進行Profile

1. 通過USB連線除錯裝置和Mac。

2. 確保除錯裝置能夠進行除錯你的app

   關於Apple Developer和Provisioning Profiles

   • 一個apple developer有一個apple id
   • 這個apple id下有不同的證書（certificates）。證書證明了這個apple id有能力進行軟體的開發、分發。
   • 這個apple id下有不同的app，每個app對應一個app id（也稱bundle id）。表明這個apple id正在開發、分發哪些app。
   • 這個apple id下有不同的裝置，每個裝置對應一個裝置id。表明這個apple id關聯了哪些裝置。
   • 這個apple id下有不同的Provisioning Profiles。一個證書id、一個app id和一個裝置id列表，組成了一個Provisioning Profiles。意思是，“因為有了這個Provisioning Profiles，我可以用這些裝置來除錯這個app”。
     所以，要成功讓XCode連上你的裝置並除錯你的app，你必須擁有正確的Provisioning Profile。
     更多可以參考Apple Developer官網裡的“Member Center”。

3. 在Unity進行Build了之後

4. 在XCode開啟相應的工程，如下圖點選Product>Profile
   
5. XCode編譯完了之後，會開啟“Instruments”正式開始Profile除錯
   • 可以通過“Instruments”裡面的“Library“來選擇不同維度的Profile，比如“Activity Monitor”可以監控裝置的各個程序情況、“Core Animation”可以監控幀數、“OpenGL ES Analyzer”可以監控圖形API層面的排程情況。
6. XCode進行Profile準備步驟結束。

XCode進行“GPU Report”

大體的準備規則和上面的“XCode進行Profile”差不多，主要差別在後面幾步：

1. Unity輸出XCode工程後，在XCode開啟相應的工程，直接點選“播放鍵”三角形；
2. 當裝置自動執行app後，點選下圖左部的按鈕
   
3. XCode進行“GPU Report”準備步驟結束。

Profile的方法論

如何找到效能瓶頸

專案乃至人生，都是一個選擇、試錯、總結，再選擇、再試錯、再總結的迴圈過程。這個過程並非白費，而是提高自己的經驗和能力，減少之後選擇錯誤的機率。

通過Profile找出效能瓶頸的通用步驟如下：

1. 通過功能Profile統計列表，找出佔用CPU時間/GPU時間最多的“瓶頸功能”。注意一幀所消耗的時間=Max(CPU時間, GPU時間），而並非它們的和；
2. 如果這個“瓶頸功能”是指令碼函式等具體的、熟悉的功能，則已經確切找到效能瓶頸，步驟結束。
3. 如果這個“瓶頸功能”是不具體的（比如“引擎渲染透明物體”、“引擎渲染cull預處理”就是不具體的），則繼續執行以下“廣度遍歷嘗試”步驟:
4. 對遊戲以不同維度進行拆分，以達到不同功能維度之間可以不相干地切換“ON/OFF”狀態。注意，選擇哪一種維度進行拆分是關鍵的；
5. 進行多次嘗試，每次嘗試只有一個維度在“ON”狀態、其他維度在“OFF”狀態；
6. 統計眾多嘗試中，最影響效能的維度A；
7. 將維度A進行子劃分，重複第4步，直到找到確切性能瓶頸。
8. 如果維度A優化掉後效果依然不達標，則重複到第1步。

找到效能瓶頸後該怎麼處理

處理方法可以有以下方法：

• 無損處理：進行優化，讓效能瓶頸優化成在任何情況下都不出現。比如演算法優化、記憶體訪問優化等。
• 有損處理：可能受限於執行環境，無損處理不可能完成，這需要有損地進行處理，讓效能瓶頸在特定情況下才不出現。比如Camera距離LOD、裝置功能LOD等。

具體Profile案例（Killer Project）

2014-08-10

問題

策劃要求敵人批量刷出至少15個，但在iPhone4上，15個敵人已經很卡。

目標

出現瓶頸的裝置：iPhone4。目標幀率30fps，所以目標幀時間為33.33ms。考慮到iPhone4是低端機型，允許偶爾降到20fps，所以允許幀時間偶爾達到50ms。

Profile步驟

使用Unity進行聯機Profile，發現渲染透明物體是效能瓶頸。

嘗試過把場景裡的透明物體都去掉，效果不明顯

所以依次進行了以下“ON/OFF”的嘗試。除了尋找真正瓶頸透明渲染之外，中間還輸出了其他的結論點

結論，敵人腳下的Blob shadow projector陰影是真正的透明渲染瓶頸所在，可以採取裝置LOD，在iPhone4上直接去除掉這個功能。
可以發現儘管去掉陰影后，效率還是無法達標，所以需要再重新進行一次profile。