總結使用Unity 3D優化遊戲運行性能的經驗

　　流暢的遊戲玩法來自流暢的幀率，而我們即將推出的動作平台遊戲《Shadow Blade》已經將在標準iPhone和iPad設備上實現每秒60幀視為一個重要目標。

　　以下是我們在緊湊的優化過程中提升遊戲運行性能，並實現目標幀率時需要考慮的事項。

　　當基本遊戲功能到位時，就要確保遊戲運行表現能夠達標。我們衡量遊戲運行表現的一個基本工具是Unity內置分析器以及Xcode分析工具。使用Unity分析器來分析設備上的運行代碼真是一項寶貴的功能。

　　我們總結了這種為將目標設備的幀率控製在60fps而進行衡量、調整、再衡量過程的中相關經驗。

　　一、遇到麻煩時要調用“垃圾回收器”（Garbage Collector，無用單元收集程序，以下簡稱GC）

　　由於具有C/C++遊戲編程背景，我們並不習慣無用單元收集程序的特定行為。確保自動清理你不用的內存，這種做法在剛開始時很好，但很快你就公發現自己的分析器經常顯示CPU負荷過大，原因是垃圾回收器正在收集垃圾內存。這對移動設備來說尤其是個大問題。要跟進內存分配，並盡量避免它們成為優先數，以下是我們應該采取的主要操作：

　　1.移除代碼中的任何字符串連接，因為這會給GC留下大量垃圾。

　　2.用簡單的“for”循環代替“foreach”循環。由於某些原因，每個“foreach”循環的每次迭代會生成24字節的垃圾內存。一個簡單的循環迭代10次就可以留下240字節的垃圾內存。

　　3.更改我們檢查遊戲對象標簽的方法。用“if (go.CompareTag (“Enemy”)”來代替“if (go.tag == “Enemy”)” 。在一個內部循環調用對象分配的標簽屬性以及拷貝額外內存，這是一個非常糟糕的做法。

　　4.對象庫很棒，我們為所有動態遊戲對象製作和使用庫，這樣在遊戲運行時間內不會動態分配任何東西，不需要的時候所有東西反向循環到庫中。

　　5.不使用LINQ命令，因為它們一般會分配中間緩器，而這很容易生成垃圾內存。

　　二、謹慎處理高級腳本和本地引擎C++代碼之間的通信開銷。

　　所有使用Unity3D編寫的遊戲玩法代碼都是腳本代碼，在我們的項目中是使用Mono執行時間處理的C#代碼。任何與引擎數據的通信需求都要有一個進入高級腳本語言的本地引擎代碼的調用。這當然會產生它自己的開銷，而盡量減少遊戲代碼中的這些調用則要排在第二位。

　　1.在這一情景中四處移動對象要求來自腳本代碼的調用進入引擎代碼，這樣我們就會在遊戲玩法代碼的一個幀中緩存某一對象的轉換需求，並一次僅向引擎發送一個請求，以便減少調用開銷。這種模式也適用於其他相似的地方，而不僅局限於移動和旋轉對象。

　　2.將引用本地緩存到元件中會減少每次在一個遊戲對象中使用 “GetComponent” 獲取一個元件引用的需求，這是調用本地引擎代碼的另一個例子。

　　三、物理效果

　　1.將物理模擬時間步設置到最小化狀態。在我們的項目中就不可以將讓它低於16毫秒。

　　2.減少角色控製器移動命令的調用。移動角色控製器會同步發生，每次調用都會耗損極大的性能。我們的做法是緩存每幀的移動請求，並且僅運用一次。

　　3.修改代碼以免依賴“ControllerColliderHit” 回調函數。這證明這些回調函數處理得並不十分迅速。

　　4.麵對性能更弱的設備，要用skinned mesh代替physics cloth。cloth參數在運行表現中發揮重要作用，如果你肯花些時間找到美學與運行表現之間的平衡點，就可以獲得理想的結果。

　　5.在物理模擬過程中不要使用ragdolls，隻有在必要時才讓它生效。

　　6.要謹慎評估觸發器的“onInside”回調函數，在我們的項目中，我們盡量在不依賴它們的情況下模擬邏輯。

　　7.使用層次而不是標簽。我們可以輕鬆為對象分配層次和標簽，並查詢特定對象，但是涉及碰撞邏輯時，層次至少在運行表現上會更有明顯優勢。更快的物理計算和更少的無用分配內存是使用層次的基本原因。

　　8.千萬不要使用Mesh對撞機。

　　9.最小化碰撞檢測請求（例如ray casts和sphere checks），盡量從每次檢查中獲得更多信息。

　　四、讓AI代碼更迅速

　　我們使用AI敵人來阻攔忍者英雄，並同其過招。以下是與AI性能問題有關的一些建議：

　　1.AI邏輯（例如能見度檢查等）會生成大量物理查詢。可以讓AI更新循環設置低於圖像更新循環，以減少CPU負荷。

　　五、最佳性能表現根本就不是來自代碼！

　　沒有發生什麼情況的時候，就說明性能良好。這是我們關閉一切不必要之物的基本原則。我們的項目是一個側邊橫向卷軸動作遊戲，所以如果不具有可視性時，就可以關閉許多動態關卡物體。

　　1.使用細節層次的定製關卡將遠處的敵人AI關閉。

　　2.移動平台和障礙，當它們遠去時其物理碰撞機也會關閉。

　　3.Unity內置的“動畫挑選”係統可以用來關閉未被渲染對象的動畫。

　　4.所有關卡內的粒子係統也可以使用同樣的禁用機製。

　　六、回調函數！那麼空白的回調函數呢？

　　要盡量減少Unity回調函數。即使敵人回調函數存在性能損失。沒有必要將空白的回調函數留在代碼庫中（有時候介於大量代碼重寫和重構之間）。

　　七、讓美術人員來救場

　　在程序員抓耳撓腮，絞盡腦汁去想該如何讓每秒運行更多幀時，美術人員總能神奇地派上大用場。

　　1.共享遊戲對象材料，令其在Unity中處於靜止狀態，可以讓它們綁定在一起，由此產生的簡化繪圖調用是呈現良好移動運行性能的重要元素。

　　2.紋理地圖集對UI元素來說尤其有用。

　　3.方形紋理以及兩者功率的合理壓縮是必不可少的步驟。

　　4.我們的美術人員移除了所有遠處背景的網格，並將其轉化為簡單的2D位麵。

　　5.光照圖非常有價值。

　　6.我們的美術人員在一些關口移除了額外頂點。

　　7.使用合理的紋理mip標準是一個好主意（遊戲邦注：要讓不同分辨率的設備呈現良好的幀率時尤其如此）。

　　8.結合網格是美術人員可以發揮作用的另一個操作。

　　9.我們的動畫師盡力讓不同角色共享動畫。

　　10.要找到美學/性能之間的平衡，就免不了許多粒子效果的迭代。減少發射器數量並盡量減少透明度需求也是一大挑戰。

　　八、要減少內存使用

　　使用大內存當然會對性能產生負麵影響，但在我們的項目中，我們的iPod由於超過內存上限而遭遇了多次崩潰事件。我們的遊戲中最耗內存的是紋理。

　　1.不同設備要使用不同的紋理大小，尤其是UI和大型背景中的紋理。《Shadow Blade》使用的是通用型模板，但如果在啟動時檢測到設備大小和分辨率，就會載入不同資產。

　　2.我們要確保未使用的資產不會載入內存。我們必須遲一點在項目中找到僅被一個預製件實例引用，並且從未完全載入內存中實例化的資產。

　　3.去除網格中的額外多邊形也能實現這一點。

　　4.我們應該重建一些資產的生周期管理。例如，調整主菜單資產的加載/卸載時間，或者關卡資產、遊戲音樂的有效期限。

　　5.每個關卡都要有根據其動態對象需求而量身定製的特定對象庫，並根據最小內存需求來優化。對象庫可以靈活一點，在開發過程中包含大量對象，但知道遊戲對象需求後就要具體一點。

　　6.保持聲音文件在內存的壓縮狀態也是必要之舉。

　　加強遊戲運行性能是一個漫長而具有挑戰性的過程，遊戲開發社區所分享的大量知識，以及Unity提供的出色分析工具為《Shadow Blade》實現目標運行性能提供了極大幫助。