U3D 最佳化技術

一、Batching技術： 在擁有網格並攜帶一種不同的材質時候才會形成一個獨立的drawcall, 在通知GPU和切換材質shader紋理時候也是比較耗時的（特別是第一次CPU->GPU傳遞紋理資料）。 Batching 的主要目標是 合并物體的材質，只要他們使用相同的材質（紋理和shader），GPU就可以按完全相同的方式進行處理（批處理合并drawcall）。Batching處理技術的演算法是： 檢查所有要繪製物體的材質，把材質相同的遊戲對象分成一組，這樣就可以在一個drawcall中處理多個物體。 Unity在情境中先對物體進行可視化裁剪，然後進行批處理，這樣可以使得渲染過程中幾何總量在批處理前後保持不變。使用幾何建模工具會妨礙引擎對其進行有效裁剪，從而導致unity內部需要更多的幾何面片。 靜態批處理只要對遊戲對象選擇static即可，需要額外的記憶體來消耗儲存合并後的幾何資料。使用遊戲對象建立了共用網格，那麼會消耗過多的記憶體，通過去掉static可以減少記憶體使用量。 動態遊戲對象擁有相同的材質Unity會自動進行批處理，不需要任何設定。但是動態批處理是有限和有條件的。擁有位置，法線和uv的網格物體只能處理總共300個頂點的物體合并批處理，超過不支援。使用不同材質的執行個體化遊戲對象不能進行批處理，擁有lightmap的遊戲對象不能批處理，多個pass的shader材質會妨礙批處理，接受陰影的物體不會進行批處理。
二、UnityProfile 分析器使用： 可以查看CPU, 記憶體，GPU, 渲染，物理及音頻佔用情況（可以在左上方添加，可以在對應的頁簽左邊點擊X去掉），找到遊戲的效能瓶頸。 1）window->Profile視窗 點擊Record記錄，點擊Play按鈕。 2）unity會記錄啟動並執行效能情況，點擊時間軸上任何地方會在視窗底部會顯示所選幀的詳細資料。 3）上部會顯示分析器控制項，點擊時間軸會暫停顯示幀詳細資料，Frame的上下是上一幀下一幀，current是當前最後一幀。點擊Deep Profile是深度分析會分析所有指令碼的函數調用容易卡死，Profile Editor是分析編輯器，Clear是清理。
每個視圖都要注意下，分析出來的每個欄位的含義，不懂就google下。 如： CPU分析中： Total是函數及其子函數所花費的時間，self是本函數消耗的時間。單擊層次項目項，右邊會顯示出詳細資料。GPU中也是一樣。可以根據這些資訊來最佳化遊戲對象設定，啟用的特性，最佳化指令碼。 Memory分析中：GfxDriver是顯卡驅動程式在紋理，渲染對象，著色器等渲染所需要的記憶體情況。 Detail模式下，Referenced from native code 對象是Unity自身代碼的引用。 Scene Object 對象來自情境遊戲對象。 Builtin Resources 對象來自於Unity內建資源。
分析器介面在代碼中使用： 針對unity deep profile分析的局限性，可以使用 Profiler.BeginSample(name:string); // name是採樣標籤 Profiler.EndSample(); 手動開啟和關閉功能，會對BeginSample和EndSample之間的程式碼片段進行分析。樣本： using UnityEngine; using System.Collections; /*samcen*/ public class ProfilerExample : MonoBehaviour {
private int sum = 0; void Start() { Profiler.BeginSample ("MyProfiler"); for (int i = 0; i < 10; i++) { sum += i; print (sum); } Profiler.EndSample (); } } 將該指令碼掛載到遊戲對象中，就可以在Profile 開始幀的詳細面板中看到分析結果(因為在Start中)。
不同裝置串連到分析器： IOS裝置串連到分析器： 選中Build setting->development build->auto connect profile，然後在Profile分析視圖中選擇Active profile中選擇裝置，就可以分析了。 確保ios裝置串連到了wifi, 確保mac 防火牆關閉了，或者保證54998~55511連接埠處於開啟狀態。 在unity中依次開啟file->build & run。 就可以在unity分析器中分析遊戲在ios中的運行情況了。
Android裝置串連到分析器： 和ios類似，就是多了確保android裝置關閉了行動數據，開啟wifi, 和ios一樣設定項目開啟了auto connect profile, 在unity開啟了profile視窗後，選擇active profile選項開啟分析器。 選擇unity file->build & run, 在android裝置上開啟應用程式。android裝置與主機計算機必須使用同一個子網。
三、Unity Frame debugger 通過幀分析，來分析每一幀的GPU, Draw call和渲染的紋理映像資訊，以及深度緩衝，模板緩衝，多目標FBO的資訊。 你也可以使用外部的工具調試渲染。打一個獨立播放包，用 Visual Studio圖形調試器 、 Intel GPA 、 RenderDoc 、 NVIDIA NSight 或 AMD GPU PerfStudio 運行，然後抓取渲染的一幀，並且逐步調試draw calls和其它渲染事件看看發生了什麼。
四、最佳化建議 1.通用的最佳化建議： 1).FixedUpdate是用在物理引擎中，以固定間隔執行的。Update是每幀調用，間隔是不固定的。 盡量不要在其中寫太多不需要重複調用的代碼。 存在空的FixedUpdate, Update也要移除，避免每幀的函數調用開銷。 2).Update, FixedUpdate中不要使用Find, FindObjectOfType, FindGameObjectsWithTag, GetCompoent<T>()等耗時的函數。 3).Update, FixedUpdate中不要申請字串，數組 等對堆記憶體資源的頻繁申請和釋放。 也不要在該熱點函數中使用太多臨時變數，如太多棧變數也是耗時的，特別注意堆變數。
4).上述1，2，3的操作可以放置到Awake, Start函數中。 代碼不需要每幀執行，則用Coroutines來解決，如： void Start() ｛ InvokeRepeating("DoSomeThing", 1.5f, 1.0f); ｝ 5).在遊戲切換關卡，或暫停時候，手動進行垃圾記憶體的回收。 Resource.UnloadUnuseAssets()； GC.Collect()；的調用。
2.在行動裝置中： 物理效能的最佳化： 1）對物理引擎的最佳化，在edit->project setting->time中，增加Fixed Timestep的數值，減少物理引擎幀計算間隔，降低CPU負荷。設定Maximum Allowed Timestep的數值為0.1,即每秒更新10次。 2）不使用網格碰撞體，wheel colliders車輪碰撞體，而是使用box,sphere形狀的碰撞體，減少計算開銷。 3）避免使用unity內建的Sphere等mesh組件，因為有太多的面片，需用從其它建模軟體中匯入3D模型替代。 4）需要控制情境中非休眠的剛體和碰撞體的數量，可以使用profile工具來確定活動的數量。 指令碼的最佳化： 1)在Update函數中，減少GetCompoent調用，減少字串，數組對堆記憶體資源的申請和釋放。 2）盡量減少GUILayout的使用，因為需要額外的記憶體開銷。通過將useGULayout為false, 用GUI手動布局可以替代掉。 3）不使用異常處理，如ios中，unity設定 project setting->player中異常選項中使用： Fast and exceptions unsupported（不使用異常）,而不是使用slow and safe（mono內部使用，支援異常）。 4）最佳化變數，盡量用Int而不是float； 盡量用簡單的運算式，例如位元運算；盡量不用複雜的數學函數。