Q&A——资源管理（九）

资源管理

Q1：我在UGUI里更改了Image的Color属性，那么Canvas是否会重建？我只想借用它的Color做Animation里的变化量。

如果修改的是Image组件上的Color属性，其原理是修改顶点色，因此是会引起网格的Rebuild的（即Canvas.BuildBatch操作，同时也会有Canvas.SendWillRenderCanvases的开销）。而通过修改顶点色来实现UI元素变色的好处在于，修改顶点色可以保证其材质不变，因此不会产生额外的Draw Call。

---

资源管理

Q2：AssetBundle中资源同名但实际不同，请问会在UWA的资源检测报告中被认为是冗余的吗？

项目中的同名资源在UWA的资源检测报告中是不会被认为冗余的。在资源检测过程中，我们并不是通过资源的名称来判定其是否冗余。如果资源本身是不同的，即使名称相同，UWA报告也不会判定是冗余。

资源管理

Q3：移动游戏场景中，相同的怪物会动态合并吗？如下设置可行吗？

默认情况下，带蒙皮的Mesh是不支持动态合批的。如果场景中相同材质的蒙皮网格数量很多，可以考虑通过插件MeshBaker来进行合并，具体方法大家可以参考好插件让你事半功倍！

---

资源管理

Q4：EventSystem.Update()占用过高怎么优化？

EventSystem.Update 的开销分为两个部分：

1. 来自被触发的响应事件，这部分的开销实际上并不属于事件系统本身，比如：某次点击触发了一个开销很高的逻辑函数，尤其是涉及到资源的加载和实例化。对于这类开销，我们建议通过Profiler.Begin/EndSample或者UWA提供的UWA API，对这些逻辑函数进行进一步的分析。

2. 事件检测的开销，在默认情况下所有的UI元素都是事件检测的目标，因此当界面上UI元素数量很多，且长时间接触屏幕时，会有较高的持续开销。对于这类开销，我们建议通过以下几种方式来优化：
   a) 合理划分子Canvas，只有需要检测事件的界面才需要挂上GraphicRaycaster组件。
   b) 在Unity5.2之后的版本中，尽可能将不需要参与事件检测的UI元素的 Raycast Target 属性的勾选去掉。而对于Unity 4.x的版本，则可以尝试对UI部分的源码来进行修改以达到类似的效果。

资源管理

Q5：打包AssetBundle的时候，我发现切换场景时，即使打同一个场景的AssetBundle，它们的Hash值都是不一样的，可能是什么原因造成的呢？

在不同的场景下打包同一个资源或场景时，如果出现AssetBundle的差异，目前很可能是Shader Stripping造成的，其原理可见文档：https://docs.unity3d.com/Manual/class-GraphicsSettings.html

简单来说就是根据当前场景对Shader进行简化，因此如果打包时包含的场景的Lightmap或Fog设置不同，打出来的AssetBundle包也有可能是不同的。可以尝试通过把Graphics Settings中的Shader Stripping设置进行修改来避免这个问题。

---

资源管理

Q6：当UI关闭后，Texture图片却还留在内存，是下次垃圾回收或者Resources.UnloadUnusedAssets调用的时候就会清除吗？如果想立即清除，该如何操作？

垃圾回收并不会卸载内存中的资源，而Resources.UnloadUnusedAssets是可以的，但前提是纹理资源已经不再被其他Object引用。如果要立即清除，可以尝试直接调用Resources.UnloadAsset来进行卸载。

---

资源管理

Q7：我们的游戏中，不透明渲染在总体渲染里占比较高，主要的开销在于 MeshSkinning.Render 部分，这部分的Draw Call过高，共有65个， 请问该如何优化呢？

默认情况下Skinned Mesh是无法合并Draw Call的，从而导致Draw Call过高的问题。 我们建议尝试通过 SkinnedMeshRenderer的BakeMesh接口，将蒙皮动画转为网格序列帧，同时确保顶点属性的数目符合动态拼合的条件，从而降低这部分的Draw Call。另外，这种做法也可以降低MeshSkinning.Update以及Animator.Update的CPU耗时，只是网格序列帧会占用较大的内存，研发团队可以尝试做一个评估。

资源管理

Q8:预设中的变量，拖拽到Inspector面板和Transform.find这两种方法对加载影响是一样的吗？

对加载性能有微小的不同。Transform.Find 是可以灵活控制调用时机的，可以真正要用的时候再进行Transform.Find，这样GameObject被实例化时效率会更高一些 。但如果拖上去，GameObject被实例化时，该变量就需要进行序列化。因此，加载和实例化时两者的性能会存在一些微小的变化。

资源管理

Q9：我有一个关于AssetBundle资源加密问题。CreateFromMemory这里不推荐大规模使用，那是不是我们要放弃对一部分资源的加密？还是说有其它的解决办法？

由于CreateFromMemory的加载速度相较其他的接口而言，耗时明显增大，因此我们确实不建议大规模使用。就目前而言，除了使用CreateFromMemory，并没有其他高效直接的方法进行资源加密，因此，确实需要放弃对一部分资源的加密。同时，目前存在一些工具可以从更底层的方式来获取和导出渲染相关的资源，如纹理、网格等，因此，对于这部分的资源加密并没有十分的必要性。

---

资源管理

Q10：我想确认一下Shader的依赖打包问题。如果采用了依赖打包，A、B、C依赖了D，当我更新了D包时，A、B、C是否都要重新打包？反过来呢？

在使用Unity 4.x的接口时开启DeterministicAssetBundle，或者使用Unity 5.x新接口（默认强制开启DeterministicAssetBundle）时，当更新了D包，都是不需要重新打包A、B和C的。
反之，如果更新了（比如B包），那么在Unity 4.x 下依然是需要重新打D包的，而Unity 5.x新接口则会检测到D包未更新，而自动跳过其打包过程。