當基本遊戲功能到位時，就要確保遊戲執行表現能夠達標。我們衡量遊戲執行表現的乙個基本工具是unity內建分析器以及xcode分析工具。使用unity分析器來分析裝置上的執行**真是一項寶貴的功能。我們總結了這種為將目標裝置的幀率控制在60fps而進行衡量、調整、再衡量過程的中相關經驗。
一、遇到麻煩時要呼叫「垃圾**器」（garbage collector，無用單元收集程式，以下簡稱gc）。由於具有c/c++遊戲程式設計背景，我們並不習慣無用單元收集程式的特定行為。確保自動清理你不用的記憶體，這種做法在剛開始時很好，但很快你就公發現自己的分析器經常顯示cpu負荷過大，原因是垃圾**器正在收集垃圾記憶體。這對移動裝置來說尤其是個大問題。要跟進記憶體分配，並盡量避免它們成為優先數，以下是我們應該採取的主要操作：
移除**中的任何字串連線，因為這會給gc留下大量垃圾。
用簡單的「for」迴圈代替「foreach」迴圈。由於某些原因，每個「foreach」迴圈的每次迭代會生成24位元組的垃圾記憶體。乙個簡單的迴圈迭代10次就可以留下240位元組的垃圾記憶體。
更改我們檢查遊戲物件標籤的方法。用「if (go.comparetag (「enemy」)」來代替「if (go.tag == 「enemy」)」 。在乙個內部迴圈呼叫物件分配的標籤屬性以及拷貝額外記憶體，這是乙個非常糟糕的做法。
物件庫很棒，我們為所有動態遊戲物件製作和使用庫，這樣在遊戲執行時間內不會動態分配任何東西，不需要的時候所有東西反向迴圈到庫中。
不使用linq命令，因為它們一般會分配中間緩器，而這很容易生成垃圾記憶體。
二、謹慎處理高階指令碼和本地引擎c++**之間的通訊開銷。所有使用unity3d編寫的遊戲玩法**都是指令碼**，在我們的專案中是使用mono執行時間處理的c#**。任何與引擎資料的通訊需求都要有乙個進入高階指令碼語言的本地引擎**的呼叫。這當然會產生它自己的開銷，而儘量減少遊戲**中的這些呼叫則要排在第二位。
在這一情景中四處移動物件要求來自指令碼**的呼叫進入引擎**，這樣我們就會在遊戲玩法**的乙個幀中快取某一物件的轉換需求，並一次僅向引擎傳送乙個請求，以便減少呼叫開銷。這種模式也適用於其他相似的地方，而不僅侷限於移動和旋轉物件。
將引用本地快取到元件中會減少每次在乙個遊戲物件中使用 「getcomponent」 獲取乙個元件引用的需求，這是呼叫本地引擎**的另乙個例子。
三、物理效果。
將物理模擬時間步設定到最小化狀態。在我們的專案中就不可以將讓它低於16毫秒。
減少角色控制器移動命令的呼叫。移動角色控制器會同步發生，每次呼叫都會耗損極大的效能。我們的做法是快取每幀的移動請求，並且僅運用一次。
修改**以免依賴「controllercolliderhit」 **函式。這證明這些**函式處理得並不十分迅速。
面對效能更弱的裝置，要用skinned mesh代替physics cloth.cloth引數在執行表現中發揮重要作用，如果你肯花些時間找到美學與執行表現之間的平衡點，就可以獲得理想的結果。
在物理模擬過程中不要使用ragdolls，只有在必要時才讓它生效。
要謹慎評估觸發器的「oninside」**函式，在我們的專案中，我們盡量在不依賴它們的情況下模擬邏輯。
使用層次而不是標籤。我們可以輕鬆為物件分配層次和標籤，並查詢特定物件，但是涉及碰撞邏輯時，層次至少在執行表現上會更有明顯優勢。更快的物理計算和更少的無用分配記憶體是使用層次的基本原因。
千萬不要使用mesh碰撞器。
最小化碰撞檢測請求（例如ray casts和sphere checks），盡量從每次檢查中獲得更多資訊。
四、讓ai**更迅速。我們使用ai敵人來阻攔忍者英雄，併同其過招。以下是與ai效能問題有關的一些建議：
ai邏輯（例如能見度檢查等）會生成大量物理查詢。可以讓ai更新迴圈設定低於影象更新迴圈，以減少cpu負荷。
五、最佳效能表現根本就不是來自**。沒有發生什麼情況的時候，就說明效能良好。這是我們關閉一切不必要之物的基本原則。我們的專案是乙個側邊橫向卷軸動作遊戲，所以如果不具有可視性時，就可以關閉許多動態關卡物體。
使用細節層次的定製關卡將遠處的敵人ai關閉。
移動平台和障礙，當它們遠去時其物理碰撞機也會關閉。
unity內建的「動畫挑選」系統可以用來關閉未被渲染物件的動畫。
所有關卡內的粒子系統也可以使用同樣的禁用機制。
六、**函式！那麼空白的**函式呢？要儘量減少unity**函式。即使敵人**函式存在效能損失。沒有必要將空白的**函式留在**庫中（有時候介於大量**重寫和重構之間）。
七、讓美術人員來救場。在程式設計師抓耳撓腮，絞盡腦汁去想該如何讓每秒執行更多幀時，美術人員總能神奇地派上大用場。
共享遊戲物件材質，令其在unity中處於靜態，可以讓它們繫結在一起，由此產生的簡化繪圖呼叫是呈現良好移動執行效能的重要元素。
紋理地圖集對ui元素來說尤其有用。
方形紋理以及兩者功率的合理壓縮是必不可少的步驟。
我們的美術人員移除了所有遠處背景的網格，並將其轉化為簡單的2d位面。
光照圖非常有價值。
我們的美術人員在一些關口移除了額外頂點。
使用合理的紋理mip標準是乙個好主意（遊戲邦注：要讓不同解析度的裝置呈現良好的幀率時尤其如此）。
合併網格是美術人員可以發揮作用的另乙個操作。
我們的動畫師盡力讓不同角色共享動畫。
要找到美學/效能之間的平衡，就免不了許多粒子效果的迭代。減少發射器數量並儘量減少透明度需求也是一大挑戰。
八、要減少記憶體使用。使用大記憶體當然會對效能產生負面影響，但在我們的專案中，我們的ipod由於超過記憶體上限而遭遇了多次崩潰事件。我們的遊戲中最耗記憶體的是紋理。
不同裝置要使用不同的紋理大小，尤其是ui和大型背景中的紋理。《shadow blade》使用的是通用型模板，但如果在啟動時檢測到裝置大小和解析度，就會載入不同資產。
我們要確保未使用的資產不會載入記憶體。我們必須遲一點在專案中找到僅被乙個預製件例項引用，並且從未完全載入記憶體中例項化的資產。
去除網格中的額外多邊形也能實現這一點。
我們應該重建一些資產的生週期管理。例如，調整主選單資產的載入/解除安裝時間，或者關卡資產、遊戲**的有效期限。
每個關卡都要有根據其動態物件需求而量身定製的特定物件庫，並根據最小記憶體需求來優化。物件庫可以靈活一點，在開發過程中包含大量物件，但知道遊戲物件需求後就要具體一點。
保持聲音檔案在記憶體的壓縮狀態也是必要之舉。
Flex遊戲程式設計效能優化
1.首先，元件的座標必須是整數 x 整數 y 整數 2.對於按鈕元件啟用cache as bitmap，會生成四個位圖 對不需要使用disable屬性的按鈕，盡量使用 button，因為4.避免for var i int 0 i arr.length i 的寫法，先用var i int arr.le...
遊戲效能優化（基礎）
資源在遊戲中會大量頻繁地使用，而在記憶體中是按照2的冪次方來載入的，例如一張大小是2020畫素的，在程式執行中是按照3232來處理的，而且從磁碟上載入每一張都屬於io操作，非常耗費cpu時間，尤其是在android的低端裝置上。所以通過打包工具 例如texturepacker 把多張小合併到一張大圖...
總結使用Unity 3D優化遊戲執行效能的經驗
流暢的遊戲玩法來自流暢的幀率，而我們即將推出的動作平台遊戲 shadow blade 已經將在標準iphone和ipad裝置上實現每秒60幀視為乙個重要目標。以下是我們在緊湊的優化過程中提公升遊戲執行效能，並實現目標幀率時需要考慮的事項。當基本遊戲功能到位時，就要確保遊戲執行表現能夠達標。我們衡量遊...