【厚积薄发】对象销毁了，为什么材质还留在内存里

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

UWA社区主页：community.uwa4d.com

UWA QQ群：793972859

本期目录：

• Material Instance为什么持续增长

• 动态生成Mesh后，为什么Mono内存变高了

本次推送的实战案例来自于使用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，它们为什么还被脚本长期持有。

无论是社区里开发者们的互助讨论，还是AI基于知识沉淀的快速反馈，核心都是为了让每一个技术难题都有解、每一次踩坑都有回响。希望这些从真实开发场景中提炼的经验，能直接帮你解决当下的技术卡点，也让你在遇到同类问题时，能更高效地找到破局方向。

封面图来源于网络

今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。

UWA官网：www.uwa4d.com

UWA社区：community.uwa4d.com

UWA学堂：edu.uwa4d.com

点击下方名片关注我们，将我设为星标，及时接收小编每日推送哦，性能优化不迷路～

近期精彩回顾