技术分享连载（六十一）

资源管理

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
转载请与作者联系，同时请务必标明文章原始出处和原文链接及本声明。