1. 项目概述从一次线上卡顿事故说起那天下午项目组里负责战斗模块的老王突然在群里发了个截图游戏帧率从稳定的60帧骤降到个位数持续了将近5秒玩家反馈直接炸了。我们紧急回滚版本、排查日志最终定位到一个诡异的现象每当玩家通过传送点进入一个特定的“幽暗森林”子场景时主线程就会发生一次明显的卡顿而Profiler里显示大量的时间花在了“Loading.Preload”和“SerializedFile.Read”上。这不对劲这个子场景的AssetBundle明明不大美术资源也做了优化按说不该这么卡。更头疼的是随着玩家在线时间增长游戏的整体内存占用会缓慢而坚定地攀升直到触发OOM崩溃。直觉告诉我这不仅仅是“资源太大”那么简单背后一定藏着某种隐性的资源泄漏。我们项目正从传统的GameObject转向Unity DOTS 1.0架构大量逻辑用ECS和Jobs重写AssetBundle则用Addressables管理。问题就出在这个新旧架构的夹缝里——DOTS Entity引用的Prefab通过AssetBundle加载后其引用计数似乎没有在场景卸载时被正确清理。这不是一个简单的“忘记调用Release”的问题而是一条在DOTS 1.0到1.5版本中可能存在的、由引擎底层引用计数管理机制与上层AssetBundle生命周期错位导致的泄漏链。为了彻底揪出这条链并给团队提供一个可持续的排查手段我花了些时间研究并实现了一个基于Unity Editor的内存引用关系图谱自动化分析工具。今天我就把这个从问题定位、原理剖析到工具实战的完整过程分享出来希望能帮到同样在DOTS迁移深水区挣扎的兄弟们。2. 核心问题拆解为什么DOTSAssetBundle容易“漏”要理解这个泄漏链我们得先抛开DOTS那些复杂的ComponentSystem和Entity回到Unity资源管理的基石引用计数Reference Counting和AssetBundle的生命周期。2.1 传统模式与DOTS模式下的资源引用差异在传统的GameObject/Component模式下一个Prefab从AssetBundle中加载出来比如通过Addressables.LoadAssetAsyncGameObject实例化成场景中的GameObject。这个GameObject身上挂载的脚本、Renderer组件引用的Material和Texture都形成了清晰的引用链。当你销毁这个GameObject或卸载包含它的场景时只要你没有在其他地方持有这些资源的引用Unity的垃圾回收GC和AssetBundle的引用计数机制通常会协同工作最终在合适的时机比如调用Resources.UnloadUnusedAssets或Addressables的释放接口将资源内存释放并将AssetBundle的引用计数减到0从而允许其被卸载。然而在DOTS架构下情况变了。我们不再直接实例化GameObject的Prefab而是通过EntityManager.Instantiate来实例化一个Entity的Prefab通常是一个EntityPrefab。这个EntityPrefab本身也是一个可序列化的资产它可能通过IBufferElementData组件间接引用了一个复杂的Prefab结构这个结构里包含了需要从AssetBundle加载的Mesh、Material等子资产。关键在于DOTS的序列化与引用管理路径与传统AssetBundle的引用计数系统并不总是完全同步的。2.2 泄漏链的形成一个被忽视的“三角关系”泄漏往往发生在一个典型的“子场景动态加载”用例中。假设我们有一个主场景Main和一个子场景Forest打包成AssetBundlescene_forest.bundle。加载Loading玩家触发传送代码调用Addressables.LoadSceneAsync(“Forest”, LoadSceneMode.Additive)。Unity加载scene_forest.bundle并实例化其中的EntityPrefab比如一棵树TreeEntityPrefab。引用建立Reference CreationTreeEntityPrefab的某个IComponentData例如一个RenderMesh组件内部包含了对另一个AssetBundlematerials.bundle中某个材质球Mat_Tree的引用。此时Unity底层会为Mat_Tree增加引用计数。同时scene_forest.bundle本身也因为场景加载而被引用。卸载Unloading玩家离开森林代码调用Addressables.UnloadSceneAsync(sceneInstance)或直接卸载场景。理想情况下所有引用都应该被释放。泄漏发生Leak Occurrence问题在于DOTS Entity在销毁时其组件数据所持有的对非托管数据如BlobAsset或通过特定方式引用的托管对象的引用可能没有触发AssetBundle引用计数的递减操作。特别是当引用是通过序列化后的EntityPrefab间接持有时这个释放信号可能在场景卸载流程中被遗漏。于是Mat_Tree的引用计数仍然 0导致materials.bundle无法卸载。更糟糕的是scene_forest.bundle本身可能因为内部Entity结构的某种残留引用也无法完全卸载。链式反应Chain Reaction如果Mat_Tree又引用了textures.bundle中的一张贴图那么这张贴图也会被连带“锁住”。这就形成了一条从场景AssetBundle到材质AssetBundle再到贴图AssetBundle的泄漏链。每次加载/卸载子场景这些“僵尸”引用就累积一次内存占用稳步上涨而加载新场景时Unity可能需要重新加载那些本该在内存中、但引用计数紊乱的资源从而引发主线程的IO阻塞和反序列化卡顿。注意这种泄漏在Editor中可能不明显因为Editor有更宽松的内存管理和调试加载。一旦发布到真机尤其是内存受限的移动设备问题就会急剧放大表现为加载时间变长、内存增长、最终崩溃。3. 内存引用图谱自动化分析工具的设计与实现光知道原理不够我们需要一个“显微镜”来直观地看到到底是哪个Entity、哪个组件、通过什么路径持有了哪个AssetBundle里的哪个资源。手动在Profiler里翻看ManagedHeap和NativeHeap如同大海捞针。因此我决定打造一个Editor工具自动化分析当前内存中的对象引用关系并生成可视化的图谱。3.1 工具的核心目标与架构工具的目标很明确快照能力能在游戏运行时的任意时刻尤其是疑似泄漏发生后捕获当前内存中所有活跃的UnityEngine.Object及其引用关系。过滤与聚焦能快速过滤出与AssetBundle相关的对象并追踪其引用根路径。可视化输出生成一张清晰的图谱标明从“疑似泄漏的资产”回溯到“根源Entity或管理器”的完整引用链。自动化与集成最好能一键操作并集成到我们的CI流水线中在自动化测试后检查内存异常。工具的整体架构分为三层数据采集层利用Unity的Object.FindObjectsOfTypeObject(true)注意此API在运行时效率需谨慎我们仅在诊断时使用或更底层的UnityEditor.ObjectInfo接口需通过反射调用内部方法获取所有对象实例。同时通过AssetDatabase.GetAllAssetPaths和AssetDatabase.GetDependencies来建立资产路径与对象的关联。对于AssetBundle则通过AssetBundle.GetAllLoadedAssetBundles获取列表并查询每个bundle的引用计数通过AssetBundle.m_AssetBundle的私有字段反射获得。关系分析层这是最核心也最复杂的部分。我们需要分析对象间的引用关系。对于托管对象可以使用WeakReference和条件编译仅在UNITY_EDITOR下调用UnityEditor.EditorUtility.CollectDependencies来收集一个对象的直接依赖。但更有效的是针对Entity和ComponentData我们需要通过EntityManager遍历所有Entity检查其组件数据中是否包含对特定UnityEngine.Object的引用例如通过ComponentType和EntityManager.GetComponentData读取Entity的RenderMesh组件获取其中的material字段。可视化与输出层将分析结果以树状结构或图结构组织。我选择了输出为JSON格式然后使用一个简单的HTML页面配合vis.js库来渲染交互式网络图。同时在Unity Editor内也生成一个可折叠的树状UI方便快速浏览。3.2 关键代码实现如何捕获Entity对资产的引用下面这段代码展示了工具如何遍历所有Entity寻找对特定材质资产的引用。这是分析层的关键。using Unity.Entities; using Unity.Collections; using UnityEngine; public class MemoryReferenceAnalyzer { private World m_World; private DictionaryUnityEngine.Object, ListEntityReferencePath m_ReferenceMap; public void AnalyzeAssetReferences(UnityEngine.Object targetAsset) { m_ReferenceMap new DictionaryUnityEngine.Object, ListEntityReferencePath(); var allWorlds World.All; foreach (var world in allWorlds) { m_World world; var entityManager m_World.EntityManager; var query entityManager.CreateEntityQuery(ComponentType.ReadOnlyRenderMesh()); var entities query.ToEntityArray(Allocator.TempJob); try { foreach (var entity in entities) { var renderMesh entityManager.GetComponentDataRenderMesh(entity); // 检查material引用 if (renderMesh.material targetAsset) { RecordReference(entity, targetAsset, “RenderMesh.material”); } // 检查mesh引用如果也需要 // if (renderMesh.mesh targetAsset) ... } } finally { entities.Dispose(); query.Dispose(); } // 同样方式检查其他可能持有引用的ComponentData如PrefabReference组件等 AnalyzeCustomComponentReferences(entityManager, targetAsset); } GenerateReport(); } private void RecordReference(Entity entity, UnityEngine.Object asset, string referencePath) { if (!m_ReferenceMap.ContainsKey(asset)) { m_ReferenceMap[asset] new ListEntityReferencePath(); } m_ReferenceMap[asset].Add(new EntityReferencePath { WorldName m_World.Name, Entity entity, Path referencePath, // 可以进一步获取Entity的名称或索引 }); } private void AnalyzeCustomComponentReferences(EntityManager entityManager, UnityEngine.Object targetAsset) { // 这里需要根据项目实际使用的、可能持有资产引用的自定义IComponentData进行扩展。 // 例如一个“AssetReferenceData”组件里面存储了Addressables的Key或Instance ID。 // 可能需要用到反射或代码生成来通用化处理。 } private void GenerateReport() { // 将m_ReferenceMap序列化为JSON或直接在EditorWindow中绘制UI } } struct EntityReferencePath { public string WorldName; public Entity Entity; public string Path; }实操心得直接遍历所有Entity和组件对性能影响很大绝对不要在发布的游戏逻辑中调用。这个工具仅限在开发阶段、发现问题后在Editor中或通过Development Build连接Profiler时进行“诊断性”执行。可以考虑在工具中增加采样率控制如每N帧分析一次或仅分析特定World/Query的结果。3.3 工具的使用流程与图谱解读复现问题在编辑器中运行游戏执行一系列操作直到你认为内存泄漏可能已经发生例如反复加载/卸载某个子场景10次。触发分析在游戏运行时通过自定义的Editor窗口点击“捕获当前内存快照”按钮。等待分析工具会运行一段时间取决于场景复杂度期间游戏可能会卡顿这是正常的。查看结果AssetBundle列表工具会列出所有已加载的AssetBundle及其当前引用计数。重点关注引用计数异常高比如大于预期加载的场景或资源数量或卸载后计数不为0的Bundle。可疑资产追踪点击某个计数异常的Bundle工具会展开显示该Bundle中包含的所有资产如材质、贴图、网格。再点击某个具体资产如Mat_Tree右侧会显示“引用图谱”。解读图谱图谱通常是一个从右向左的箭头图。最右边是目标资产Mat_Tree箭头指向它的可能是一个具体的Entity显示为Entity: 1234 (World: ClientWorld)。一个EntityPrefab资产Assets/Prefabs/Tree.prefab。一个MonoBehaviour脚本实例。一个静态类或管理器的静态字段。 沿着箭头向左回溯你可能会发现这个Entity属于某个未销毁的System或者这个Prefab被缓存在某个全局的Dictionarystring, EntityPrefab里而忘记清理。典型泄漏图谱示例AssetBundle: “materials.bundle” (RefCount: 3) └── Asset: “Mat_Tree” (InstanceID: 1001) ├── Referenced By: Entity: 5678 (World: ClientWorld) via “RenderMesh.material” │ └── Belongs To: Scene “Forest (Additive)” (但该场景已调用Unload!) │ └── Root Cause: System “RenderMeshUpdateSystem” 的静态缓存列表未在场景卸载时清除对应Entity。 ├── Referenced By: Prefab “Assets/Prefabs/TreeEntity.prefab” (Loaded from “prefabs.bundle”) │ └── Referenced By: DynamicBufferPrefabReference in Entity: 9012 (World: ServerWorld) │ └── Root Cause: 服务器World的Entity跨网络同步后客户端的清理逻辑未同步处理此Buffer。通过这样的图谱我们就能精准定位到泄漏的根源代码位置。4. 针对DOTS 1.0~1.5的专项排查与修复策略有了分析工具我们就可以系统地排查和修复DOTS项目中的AssetBundle引用泄漏问题。以下是一些针对性的策略。4.1 系统System生命周期管理与静态数据清理很多泄漏源于System的设计。在DOTS中System是持续运行的如果它在OnCreate()或某个字段中缓存了对资产或Entity的引用并且在OnDestroy()中没有正确清理就会导致泄漏。错误示例public class TreeRenderSystem : SystemBase { private Dictionaryint, Material m_CachedMaterials new Dictionaryint, Material(); // 静态或实例字段缓存 protected override void OnCreate() { // 可能预加载一些材质 var mat Addressables.LoadAssetAsyncMaterial(“Mat_Tree”).WaitForCompletion(); m_CachedMaterials[0] mat; // 加载后存入缓存 } protected override void OnUpdate() { /* 使用缓存 */ } // 缺少 OnDestroy 来释放Addressables引用 }修复方案审查所有System检查每个System的字段特别是static字段或引用类型如Dictionary,List。确保在System被销毁OnDestroy或关联的World被销毁时清理这些引用。使用依赖注入与明确的生命周期考虑使用一个明确的“资产生命周期管理器”。System通过接口申请资产管理器负责跟踪资产被哪些System引用。当某个World或场景卸载时由管理器统一清理该上下文下的所有资产引用。避免在System中同步加载WaitForCompletion这会在主线程阻塞且容易让引用管理变得复杂。尽量使用异步加载并在System中妥善管理AsyncOperationHandle的生命周期确保在System销毁时调用Addressables.Release(handle)。4.2 Entity与Prefab引用的正确释放这是DOTS泄漏的重灾区。当你通过EntityManager.Instantiate实例化一个EntityPrefab后即使你调用EntityManager.DestroyEntity销毁了所有实例那个EntityPrefab资产本身以及它通过组件间接引用的其他资产可能仍然被引用。关键检查点Prefab实例化源你用来实例化的EntityPrefab是从哪里来的如果是通过Addressables.LoadAssetAsyncEntity加载的那么在不再需要这个Prefab模板时例如整个森林场景都不再需要你必须调用Addressables.Release释放这个EntityPrefab资产本身而不仅仅是销毁Entity实例。组件中的托管对象引用检查你的IComponentData中是否直接包含了UnityEngine.Object类型如Material,Texture,GameObject的字段。DOTS默认不支持在组件中直接存储托管对象引用除非使用[Managed]属性但这会带来GC和Burst兼容性问题。常见的做法是存储一个索引、Key或AssetReference。你需要确保这些间接引用背后的资产生命周期被正确管理。例如使用一个中央的AssetService来将Key解析为实际对象并在场景卸载时通知AssetService清理该场景相关的缓存。BlobAsset引用如果资产数据存储在BlobAsset中如配置表字符串并且BlobAsset中包含了指向其他BlobAsset的指针需要确保BlobAsset本身被正确释放BlobAssetReference.Dispose()。4.3 Addressables与场景加载的最佳实践适配DOTSAddressables API本身并非为DOTS设计需要一些适配。场景加载与Entity场景使用Addressables.LoadSceneAsync加载的场景如果其中包含DOTS的SubScene或Entity场景需要特别注意。Unity在后台可能会为SubScene创建额外的World或管理Entity。确保你的场景卸载逻辑不仅调用了Addressables.UnloadSceneAsync还遍历了所有World清理了属于该场景的Entity。可以使用EntityManager.GetAllUniqueSharedComponents或场景标签组件来筛选Entity。引用计数的手动干预在某些复杂情况下Addressables的自动引用计数可能出错。我们的工具可以帮助发现哪些资产的引用计数异常。作为临时应对措施可以在确认安全的情况下在场景卸载的最后阶段强制释放特定资产// 谨慎使用必须在确认没有其他地方需要该资产后调用。 var handle Addressables.LoadAssetAsyncMaterial(“Mat_Tree”); // ... 使用资产 ... // 在清理阶段如果工具显示它仍被引用但逻辑上不应如此 Addressables.Release(handle); // 或者更激进地释放所有该标签的资产 Addressables.Release(Addressables.LoadResourceLocationsAsync(“forest_materials”).WaitForCompletion());使用Addressables.EventViewer这是一个官方调试工具可以在Editor的Window Asset Management Addressables Event Viewer中打开。它可以实时查看所有Addressables的加载、释放事件结合我们的内存图谱工具能更清晰地看到引用计数的变化过程。5. 性能优化与预防措施解决已发生的泄漏很重要但防患于未然更关键。以下是在DOTS项目中预防AssetBundle引用泄漏的架构和编码实践。5.1 架构层面引入显式的资产生命周期域为资产引用引入一个明确的“域”Domain或“上下文”Context概念。例如定义一个AssetContext结构它与一个游戏玩法模块或一个场景绑定。public class AssetContext : IDisposable { public string ContextId { get; } private HashSetAsyncOperationHandle m_Handles new HashSetAsyncOperationHandle(); private HashSetEntity m_ReferencedEntities new HashSetEntity(); // 可选用于跟踪Entity public T LoadAssetT(string key) where T : UnityEngine.Object { var handle Addressables.LoadAssetAsyncT(key); m_Handles.Add(handle); return handle.WaitForCompletion(); // 或管理异步 } public void TrackEntity(Entity entity) { /* 将Entity与此上下文关联 */ } public void Dispose() { foreach (var handle in m_Handles) { if (handle.IsValid()) Addressables.Release(handle); } m_Handles.Clear(); // 清理与此上下文关联的Entity // ... } }当一个场景或模块卸载时直接销毁其对应的AssetContext对象确保所有通过它加载的资产引用都被集中释放。System只能通过其所属的上下文来加载资产。5.2 编码规范DOTS下的资源管理“军规”禁止在System中持有长期资产引用System应尽可能无状态。如需缓存使用上文提到的上下文机制并确保在OnDestroy中清理。为所有通过Addressables加载的资产定义卸载点在代码设计文档中明确记录每一个LoadAssetAsync或LoadSceneAsync调用都对应一个Release或UnloadSceneAsync调用在何处发生。使用依赖分析工具进行代码审查在提交代码前使用Unity的AssetDatabase.GetDependencies或编写简单的脚本分析新增的Prefab或资产所引用的其他资产评估其复杂性和潜在泄漏风险。自动化测试集成将我们的内存分析工具集成到自动化测试流程中。编写一个测试用例模拟玩家反复进入/退出某个子场景N次然后在测试结束后触发内存快照分析断言特定AssetBundle的引用计数为0或内存增长在阈值以内。5.3 监控与预警在开发期和测试期持续监控Profiler Memory Deep Profile定期查看UnityEngine.Object的数量和内存占用趋势。Addressables Profiler模块监控AssetBundle的加载、卸载和引用计数。自定义指标在游戏中输出日志记录关键AssetBundle的引用计数和已加载的Entity数量。当数值超过预期时发出警告。6. 常见问题排查与实战案例即使遵循了最佳实践复杂的项目依然可能遇到棘手的泄漏。这里记录几个我们实际遇到的案例和排查思路。案例一Job中捕获的引用// 错误代码 var material someMaterial; // 从某个地方获取的Material引用 Entities.ForEach((ref RenderMesh renderMesh) { // Job中使用了外部捕获的material if (someCondition) renderMesh.material material; // 这可能导致material被Job持有生命周期混乱 }).Schedule();排查与修复在Schedule Job时如果Job中使用了托管对象引用尽管DOTS的Entities.ForEach会尝试阻止你这么做但通过一些方式还是可能传入需要极其小心。确保这些引用的生命周期长于Job的执行时间并且在Job完成后有明确的释放逻辑。更好的做法是将资产引用转换为索引或ID在Job中使用在主线程System中再进行解析和赋值。案例二跨World的Entity引用泄漏我们有一个客户端World和一个服务器World用于预测或逻辑计算。服务器World中的某个System创建了一些Entity这些Entity的组件中包含了AssetReference。当客户端场景卸载时我们只清理了客户端World服务器World中的这些Entity没有被清理导致其引用的资产无法释放。排查与修复使用我们的分析工具发现泄漏的资产被一个位于ServerSimulationWorld的Entity引用。修复方案是在场景卸载时遍历所有World查找并销毁所有带有该场景标签或关联上下文的Entity。案例三Shader变体导致的材质泄漏这是一个更隐蔽的问题。我们动态创建了一个材质实例new Material(shader)并设置了不同的纹理。这个材质实例没有被任何AssetBundle管理但它引用了Shader。当大量这样的材质实例没有被销毁时它们持有的Shader引用可能导致Shader相关的资源无法卸载间接影响性能。排查与修复内存图谱显示大量Material (Instance)对象其根引用是某个动态生成管理器。修复方案是对动态创建的材质实行对象池管理或在不再需要时主动调用Destroy(material)。通用排查清单内存只增不减运行游戏反复执行某个操作如进入/退出场景10-20次观察Profiler中Total Used Memory或GC Used Memory趋势。如果呈现阶梯式上升且不回落基本确定有泄漏。AssetBundle计数异常在脚本中打印AssetBundle.GetAllLoadedAssetBundles()的数量和每个bundle的引用计数。在场景卸载后观察计数是否归零。使用Unity的Memory Profiler抓取两个时间点的内存快照操作前 vs 操作后进行对比查看哪些对象类型增加了。重点关注Texture2D,Material,Mesh,GameObject。缩小范围通过注释代码、分模块测试逐步定位泄漏发生的具体系统或功能模块。工具验证使用本文介绍的自定义分析工具对疑似泄漏的资产进行引用链追踪找到根源。内存管理尤其是DOTS与AssetBundle交织下的内存管理是一个细致且需要持续关注的工作。它没有一劳永逸的银弹需要的是清晰的设计、严谨的编码习惯和得力的排查工具。希望这篇文章和这个简单的分析工具能为你照亮DOTS性能优化路上的一些暗坑。
Unity DOTS内存泄漏排查：AssetBundle引用计数问题分析与自动化工具实现
发布时间：2026/7/13 7:32:05
1. 项目概述从一次线上卡顿事故说起那天下午项目组里负责战斗模块的老王突然在群里发了个截图游戏帧率从稳定的60帧骤降到个位数持续了将近5秒玩家反馈直接炸了。我们紧急回滚版本、排查日志最终定位到一个诡异的现象每当玩家通过传送点进入一个特定的“幽暗森林”子场景时主线程就会发生一次明显的卡顿而Profiler里显示大量的时间花在了“Loading.Preload”和“SerializedFile.Read”上。这不对劲这个子场景的AssetBundle明明不大美术资源也做了优化按说不该这么卡。更头疼的是随着玩家在线时间增长游戏的整体内存占用会缓慢而坚定地攀升直到触发OOM崩溃。直觉告诉我这不仅仅是“资源太大”那么简单背后一定藏着某种隐性的资源泄漏。我们项目正从传统的GameObject转向Unity DOTS 1.0架构大量逻辑用ECS和Jobs重写AssetBundle则用Addressables管理。问题就出在这个新旧架构的夹缝里——DOTS Entity引用的Prefab通过AssetBundle加载后其引用计数似乎没有在场景卸载时被正确清理。这不是一个简单的“忘记调用Release”的问题而是一条在DOTS 1.0到1.5版本中可能存在的、由引擎底层引用计数管理机制与上层AssetBundle生命周期错位导致的泄漏链。为了彻底揪出这条链并给团队提供一个可持续的排查手段我花了些时间研究并实现了一个基于Unity Editor的内存引用关系图谱自动化分析工具。今天我就把这个从问题定位、原理剖析到工具实战的完整过程分享出来希望能帮到同样在DOTS迁移深水区挣扎的兄弟们。2. 核心问题拆解为什么DOTSAssetBundle容易“漏”要理解这个泄漏链我们得先抛开DOTS那些复杂的ComponentSystem和Entity回到Unity资源管理的基石引用计数Reference Counting和AssetBundle的生命周期。2.1 传统模式与DOTS模式下的资源引用差异在传统的GameObject/Component模式下一个Prefab从AssetBundle中加载出来比如通过Addressables.LoadAssetAsyncGameObject实例化成场景中的GameObject。这个GameObject身上挂载的脚本、Renderer组件引用的Material和Texture都形成了清晰的引用链。当你销毁这个GameObject或卸载包含它的场景时只要你没有在其他地方持有这些资源的引用Unity的垃圾回收GC和AssetBundle的引用计数机制通常会协同工作最终在合适的时机比如调用Resources.UnloadUnusedAssets或Addressables的释放接口将资源内存释放并将AssetBundle的引用计数减到0从而允许其被卸载。然而在DOTS架构下情况变了。我们不再直接实例化GameObject的Prefab而是通过EntityManager.Instantiate来实例化一个Entity的Prefab通常是一个EntityPrefab。这个EntityPrefab本身也是一个可序列化的资产它可能通过IBufferElementData组件间接引用了一个复杂的Prefab结构这个结构里包含了需要从AssetBundle加载的Mesh、Material等子资产。关键在于DOTS的序列化与引用管理路径与传统AssetBundle的引用计数系统并不总是完全同步的。2.2 泄漏链的形成一个被忽视的“三角关系”泄漏往往发生在一个典型的“子场景动态加载”用例中。假设我们有一个主场景Main和一个子场景Forest打包成AssetBundlescene_forest.bundle。加载Loading玩家触发传送代码调用Addressables.LoadSceneAsync(“Forest”, LoadSceneMode.Additive)。Unity加载scene_forest.bundle并实例化其中的EntityPrefab比如一棵树TreeEntityPrefab。引用建立Reference CreationTreeEntityPrefab的某个IComponentData例如一个RenderMesh组件内部包含了对另一个AssetBundlematerials.bundle中某个材质球Mat_Tree的引用。此时Unity底层会为Mat_Tree增加引用计数。同时scene_forest.bundle本身也因为场景加载而被引用。卸载Unloading玩家离开森林代码调用Addressables.UnloadSceneAsync(sceneInstance)或直接卸载场景。理想情况下所有引用都应该被释放。泄漏发生Leak Occurrence问题在于DOTS Entity在销毁时其组件数据所持有的对非托管数据如BlobAsset或通过特定方式引用的托管对象的引用可能没有触发AssetBundle引用计数的递减操作。特别是当引用是通过序列化后的EntityPrefab间接持有时这个释放信号可能在场景卸载流程中被遗漏。于是Mat_Tree的引用计数仍然 0导致materials.bundle无法卸载。更糟糕的是scene_forest.bundle本身可能因为内部Entity结构的某种残留引用也无法完全卸载。链式反应Chain Reaction如果Mat_Tree又引用了textures.bundle中的一张贴图那么这张贴图也会被连带“锁住”。这就形成了一条从场景AssetBundle到材质AssetBundle再到贴图AssetBundle的泄漏链。每次加载/卸载子场景这些“僵尸”引用就累积一次内存占用稳步上涨而加载新场景时Unity可能需要重新加载那些本该在内存中、但引用计数紊乱的资源从而引发主线程的IO阻塞和反序列化卡顿。注意这种泄漏在Editor中可能不明显因为Editor有更宽松的内存管理和调试加载。一旦发布到真机尤其是内存受限的移动设备问题就会急剧放大表现为加载时间变长、内存增长、最终崩溃。3. 内存引用图谱自动化分析工具的设计与实现光知道原理不够我们需要一个“显微镜”来直观地看到到底是哪个Entity、哪个组件、通过什么路径持有了哪个AssetBundle里的哪个资源。手动在Profiler里翻看ManagedHeap和NativeHeap如同大海捞针。因此我决定打造一个Editor工具自动化分析当前内存中的对象引用关系并生成可视化的图谱。3.1 工具的核心目标与架构工具的目标很明确快照能力能在游戏运行时的任意时刻尤其是疑似泄漏发生后捕获当前内存中所有活跃的UnityEngine.Object及其引用关系。过滤与聚焦能快速过滤出与AssetBundle相关的对象并追踪其引用根路径。可视化输出生成一张清晰的图谱标明从“疑似泄漏的资产”回溯到“根源Entity或管理器”的完整引用链。自动化与集成最好能一键操作并集成到我们的CI流水线中在自动化测试后检查内存异常。工具的整体架构分为三层数据采集层利用Unity的Object.FindObjectsOfTypeObject(true)注意此API在运行时效率需谨慎我们仅在诊断时使用或更底层的UnityEditor.ObjectInfo接口需通过反射调用内部方法获取所有对象实例。同时通过AssetDatabase.GetAllAssetPaths和AssetDatabase.GetDependencies来建立资产路径与对象的关联。对于AssetBundle则通过AssetBundle.GetAllLoadedAssetBundles获取列表并查询每个bundle的引用计数通过AssetBundle.m_AssetBundle的私有字段反射获得。关系分析层这是最核心也最复杂的部分。我们需要分析对象间的引用关系。对于托管对象可以使用WeakReference和条件编译仅在UNITY_EDITOR下调用UnityEditor.EditorUtility.CollectDependencies来收集一个对象的直接依赖。但更有效的是针对Entity和ComponentData我们需要通过EntityManager遍历所有Entity检查其组件数据中是否包含对特定UnityEngine.Object的引用例如通过ComponentType和EntityManager.GetComponentData读取Entity的RenderMesh组件获取其中的material字段。可视化与输出层将分析结果以树状结构或图结构组织。我选择了输出为JSON格式然后使用一个简单的HTML页面配合vis.js库来渲染交互式网络图。同时在Unity Editor内也生成一个可折叠的树状UI方便快速浏览。3.2 关键代码实现如何捕获Entity对资产的引用下面这段代码展示了工具如何遍历所有Entity寻找对特定材质资产的引用。这是分析层的关键。using Unity.Entities; using Unity.Collections; using UnityEngine; public class MemoryReferenceAnalyzer { private World m_World; private DictionaryUnityEngine.Object, ListEntityReferencePath m_ReferenceMap; public void AnalyzeAssetReferences(UnityEngine.Object targetAsset) { m_ReferenceMap new DictionaryUnityEngine.Object, ListEntityReferencePath(); var allWorlds World.All; foreach (var world in allWorlds) { m_World world; var entityManager m_World.EntityManager; var query entityManager.CreateEntityQuery(ComponentType.ReadOnlyRenderMesh()); var entities query.ToEntityArray(Allocator.TempJob); try { foreach (var entity in entities) { var renderMesh entityManager.GetComponentDataRenderMesh(entity); // 检查material引用 if (renderMesh.material targetAsset) { RecordReference(entity, targetAsset, “RenderMesh.material”); } // 检查mesh引用如果也需要 // if (renderMesh.mesh targetAsset) ... } } finally { entities.Dispose(); query.Dispose(); } // 同样方式检查其他可能持有引用的ComponentData如PrefabReference组件等 AnalyzeCustomComponentReferences(entityManager, targetAsset); } GenerateReport(); } private void RecordReference(Entity entity, UnityEngine.Object asset, string referencePath) { if (!m_ReferenceMap.ContainsKey(asset)) { m_ReferenceMap[asset] new ListEntityReferencePath(); } m_ReferenceMap[asset].Add(new EntityReferencePath { WorldName m_World.Name, Entity entity, Path referencePath, // 可以进一步获取Entity的名称或索引 }); } private void AnalyzeCustomComponentReferences(EntityManager entityManager, UnityEngine.Object targetAsset) { // 这里需要根据项目实际使用的、可能持有资产引用的自定义IComponentData进行扩展。 // 例如一个“AssetReferenceData”组件里面存储了Addressables的Key或Instance ID。 // 可能需要用到反射或代码生成来通用化处理。 } private void GenerateReport() { // 将m_ReferenceMap序列化为JSON或直接在EditorWindow中绘制UI } } struct EntityReferencePath { public string WorldName; public Entity Entity; public string Path; }实操心得直接遍历所有Entity和组件对性能影响很大绝对不要在发布的游戏逻辑中调用。这个工具仅限在开发阶段、发现问题后在Editor中或通过Development Build连接Profiler时进行“诊断性”执行。可以考虑在工具中增加采样率控制如每N帧分析一次或仅分析特定World/Query的结果。3.3 工具的使用流程与图谱解读复现问题在编辑器中运行游戏执行一系列操作直到你认为内存泄漏可能已经发生例如反复加载/卸载某个子场景10次。触发分析在游戏运行时通过自定义的Editor窗口点击“捕获当前内存快照”按钮。等待分析工具会运行一段时间取决于场景复杂度期间游戏可能会卡顿这是正常的。查看结果AssetBundle列表工具会列出所有已加载的AssetBundle及其当前引用计数。重点关注引用计数异常高比如大于预期加载的场景或资源数量或卸载后计数不为0的Bundle。可疑资产追踪点击某个计数异常的Bundle工具会展开显示该Bundle中包含的所有资产如材质、贴图、网格。再点击某个具体资产如Mat_Tree右侧会显示“引用图谱”。解读图谱图谱通常是一个从右向左的箭头图。最右边是目标资产Mat_Tree箭头指向它的可能是一个具体的Entity显示为Entity: 1234 (World: ClientWorld)。一个EntityPrefab资产Assets/Prefabs/Tree.prefab。一个MonoBehaviour脚本实例。一个静态类或管理器的静态字段。 沿着箭头向左回溯你可能会发现这个Entity属于某个未销毁的System或者这个Prefab被缓存在某个全局的Dictionarystring, EntityPrefab里而忘记清理。典型泄漏图谱示例AssetBundle: “materials.bundle” (RefCount: 3) └── Asset: “Mat_Tree” (InstanceID: 1001) ├── Referenced By: Entity: 5678 (World: ClientWorld) via “RenderMesh.material” │ └── Belongs To: Scene “Forest (Additive)” (但该场景已调用Unload!) │ └── Root Cause: System “RenderMeshUpdateSystem” 的静态缓存列表未在场景卸载时清除对应Entity。 ├── Referenced By: Prefab “Assets/Prefabs/TreeEntity.prefab” (Loaded from “prefabs.bundle”) │ └── Referenced By: DynamicBufferPrefabReference in Entity: 9012 (World: ServerWorld) │ └── Root Cause: 服务器World的Entity跨网络同步后客户端的清理逻辑未同步处理此Buffer。通过这样的图谱我们就能精准定位到泄漏的根源代码位置。4. 针对DOTS 1.0~1.5的专项排查与修复策略有了分析工具我们就可以系统地排查和修复DOTS项目中的AssetBundle引用泄漏问题。以下是一些针对性的策略。4.1 系统System生命周期管理与静态数据清理很多泄漏源于System的设计。在DOTS中System是持续运行的如果它在OnCreate()或某个字段中缓存了对资产或Entity的引用并且在OnDestroy()中没有正确清理就会导致泄漏。错误示例public class TreeRenderSystem : SystemBase { private Dictionaryint, Material m_CachedMaterials new Dictionaryint, Material(); // 静态或实例字段缓存 protected override void OnCreate() { // 可能预加载一些材质 var mat Addressables.LoadAssetAsyncMaterial(“Mat_Tree”).WaitForCompletion(); m_CachedMaterials[0] mat; // 加载后存入缓存 } protected override void OnUpdate() { /* 使用缓存 */ } // 缺少 OnDestroy 来释放Addressables引用 }修复方案审查所有System检查每个System的字段特别是static字段或引用类型如Dictionary,List。确保在System被销毁OnDestroy或关联的World被销毁时清理这些引用。使用依赖注入与明确的生命周期考虑使用一个明确的“资产生命周期管理器”。System通过接口申请资产管理器负责跟踪资产被哪些System引用。当某个World或场景卸载时由管理器统一清理该上下文下的所有资产引用。避免在System中同步加载WaitForCompletion这会在主线程阻塞且容易让引用管理变得复杂。尽量使用异步加载并在System中妥善管理AsyncOperationHandle的生命周期确保在System销毁时调用Addressables.Release(handle)。4.2 Entity与Prefab引用的正确释放这是DOTS泄漏的重灾区。当你通过EntityManager.Instantiate实例化一个EntityPrefab后即使你调用EntityManager.DestroyEntity销毁了所有实例那个EntityPrefab资产本身以及它通过组件间接引用的其他资产可能仍然被引用。关键检查点Prefab实例化源你用来实例化的EntityPrefab是从哪里来的如果是通过Addressables.LoadAssetAsyncEntity加载的那么在不再需要这个Prefab模板时例如整个森林场景都不再需要你必须调用Addressables.Release释放这个EntityPrefab资产本身而不仅仅是销毁Entity实例。组件中的托管对象引用检查你的IComponentData中是否直接包含了UnityEngine.Object类型如Material,Texture,GameObject的字段。DOTS默认不支持在组件中直接存储托管对象引用除非使用[Managed]属性但这会带来GC和Burst兼容性问题。常见的做法是存储一个索引、Key或AssetReference。你需要确保这些间接引用背后的资产生命周期被正确管理。例如使用一个中央的AssetService来将Key解析为实际对象并在场景卸载时通知AssetService清理该场景相关的缓存。BlobAsset引用如果资产数据存储在BlobAsset中如配置表字符串并且BlobAsset中包含了指向其他BlobAsset的指针需要确保BlobAsset本身被正确释放BlobAssetReference.Dispose()。4.3 Addressables与场景加载的最佳实践适配DOTSAddressables API本身并非为DOTS设计需要一些适配。场景加载与Entity场景使用Addressables.LoadSceneAsync加载的场景如果其中包含DOTS的SubScene或Entity场景需要特别注意。Unity在后台可能会为SubScene创建额外的World或管理Entity。确保你的场景卸载逻辑不仅调用了Addressables.UnloadSceneAsync还遍历了所有World清理了属于该场景的Entity。可以使用EntityManager.GetAllUniqueSharedComponents或场景标签组件来筛选Entity。引用计数的手动干预在某些复杂情况下Addressables的自动引用计数可能出错。我们的工具可以帮助发现哪些资产的引用计数异常。作为临时应对措施可以在确认安全的情况下在场景卸载的最后阶段强制释放特定资产// 谨慎使用必须在确认没有其他地方需要该资产后调用。 var handle Addressables.LoadAssetAsyncMaterial(“Mat_Tree”); // ... 使用资产 ... // 在清理阶段如果工具显示它仍被引用但逻辑上不应如此 Addressables.Release(handle); // 或者更激进地释放所有该标签的资产 Addressables.Release(Addressables.LoadResourceLocationsAsync(“forest_materials”).WaitForCompletion());使用Addressables.EventViewer这是一个官方调试工具可以在Editor的Window Asset Management Addressables Event Viewer中打开。它可以实时查看所有Addressables的加载、释放事件结合我们的内存图谱工具能更清晰地看到引用计数的变化过程。5. 性能优化与预防措施解决已发生的泄漏很重要但防患于未然更关键。以下是在DOTS项目中预防AssetBundle引用泄漏的架构和编码实践。5.1 架构层面引入显式的资产生命周期域为资产引用引入一个明确的“域”Domain或“上下文”Context概念。例如定义一个AssetContext结构它与一个游戏玩法模块或一个场景绑定。public class AssetContext : IDisposable { public string ContextId { get; } private HashSetAsyncOperationHandle m_Handles new HashSetAsyncOperationHandle(); private HashSetEntity m_ReferencedEntities new HashSetEntity(); // 可选用于跟踪Entity public T LoadAssetT(string key) where T : UnityEngine.Object { var handle Addressables.LoadAssetAsyncT(key); m_Handles.Add(handle); return handle.WaitForCompletion(); // 或管理异步 } public void TrackEntity(Entity entity) { /* 将Entity与此上下文关联 */ } public void Dispose() { foreach (var handle in m_Handles) { if (handle.IsValid()) Addressables.Release(handle); } m_Handles.Clear(); // 清理与此上下文关联的Entity // ... } }当一个场景或模块卸载时直接销毁其对应的AssetContext对象确保所有通过它加载的资产引用都被集中释放。System只能通过其所属的上下文来加载资产。5.2 编码规范DOTS下的资源管理“军规”禁止在System中持有长期资产引用System应尽可能无状态。如需缓存使用上文提到的上下文机制并确保在OnDestroy中清理。为所有通过Addressables加载的资产定义卸载点在代码设计文档中明确记录每一个LoadAssetAsync或LoadSceneAsync调用都对应一个Release或UnloadSceneAsync调用在何处发生。使用依赖分析工具进行代码审查在提交代码前使用Unity的AssetDatabase.GetDependencies或编写简单的脚本分析新增的Prefab或资产所引用的其他资产评估其复杂性和潜在泄漏风险。自动化测试集成将我们的内存分析工具集成到自动化测试流程中。编写一个测试用例模拟玩家反复进入/退出某个子场景N次然后在测试结束后触发内存快照分析断言特定AssetBundle的引用计数为0或内存增长在阈值以内。5.3 监控与预警在开发期和测试期持续监控Profiler Memory Deep Profile定期查看UnityEngine.Object的数量和内存占用趋势。Addressables Profiler模块监控AssetBundle的加载、卸载和引用计数。自定义指标在游戏中输出日志记录关键AssetBundle的引用计数和已加载的Entity数量。当数值超过预期时发出警告。6. 常见问题排查与实战案例即使遵循了最佳实践复杂的项目依然可能遇到棘手的泄漏。这里记录几个我们实际遇到的案例和排查思路。案例一Job中捕获的引用// 错误代码 var material someMaterial; // 从某个地方获取的Material引用 Entities.ForEach((ref RenderMesh renderMesh) { // Job中使用了外部捕获的material if (someCondition) renderMesh.material material; // 这可能导致material被Job持有生命周期混乱 }).Schedule();排查与修复在Schedule Job时如果Job中使用了托管对象引用尽管DOTS的Entities.ForEach会尝试阻止你这么做但通过一些方式还是可能传入需要极其小心。确保这些引用的生命周期长于Job的执行时间并且在Job完成后有明确的释放逻辑。更好的做法是将资产引用转换为索引或ID在Job中使用在主线程System中再进行解析和赋值。案例二跨World的Entity引用泄漏我们有一个客户端World和一个服务器World用于预测或逻辑计算。服务器World中的某个System创建了一些Entity这些Entity的组件中包含了AssetReference。当客户端场景卸载时我们只清理了客户端World服务器World中的这些Entity没有被清理导致其引用的资产无法释放。排查与修复使用我们的分析工具发现泄漏的资产被一个位于ServerSimulationWorld的Entity引用。修复方案是在场景卸载时遍历所有World查找并销毁所有带有该场景标签或关联上下文的Entity。案例三Shader变体导致的材质泄漏这是一个更隐蔽的问题。我们动态创建了一个材质实例new Material(shader)并设置了不同的纹理。这个材质实例没有被任何AssetBundle管理但它引用了Shader。当大量这样的材质实例没有被销毁时它们持有的Shader引用可能导致Shader相关的资源无法卸载间接影响性能。排查与修复内存图谱显示大量Material (Instance)对象其根引用是某个动态生成管理器。修复方案是对动态创建的材质实行对象池管理或在不再需要时主动调用Destroy(material)。通用排查清单内存只增不减运行游戏反复执行某个操作如进入/退出场景10-20次观察Profiler中Total Used Memory或GC Used Memory趋势。如果呈现阶梯式上升且不回落基本确定有泄漏。AssetBundle计数异常在脚本中打印AssetBundle.GetAllLoadedAssetBundles()的数量和每个bundle的引用计数。在场景卸载后观察计数是否归零。使用Unity的Memory Profiler抓取两个时间点的内存快照操作前 vs 操作后进行对比查看哪些对象类型增加了。重点关注Texture2D,Material,Mesh,GameObject。缩小范围通过注释代码、分模块测试逐步定位泄漏发生的具体系统或功能模块。工具验证使用本文介绍的自定义分析工具对疑似泄漏的资产进行引用链追踪找到根源。内存管理尤其是DOTS与AssetBundle交织下的内存管理是一个细致且需要持续关注的工作。它没有一劳永逸的银弹需要的是清晰的设计、严谨的编码习惯和得力的排查工具。希望这篇文章和这个简单的分析工具能为你照亮DOTS性能优化路上的一些暗坑。
