对象销毁了，为什么材质还留在内存里

作者：admin
/
时间：3小时前
/
浏览：21 次
/
分类：厚积薄发

1）Material Instance为什么持续增长
2）动态生成Mesh后，为什么Mono内存变高了

这是第489篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

UWA社区主页：community.uwa4d.com
UWA QQ群：793972859

本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。

实战案例

Q：项目运行一段时间后，Material Instance数量持续增长，从开始的100多个增加到2000多个，这是什么原因？应该如何排查？

A：这种情况可以先排查运行过程中是否不断实例化了新的Material。报告中可以看到，某类技能材质（Instance）从最开始的100多个逐渐增加到2000多个，而且持续出现新的实例。这类现象通常需要结合技能、角色、特效对象的生命周期一起看，确认运行过程中是否不断产生新的Material Instance。

Unity中访问Renderer.material时，如果当前Renderer使用的是共享材质，Unity会为它实例化一份独立的Material。这里不只是调用SetColor、SetFloat等修改操作需要注意，仅仅访问Renderer.material本身，就可能触发实例化。如果只是读取或继续使用共享材质，可以检查是否应该使用Renderer.sharedMaterial。

真正容易被忽略的是材质和GameObject的生命周期并不是完全绑定的。通过Renderer.material等方式在运行时实例化出来的Material，不会因为对应GameObject被Destroy就自动完成资源释放，需要对这类动态材质单独管理。

比如技能释放时创建了临时特效对象，同时实例化了一份材质。技能结束后GameObject已经销毁，但这份Material没有被显式销毁，下一次释放技能又生成新的实例，长期运行后就可能看到Material Instance数量从几百一路涨到几千。未被使用的材质也可能在Resources.UnloadUnusedAssets()等资源清理过程中被回收，但不应该把它当成高频动态材质的主要生命周期管理方式。

排查时可以从持续增长的材质名称入手，再对应技能释放、角色生成、特效播放等操作做复现。如果每执行一次操作，某类Material Instance数量都会增加，而对应对象销毁后实例仍然保留，就需要继续检查这条材质创建和销毁链路。

优化时可以重点关注两个方向：

减少不必要的Material Instance创建。
检查是否存在只为了读取材质却访问Renderer.material的情况；如果只是修改颜色、Vector等每个Renderer不同的属性，也可以评估MaterialPropertyBlock是否适用，减少独立Material实例。需要切换Shader或Shader Keyword时，则不能简单用MPB替代。

显式管理动态材质生命周期。
如果确实需要实例化Material，需要保留对应引用，并在对象生命周期结束时显式Destroy。对于高频创建的技能、角色和特效，也可以进一步检查是否能够复用材质，而不是不断创建新的实例。

实战案例

Q：项目地图区域原本直接使用MeshRenderer，但动态加载、卸载时会有卡顿，后来改为在脚本中保存顶点等数据，运行时再动态生成Mesh。UWA GOT Online报告显示Mono内存占用较高，如何判断是否和这部分数据有关？

A：可以先通过Memory Profiler确认Mono堆中的主要占用。如果其中存在大量顶点、矩阵等Mesh相关数据，再结合引用关系查看这些数据是否由地图区域相关脚本对象持有，就能进一步判断Mono占用是否和这套动态Mesh实现有关。

这里需要关注的并不是“动态生成Mesh”本身，而是为了生成Mesh，脚本侧长期保存了多少网格数据。例如C#侧保存了大量Vector3[]、索引数组或矩阵数据，这些内容会占用Managed Heap，也就是这里看到的Mono内存。随后再把这些顶点、索引数据提交给Mesh，Mesh自身还需要在Native侧维护对应的网格数据。

因此，如果Mesh已经生成，而C#侧的原始顶点、索引等数据仍然长期保留，就可能出现同一批网格信息同时占用Managed和Native两侧内存的情况。这里不能简单理解为固定的“双倍内存”，但确实需要同时关注两边的数据占用，而不能只看Mono。

排查时可以重点看：

确认Mono中的Mesh相关数据占了多少。
查看顶点数组、索引、矩阵等数据的数量和实际占用，再通过引用关系确认它们是否由地图区域相关脚本长期持有。

检查Mesh生成后，托管侧数据是否仍然需要保留。
如果网格生成完成后不再需要频繁修改，原始Vector3[]、List等数据就要确认是否还有长期保存的必要。如果没有其他引用，可以解除引用，让GC后续回收，而不是一直和Mesh同时保留。

检查是否存在多份数据。
如果原始地图区域数据、转换后的顶点数据、运行时Mesh和其他缓存同时存在，同一份区域信息就可能以不同形式占用多份内存。

此外还要关注动态Mesh生成过程中的临时分配。如果频繁创建新的Vector3[]、List等托管对象，会持续产生GC Alloc，Managed Heap扩容后也不一定会马上回落，因此会出现Mono内存长期维持在较高水位的情况。

Mono堆规模变大、需要管理的托管对象增多后，GC扫描和标记的成本也可能随之增加，因此这部分问题不仅体现在内存占用上，也可能进一步带来GC耗时。

如果项目使用的Unity版本和现有架构允许，还可以继续评估NativeArray、Mesh.SetVertices(NativeArray)，以及MeshDataArray、Mesh.ApplyAndDisposeWritableMeshData等方式，减少动态网格构建过程中对Managed Heap的依赖。不过这属于进一步的实现优化，排查时仍然应该先确认：现在到底是哪一批数据占用了Mono，它们为什么还被脚本长期持有。