資源管理

Q1：Unity5.4.1中，我將需要的Shader打到一個AssetBundle包中（包含一個關聯了所有Shader的Shader Variants），分別用Shader.WarmupAllShaders和ShaderVariantCollection.WarmUp兩種方式進行預加載，后者耗時更少。
這里用了Standard Shader做的測試，可以看到真機上兩種方式耗時差距是非常大的。 請問，確實是ShaderVariantCollection的效率更高，還是我測試方法有問題？

測試代碼：

Shader的AB包里的內容:

根據官方的文檔的描述，確實是ShaderVariantCollection的效率更高，詳見：
https://docs.unity3d.com/Manual/OptimizingShaderLoadTime.html
因為在ShaderVariantCollection中，是可以給每個Shader添加指定的Keyword的，ShaderVariantCollection.WarmUp的調用只會對ShaderVariantCollection中指定的Keyword進行Warmup操作；而Shader.WarmupAllShaders則是對所有的Keyword全部進行Warmup操作（其中大多數很可能都不會用到）。
因此在Shader.WarmupAllShaders的文檔中也提到，建議使用ShaderVariantCollection.Warmup來進行細粒度的Warmup操作，避免大量多余的Keyword被Warmup，造成嚴重的卡頓，大家可以參考下文：
https://docs.unity3d.com/ScriptReference/Shader.WarmupAllShaders.html

此問答來自于UWA 問答社區：https://answer.uwa4d.com/question/58fabe919db5d16c66166132
如您對該問題仍有疑問，可以轉至社區進行進一步交流。

---

資源管理

Q2：我們在做MMO國戰類游戲，因此想咨詢下資源標準。我們同屏會有70~80個玩家，這種情況下主角一般控制在多少面，多少根骨骼呢？一個Boss有80多根骨骼會有問題嗎？

這個需要看研發團隊希望在什么樣的機型上運行。假設是低端機器類似紅米Note2，那么建議玩家都控制在30根骨骼，1500面以下。如果只有一個怪物80根骨骼，問題并不大，但還需要考慮場景中其他物體的使用量。

建議研發團隊看一下這篇文章，這是我們半年前統計的關于MMO游戲的性能數據，相信能對MMO游戲的開發團隊具有借鑒意義：《MMO移動游戲性能分析報告：渲染、UI、邏輯代碼和內存需重點關注》

此問答來自于UWA 問答社區：
https://answer.uwa4d.com/question/58f614999db5d16c66166121
如您對該問題仍有疑問，可以轉至社區進行進一步交流。

---

資源管理

Q3：我們想請教一個Unity的普適性的資源管理問題。舉個例子，我們現在的一個特效Prefab包含的貼圖打成AssetBundle時沒有單獨拆分出來，就會存在一個問題，這個特效AssetBundle會存在重復加載的問題進而導致重復的特效貼圖在內存中。（針對“重復加載”說明下：我們首先通過AssetBundle出來一個Object，這個Object會緩存一段時間，在這段緩存時間過后這個Object會被Destroy掉，而需要釋放的特效是通過Instantiate這個Object出來的。當這個Object過了緩存時間被destroy掉后，下次需要釋放相同的特效還是通過load同樣的AssetBundle進行再實例化出來，這樣內存中存在兩份貼圖了。）

Unity中是沒有這種API來提供的，一般是團隊中自行做一些資源的引用計數來進行管理。頻繁調用UnloadUnusedAssets是不可取的（該函數的主要作用是查找并卸載不再使用的資源。游戲場景越復雜、資源越多，該函數的開銷越大，一般在300~2000 ms范圍內），但可以調用UnloadAsset來釋放資源。

---

內存管理

Q4：我們游戲現在測試出來的GC是否合理？這個分配數值可以接受嗎？是否存在泄露？如果存在泄露，有沒有具體到每個函數的分配詳情？

研發團隊可以在測試報告中查看 Mono堆內存分析報告，這里有我們對于Mono堆內存的詳細分析，包括 堆內存具體分配 和 堆內存泄露分析 兩大功能，如下圖所示。


就研發團隊目前的數據報告來看，其堆內存分配其實是很小的，之所以有目前的堆內存調用，推測是手動調用GC的頻率較高所致，研發團隊可以就此再進行進一步的檢測。

原文出處：侑虎科技
本文作者：admin
轉載請與作者聯系，同時請務必標明文章原始出處和原文鏈接及本聲明。