资源管理

Q1：我在UWA上进行了性能检测，在资源内存这里看到详情如下。请问这个数量峰值大于1是不是就是有问题的？但一个Material是很可能被实例化多份的。实例化后对象释放掉，然后清理掉原始的Material，按道理就不算冗余吧？毕竟大部分都是材质在操作，对贴图资源应该没有影响。而且，如果确实有那么多角色同屏怎么办呢？

是的，如果数量峰值>1，则说明存在资源冗余的风险。如果是Material实例化，那么后者是有个（instance）后缀的，比较好识别。如果是new Material(Shader)出来的，那么是没有instance后缀的。但无论是哪种方式，如果数量峰值较大，都应引起大家注意。一般都是可以通过其他方法来尽可能避免冗余的。

如果变化不是随机的，且Material参数变化情况比较少，那么可以根据参数的变化情况只做几种Material，然后通过脚本动态赋值。如果是随机或者动画，那就没什么办法了，要么改需求，要么就接受这么多。

资源管理

Q2: 对NGUI字体错乱有什么好的解决方案吗？

有这么几种可能：

1. 一次展开文字太多了。这种情况在部分高通机型和Unity早期版本上都经常出现，现在也偶尔有，究其原理是FontTexture的扩容操作做得不够快或者收到了硬件驱动的限制。

   一般来说有两种方法可以解决：（1）减少面板中的字体内容；（2）一开始就用超大量的字体去扩容，将动态字体的FontTexture扩大到足够大；

2. 文字渲染与开发团队编写的多线程渲染发生了冲突。这种情况也常有发生，特别是通过GL.IssuePluginEvent方式来开启多线程渲染的项目，就会容易出现问题。

就我们的优化经验来看，第一种情况发生的可能性比较大。

性能优化

Q3：这个批渲染是什么？好像开销很高 。

从图中看出，这是场景中不透明物体的渲染开销。建议研发团队对当时场景中的不透明物体（地形、建筑等）进行进一步检测，主要查看其三角面片数是否过高、Shader是否过于复杂等。

资源管理

Q4：我们测试发现，当Animator Controller挂载的动作比较多时，即使切换成另外一个动作很少的Animator Controller，任务的动作信息还是不会释放。我们将英雄打成一个AssetBundle，然后又把定制的Runtime Animator Controller加载替换进去，英雄自带的Runtime Animator Controller是挂了所有动作的。我们试了替换Runtime Animator Controller之后，把先前的Runtime Animator Controller Destroy掉，貌似内存也没释放。

销毁Animator Controller并不会释放其内所引用的AnimationClip资源的，所以内存没有明显下降是正常的。建议按照以下方式做个试验：

1. 销毁Animator Controller 后，通过Unity Profiler立刻真机Take Sample，查看Animation Clip的Ref count是否为0；
2. 如果不是，则需要进一步查看这些资源的索引出处；如果为0，则可以通过UnloadUnusedAssets或UnloadAsset来将其从内存中去除。

资源管理

Q5：请问这个GameObject.Active的开销怎么这么高？Activate会产生堆内存分配吗？

这个是PC上的鼠标交互事件造成的，是UI界面的Active操作，所以触发了各种相关的OnEnable调用，研发团队可以在Profiler中进行进一步定位，查看根源。

一般来说，GameObject的Activate操作本身是不会产生堆内存分配，但它引发的各种底层类的OnEnable会产生堆内存的分配。