【轉】 各種 基於Unity3d 引擎的Android遊戲最佳化 （drawcall）

標籤：android   style   http   color   os   使用   io   ar   for   

 

1. 更新不透明貼圖的壓縮格式為ETC 4bit，因為android市場的手機中的GPU有多種，每家的GPU支援不同的壓縮格式，但他們都相容ETC格式，
2. 對於透明貼圖，我們只能選擇RGBA 16bit 或者RGBA 32bit。
3. 減少FPS，在ProjectSetting-> Quality中的VSync Count 參數會影響你的FPS，EveryVBlank相當於FPS=60，EverySecondVBlank = 30；
這兩種情況都不符合遊戲的FPS的話，我們需要手動調整FPS，首先關閉垂直同步這個功能，然後在代碼的Awake方法裏手動設定FPS（Application.targetFrameRate = 45;）
   降低FPS的好處：
 1）省電，減少手機發熱的情況；
 2）能都穩定遊戲FPS，減少出現卡頓的情況。
4. 當我們設定了FPS後，再調整下Fixed timestep這個參數，這個參數在ProjectSetting->Time中，目的是減少物理計算的次數，來提高遊戲效能。

5. 盡量少使用Update LateUpdate FixedUpdate，這樣也可以提升效能和節省電量。多使用事件（不是SendMessage，使用自己寫的，或者C#中的事件委託）。

6. 待機時，調整遊戲的FPS為1，節省電量。

 

 

玩一款遊戲如 果經常遇到死機或者畫面不好，一般的使用者就不想在玩下去了，之所以會造成這種情況大體可以說是兩個原因導致的，第一就是自己的硬體設施，第二就是遊戲自己 本身的效能；第一個原因是可以使用者自己去選擇的，至於第二個原因只能通過開發人員來改變，那麼如何最佳化遊戲運行效能呢？下面簡單的為大家介紹幾個方面。
遇到麻煩時要調用“記憶體回收行程”（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命令，因為它們一般會分配中間緩器，而這很容易產生垃圾記憶體。
所有使用unity3d編寫的遊戲玩法代碼都是指令碼代碼，在我們的項目中是使用Mono執行時間處理的C#代碼。任何與引擎資料的通訊需求都要有一個進入進階指令碼語言的本地引擎代碼的調用。這當然會產生它自己的開銷，而盡量減少遊戲代碼中的這些調用則要排在第二位。
1.在這一情景中四處移動對象要求來自指令碼代碼的調用進入引擎代碼，這樣我們就會在遊戲玩法代碼的一個幀中緩衝某一對象的轉換需求，並一次僅向引擎發送一個請求，以便減少調用開銷。這種模式也適用於其他相似的地方，而不僅局限於移動和旋轉對象。
2.將引用本機快取到元件中會減少每次在一個遊戲對象中使用 “GetComponent” 擷取一個元件引用的需求，這是調用本地引擎代碼的另一個例子。

 

 

   只有擁有相同材質的物體才可以進行批處理。因此，如果你想要得到良好的批處理效果，你需要在程式中儘可能地複用材質和物體。   動態批處理動態批處理操作是自動完成的，並不需要你進行額外的操作。 提醒：1、       批處理動態物體需要在每個頂點上進行一定的開銷，所以動態批處理僅支援小於900頂點的網格物體。 2、     如果你的著色器使用頂點位置，法線和UV值三種屬性，那麼你只能批處理300頂點以下的物體；如果你的著色器需要使用頂點位置，法線，UV0，UV1和切向量，那你只            能批處理180頂點以下的物體。            請注意：屬性數量的限制可能會在將來進行改變。 4、      不要使用縮放尺度（scale）。分別擁有縮放尺度(1,1,1)和(2,2,2)的兩個物體將不會進行批處理。 5、      統一縮放尺度的物體不會與非統一縮放尺度的物體進行批處理。          使用縮放尺度(1,1,1)和 (1,2,1)的兩個物體將不會進行批處理，但是使用縮放尺度(1,2,1)和(1,3,1)的兩個物體將可以進行批處理。 6、      使用不同材質的執行個體化物體（instance）將會導致批處理失敗。 7、      擁有lightmap的物體含有額外（隱藏）的材質屬性，比如：lightmap的位移和縮放係數等。所以，擁有lightmap的物體將不會進行批處理（除非他們指向lightmap的同一           部分）。 8、     多通道的shader會妨礙批處理操作。比如，幾乎unity中所有的著色器在前向渲染中都支援多個光源，並為它們有效地開闢多個通道。 9、      預設體的執行個體會自動地使用相同的網格模型和材質。 靜態批處理  
  靜態批處理目前只支援Unity iOS Advanced。

【轉】 各種 基於Unity3d 引擎的Android遊戲最佳化 （drawcall）