技術分享連載（十三）資源管理性能優化資源管理性能優化性能優化

Q1: 請問粒子特效的Shader是否不能使用依賴打包？ 我們對Shader的模型和特效使用了依賴打包，運作的時候發現模型顯示是正常的，但是粒子特效使用的Shader就不能正常運作，特效顯示不正常。而在編輯器中，我們看到Material中的Shader是存在的。這時候如果重新手動給這個Material指定同樣的Shader，這個粒子特效就能正常顯示，請問這是什麼原因引起的？

部分 Shader 在打包到 Android 版本的 Assetbundle 之後，會因為平台不相容而無法正确顯示，這是因為打包後的 Shader 代碼隻保留了目标平台的預編譯代碼，不一定能夠在 Editor 下運作，是以這是正常現象。 但這并不會影響依賴打包，因為在真機上并不會出現類似的問題。

Q2：如圖，我們在UI打開或者移動到某處的時候經常會觀測到CPU上的沖激，經過進一步觀察發現是因為Instantiate産生了大量的GC。想請問下Instantiate是否應該産生GC呢？我們能否通過資源制作上的調整來避免這樣的GC呢？如下圖，因為一次性産生若幹MB的GC在直覺感受上還是很可觀的。

準确的說這些 GC Alloc 并不是由Instantiate 直接引起的，而是因為被執行個體化出來的元件會進行 OnEnable 操作，而在 OnEnable 操作中産生了 GC，比如以上圖中的函數為例： 上圖中的 Text.OnEnable 是在執行個體化一個 UI 界面時，UI 中的文本（即 Text 元件）進行了 OnEnable 操作，其中主要是初始化文本網格的資訊（每個文字所在的網格頂點，UV，頂點色等等屬性），而這些資訊都是儲存在數組中（即堆記憶體中），是以文本越多，堆記憶體開銷越大。但這是不可避免的，隻能盡量減少出現次數。 是以，我們不建議通過 Instantiate/Destroy 來處理切換頻繁的 UI 界面，而是通過 SetActive(true/false)，甚至是直接移動 UI 的方式，以避免反複地造成堆記憶體開銷。

Q3: iOS平台需要對圖集做RGB和Alpha通道的分離嗎？我發現在同樣大小的圖檔（正方形），RGB Compressed PVRTC 4bits和RGBA Compressed PVRTC 4bits兩種格式，占用記憶體是一樣的，如果把一張圖檔分成兩張，那麼在iOS平台是不是占用記憶體多一倍？有透明通道的，對于它的圖集怎麼處理會更好一點？

通常iOS下是不需要做通道分離的，因為 iOS 通用的 PVRTC 格式支援 Alpha 通道。但目前也有團隊回報，在 iOS 上進行通道分離有助于減少失真，可以在一定程度上提高視覺效果，是以也可以嘗試做一個對比。

如果發現占用記憶體是一樣的，那麼原始圖檔是RGB的。如果iOS上做通道分離，記憶體确實會增加一倍。UI的紋理在iOS下可以直接選擇預設的 Compress，在打Atlas時會自動處理成 PVRTC，開發團隊可以從Sprite packer視窗來看Atlas的壓縮格式做個确認。

Q4: 關于場景中玩家和NPC名字的DrawCall的問題。我們項目中是使用TextMesh挂到場景機關上，但是這樣每個名字就占了一個DrawCall，請問有沒有好的辦法優化呢？

遊戲中的HUD的做法一般有兩種，一種是如上的做法，另一種則是通過NGUI/UGUI來制作HUD。第二種的實作方法大緻如下： （1）計算螢幕中角色在螢幕中的位置； （2）根據螢幕中的位置來計算各自HUD的位置，并根據HUD的數量分别放置在一個或幾個Panel/Canvas下。 第二種方法的優勢是盡可能用少的Draw Call數來渲染角色的HUD。開發團隊可以就該方法來進行嘗試。

Q5: 我們能通過Batching來進行效能方面的優化嗎?透過粒子發射出來的半透明模型片是無法Saved by Batching ，如果粒子可以使用Dynamic Batching的話，想請教具體的使用規則與方法。

根據Unity 官方的資訊，目前粒子系統已經不再進行 Draw Call 的拼合，因為在新版本5.3 中已認證多線程進行更新，暫時無法支援拼合，但性能已經得到提升。

原文出處：侑虎科技

轉載請與作者聯系，同時請務必标明文章原始出處和原文連結及本聲明。