壹、遇到麻煩時要調用“垃圾回收器”（Garbage Collector，無用單元收集程序，以下簡稱GC）
由於具有C/C++遊戲編程背景，我們並不習慣無用單元收集程序的特定行為。確保自動清理妳不用的內存，這種做法在剛開始時很好，但很快妳就公發現自己的分析器經常顯示CPU負荷過大，原因是垃圾回收器正在收集垃圾內存。這對移動設備來說尤其是個大問題。要跟進內存分配，並盡量避免它們成為優先數，以下是我們應該采取的主要操作：
移除代碼中的任何字符串連接，因為這會給GC留下大量垃圾。
2.用簡單的“for”循環代替“foreach”循環。由於某些原因，每個“foreach”循環的每次叠代會生成24字節的垃圾內存。壹個簡單的循環叠代10次就可以留下240字節的垃圾內存。
3.更改我們檢查遊戲對象標簽的方法。用“if (gopareTag (“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.所有關卡內的粒子系統也可以使用同樣的禁用機制。