资源泄漏检测与治理篇章09-核心技术-内存管理篇 |阅读时间约 40 分钟 |前置知识了解 Unity 资源系统和 GC 基本概念一、引言资源泄漏是 Unity 项目中最隐蔽的内存问题。泄漏的资源在被完全释放前会持续占用内存并增加 GC 压力。最常见的泄漏模式是C# 侧持有 UnityEngine.Object 的引用阻止了引擎端释放。资源泄漏的危害随时间累积。单个泄漏可能只占用几 KB 或几 MB但在长时间运行的游戏中泄漏会像雪崩一样累积。一个每小时泄漏 1MB 的游戏运行 24 小时后泄漏 24MB运行一周后泄漏超过 160MB。在内存受限的移动设备上这种渐进式泄漏往往在运行数小时后触发 OOM 崩溃且难以复现和定位。核心论点资源泄漏检测与治理不是一次性的任务而是持续的过程。它需要工具链支持Memory Profiler、自动化测试、流程保障代码审查、资源清单、团队协作每类资源明确负责人和持续监控CI 集成、线上 OOM 追踪。只有建立完整的治理体系才能将泄漏风险控制在可接受范围内。二、常见泄漏模式的深度分析2.1 静态持有泄漏静态字段是资源泄漏最常见的来源之一。静态字段的存活周期与应用相同GC 永远不会回收它们。如果静态字段持有 UnityEngine.Object 引用这些对象将永远驻留在内存中直到应用退出。静态持有泄漏的典型场景是开发者创建一个缓存字典用于存储加载的资源但从未实现清理逻辑。随着游戏运行字典不断增长占用越来越多的内存。更隐蔽的是静态字段可能通过事件订阅、回调闭包等间接方式持有引用这些引用在代码审查中难以发现。2.2 事件未解绑泄漏事件绑定是另一个常见的泄漏源。每次调用 AddListener 或 订阅事件订阅者对象就会被事件源持有一个引用。如果对应的 RemoveListener 或 - 解绑操作没有被调用订阅者对象及其所有引用链上的资源都不会被 GC 回收。事件泄漏的典型场景是UI 面板在 OnEnable 中订阅事件但在 OnDisable 中忘记解绑。每次打开面板都会增加一个新的订阅而旧订阅永远不会被移除。面板打开十次就产生十个泄漏的订阅每个订阅都持有面板对象及其所有资源的引用。2.3 DontDestroyOnLoad 滥用DontDestroyOnLoad 的对象在场景切换时不会被销毁其引用的资源也不会被 UnloadUnusedAssets 回收。将不应该标记为 DontDestroyOnLoad 的对象标记后这些对象及其资源将常驻内存。DontDestroyOnLoad 滥用的典型场景是每个 UI 面板都在创建时调用 DontDestroyOnLoad导致所有曾经打开过的 UI 面板都常驻内存。或者在场景切换时每个场景都创建一个新的管理器实例而没有检查是否已存在单例导致多个管理器实例共存。2.4 AssetBundle 未卸载AssetBundle 加载后没有调用 Unload 是资源泄漏的典型模式。AB 的元数据和已加载资源都会占用内存如果不主动卸载这些内存永远不会被释放。AB 泄漏的典型场景是使用 Addressables 加载资源后忘记调用 Release或者手动管理 AB 时只加载不卸载。在大型项目中AB 的数量可能达到数百个每个 AB 的大小从几十 KB 到数百 MB 不等。一个未卸载的 100MB AB 就可能导致移动端 OOM。2.5 协程未停止协程本身不直接持有资源引用但协程中捕获的闭包变量可能持有引用。如果协程在对象销毁后仍在运行闭包中的引用会阻止 GC 回收相关对象。协程泄漏的典型场景是在 MonoBehaviour 中启动协程但在 OnDestroy 中没有调用 StopAllCoroutines。当对象被销毁后协程仍在运行闭包捕获的 this 引用阻止了对象的 GC 回收。三、快照对比法的工程实践3.1 快照对比的基本原理快照对比法的核心思想是在操作前后分别拍摄内存快照对比差异找出新增但未释放的对象。这种方法可以精确定位泄漏的根源而非仅仅观察内存增长的趋势。快照对比的流程是首先在应用稳定状态下拍摄基准快照 A然后执行可疑操作打开关闭 UI、切换场景触发 GC 回收后拍摄快照 B对比 A 和 B 的差异筛选出只存在于 B 中的对象按大小排序检查引用链定位持有引用的根对象。3.2 Memory Profiler 的实际操作Unity Memory Profiler 1.0 提供了编程式快照拍摄 API。通过 MemoryProfiler.TakeSnapshot 方法可以在代码中自动拍摄快照并保存到文件。在 CI 流水线中可以自动执行测试流程、拍摄快照、对比差异、输出报告。快照对比的关键在于对比时的筛选策略。应该筛选只存在于 B 中的对象按大小降序排列优先检查最大的对象。对于每个新对象查看它的引用链找到从 GC Root 到该对象的路径。这条路径上的某个对象就是泄漏的根。3.3 自动化快照对比将快照对比集成到自动化测试中是防止泄漏回归的关键。测试流程为拍摄操作前快照执行测试操作触发 GC拍摄操作后快照对比差异。如果新增对象总大小超过阈值测试失败。自动化快照对比的价值在于它可以作为 CI 流水线的一部分每次代码提交都自动运行。如果某个提交引入了泄漏CI 会立即标记失败防止泄漏代码合并到主分支。四、自动化检测的工程实现4.1 场景切换泄漏测试场景切换泄漏测试是最有效的自动化检测方法之一。测试流程为加载场景 A等待稳定后记录内存基线切换到场景 B等待加载完成触发 GC 回收记录最终内存对比差异。如果内存增长超过阈值测试失败。阈值的设置需要根据项目的具体情况确定。一般来说场景切换后的内存增长应该小于 10MB不包括场景 B 本身的新增资源。如果增长超过这个值说明场景 A 的资源没有被正确卸载。4.2 静态字段泄漏检测静态字段泄漏检测通过分析静态字段中持有的 UnityEngine.Object 引用实现。通过反射获取所有类型的所有静态字段检查哪些字段持有 UnityEngine.Object 或其子类型的引用。对于每个发现的静态引用检查它是否应该被持有。这种检测应该在编辑器中定期运行输出报告。对于每个静态持有的资源对象标注其类型、大小、持有时间。如果某个静态引用持有超过预期时间输出警告。4.3 事件泄漏检测事件泄漏检测通过分析事件订阅关系实现。对于每个事件源检查它的订阅列表找出订阅者对象是否应该仍然活跃。如果订阅者对象已经被 Destroy 但订阅仍然存在说明缺少解绑逻辑。五、治理流程的深度实践5.1 资源生命周期清单资源生命周期清单是治理工作的基础文档。它记录了项目中每类资源的加载方式、加载时机、卸载方式、卸载时机和负责人。建立清单的价值在于在代码审查时对照清单检查每条加载路径是否有对应的卸载路径。缺少卸载路径的就是泄漏。清单的维护应该是持续的。每次新增资源加载逻辑时必须同步更新清单。每次发现泄漏时必须更新清单中对应的条目补充遗漏的卸载路径。5.2 代码审查检查清单代码审查是防止泄漏的第一道防线。审查检查清单包括新增的资源加载代码是否有对应的卸载路径静态字段是否持有 UnityEngine.Object 引用事件绑定是否在生命周期结束时解除协程是否在对象销毁时停止是否有新的内存分配通过 Profiler 验证5.3 泄漏治理的标准流程泄漏治理的标准流程是发现泄漏后使用 Memory Profiler 拍摄操作前快照执行可疑操作触发 GC 回收拍摄操作后快照对比差异追踪引用链定位根对象修复代码验证修复编写自动化测试防止回归。这个流程的核心价值在于它将泄漏治理从经验驱动转变为数据驱动。通过快照对比和引用链追踪可以精确定位泄漏根源而非凭猜测修改代码。通过编写自动化测试确保修复不会回归。六、泄漏检测工具链6.1 工具链的层次结构完整的泄漏检测工具链包含多个层次Memory Profiler 检测托管堆泄漏用于本地测试。Profiler Memory 检测原生内存泄漏用于本地测试。RenderDoc 检测显存泄漏用于 GPU 调试。CI 自动化检测堆增长回归用于每次代码提交。崩溃平台监控 OOM 崩溃率用于线上追踪。6.2 工具链的协作模式工具链的各个工具不是孤立的而是协作的。Memory Profiler 发现托管堆泄漏后可以通过引用链追踪定位到具体的 C# 代码行。Profiler Memory 发现原生内存增长后可以通过 FindObjectsOfTypeAll 统计各类资源数量变化。RenderDoc 发现显存泄漏后可以回溯到创建这些 GPU 资源的 C# 代码。CI 自动化发现堆增长回归后可以自动关联到最近的代码提交通知相关开发者。七、泄漏治理的团队协作7.1 开发规范泄漏治理需要全团队遵循统一的开发规范。所有 AddListener 必须有对应的 RemoveListener写在同一个方法块中。所有 Resources.Load 必须有对应的缓存和卸载逻辑。所有 AssetBundle.Load 必须有对应的 Unload。所有 StartCoroutine 必须在 OnDestroy 中 StopAllCoroutines。7.2 定期审查每周运行一次 Memory Profiler 快照对比检查是否有新的泄漏模式出现。每月审查一次资源生命周期清单确保清单与实际代码同步。每季度进行一次全面的内存审计检查整体内存健康状况。7.3 线上监控上线后监控 OOM 崩溃率是泄漏治理的最后防线。通过崩溃分析服务追踪 OOM 崩溃的设备型号、操作系统版本、游戏时长、崩溃前的操作序列。这些信息可以帮助复现和修复线上泄漏问题。八、总结资源泄漏检测核心是快照对比法加引用链追踪。治理关键是建立资源生命周期清单代码审查中成对检查创建和销毁。标准流程是发现、快照、对比、追踪、修复、验证、防回归。泄漏治理不是一次性的任务而是持续的过程。它需要工具链支持、流程保障、团队协作和持续监控。只有建立完整的治理体系才能将泄漏风险控制在可接受范围内确保游戏在长时间运行后仍然保持稳定的内存占用。7.1 泄漏治理的成熟度模型泄漏治理的能力可以分为五个成熟度等级。第一级初始级没有自动化工具依赖开发者经验发现泄漏。第二级可重复级建立了基本的代码审查流程但缺乏自动化检测。第三级已定义级建立了资源生命周期清单代码审查有明确检查项。第四级已管理级CI 集成自动化泄漏检测每次提交都验证。第五级优化级线上实时监控泄漏趋势AI 辅助定位泄漏根因。项目应该根据自身情况设定目标等级并制定提升计划。大多数项目的合理目标是达到第四级——CI 自动化检测。这需要将泄漏测试集成到现有的 CI 流水线中设置合理的阈值和告警机制。7.2 泄漏治理的度量指标有效的泄漏治理需要可量化的度量指标。核心指标包括泄漏发现平均时间MTTD从泄漏引入到被发现的时间间隔。泄漏修复平均时间MTTR从发现到修复完成的时间间隔。泄漏回归率修复后再次出现同类泄漏的比例。每千行代码泄漏数衡量代码质量的长期趋势指标。这些指标应该定期如每月在团队内部分享作为改进方向的参考。指标的目的不是惩罚开发者而是识别流程中的薄弱环节针对性地改进。7.3 线上泄漏的应急处理即使有完善的检测体系仍可能有泄漏代码流入线上版本。线上泄漏的应急处理流程是通过崩溃分析和用户反馈确认泄漏现象使用远程日志和性能数据定位泄漏模式在热更新中修复泄漏代码在下个大版本中修复原生代码通过 A/B 测试验证修复效果。对于严重的线上泄漏可能需要紧急发布热修复补丁。热修复应该遵循最小变更原则只修复泄漏点不引入新的功能变更。修复后密切监控泄漏指标确保修复有效且没有引入新的问题。从疑似泄漏到可验证修复泄漏判断必须绑定一个本应结束的生命周期。以反复打开角色界面为例先说明关闭界面后哪些对象允许缓存、缓存容量上限是什么再比较第二轮与后续轮次的稳定状态。第一次加载字体、着色器和图集的增长不应直接记为泄漏。缓存超过既定上限仍持续增长则属于另一类同样需要治理的问题。发现新增纹理后先确认它是导入资源、运行时克隆还是插件对象再寻找保留路径。解除某个静态字典条目后如果对象仍存在应继续查事件和异步操作不要重复调用 GC 来试图掩盖所有权缺失。修复应能解释“哪个持有者不该继续存在、在哪条结束路径解除引用”。最终用相同操作脚本复测正常退出和异常退出。报告至少保留对象数变化、稳定状态容量、峰值容量与修复前后的引用链。进程驻留内存可能因为分配器保留而不回到启动值验收重点是对象生命周期是否结束以及长期趋势是否有界。
资源泄漏检测与治理篇章09-核心技术-内存管理篇 |阅读时间约 40 分钟 |前置知识了解 Unity 资源系统和 GC 基本概念一、引言资源泄漏是 Unity 项目中最隐蔽的内存问题。泄漏的资源在被完全释放前会持续占用内存并增加 GC 压力。最常见的泄漏模式是C# 侧持有 UnityEngine.Object 的引用阻止了引擎端释放。资源泄漏的危害随时间累积。单个泄漏可能只占用几 KB 或几 MB但在长时间运行的游戏中泄漏会像雪崩一样累积。一个每小时泄漏 1MB 的游戏运行 24 小时后泄漏 24MB运行一周后泄漏超过 160MB。在内存受限的移动设备上这种渐进式泄漏往往在运行数小时后触发 OOM 崩溃且难以复现和定位。核心论点资源泄漏检测与治理不是一次性的任务而是持续的过程。它需要工具链支持Memory Profiler、自动化测试、流程保障代码审查、资源清单、团队协作每类资源明确负责人和持续监控CI 集成、线上 OOM 追踪。只有建立完整的治理体系才能将泄漏风险控制在可接受范围内。二、常见泄漏模式的深度分析2.1 静态持有泄漏静态字段是资源泄漏最常见的来源之一。静态字段的存活周期与应用相同GC 永远不会回收它们。如果静态字段持有 UnityEngine.Object 引用这些对象将永远驻留在内存中直到应用退出。静态持有泄漏的典型场景是开发者创建一个缓存字典用于存储加载的资源但从未实现清理逻辑。随着游戏运行字典不断增长占用越来越多的内存。更隐蔽的是静态字段可能通过事件订阅、回调闭包等间接方式持有引用这些引用在代码审查中难以发现。2.2 事件未解绑泄漏事件绑定是另一个常见的泄漏源。每次调用 AddListener 或 订阅事件订阅者对象就会被事件源持有一个引用。如果对应的 RemoveListener 或 - 解绑操作没有被调用订阅者对象及其所有引用链上的资源都不会被 GC 回收。事件泄漏的典型场景是UI 面板在 OnEnable 中订阅事件但在 OnDisable 中忘记解绑。每次打开面板都会增加一个新的订阅而旧订阅永远不会被移除。面板打开十次就产生十个泄漏的订阅每个订阅都持有面板对象及其所有资源的引用。2.3 DontDestroyOnLoad 滥用DontDestroyOnLoad 的对象在场景切换时不会被销毁其引用的资源也不会被 UnloadUnusedAssets 回收。将不应该标记为 DontDestroyOnLoad 的对象标记后这些对象及其资源将常驻内存。DontDestroyOnLoad 滥用的典型场景是每个 UI 面板都在创建时调用 DontDestroyOnLoad导致所有曾经打开过的 UI 面板都常驻内存。或者在场景切换时每个场景都创建一个新的管理器实例而没有检查是否已存在单例导致多个管理器实例共存。2.4 AssetBundle 未卸载AssetBundle 加载后没有调用 Unload 是资源泄漏的典型模式。AB 的元数据和已加载资源都会占用内存如果不主动卸载这些内存永远不会被释放。AB 泄漏的典型场景是使用 Addressables 加载资源后忘记调用 Release或者手动管理 AB 时只加载不卸载。在大型项目中AB 的数量可能达到数百个每个 AB 的大小从几十 KB 到数百 MB 不等。一个未卸载的 100MB AB 就可能导致移动端 OOM。2.5 协程未停止协程本身不直接持有资源引用但协程中捕获的闭包变量可能持有引用。如果协程在对象销毁后仍在运行闭包中的引用会阻止 GC 回收相关对象。协程泄漏的典型场景是在 MonoBehaviour 中启动协程但在 OnDestroy 中没有调用 StopAllCoroutines。当对象被销毁后协程仍在运行闭包捕获的 this 引用阻止了对象的 GC 回收。三、快照对比法的工程实践3.1 快照对比的基本原理快照对比法的核心思想是在操作前后分别拍摄内存快照对比差异找出新增但未释放的对象。这种方法可以精确定位泄漏的根源而非仅仅观察内存增长的趋势。快照对比的流程是首先在应用稳定状态下拍摄基准快照 A然后执行可疑操作打开关闭 UI、切换场景触发 GC 回收后拍摄快照 B对比 A 和 B 的差异筛选出只存在于 B 中的对象按大小排序检查引用链定位持有引用的根对象。3.2 Memory Profiler 的实际操作Unity Memory Profiler 1.0 提供了编程式快照拍摄 API。通过 MemoryProfiler.TakeSnapshot 方法可以在代码中自动拍摄快照并保存到文件。在 CI 流水线中可以自动执行测试流程、拍摄快照、对比差异、输出报告。快照对比的关键在于对比时的筛选策略。应该筛选只存在于 B 中的对象按大小降序排列优先检查最大的对象。对于每个新对象查看它的引用链找到从 GC Root 到该对象的路径。这条路径上的某个对象就是泄漏的根。3.3 自动化快照对比将快照对比集成到自动化测试中是防止泄漏回归的关键。测试流程为拍摄操作前快照执行测试操作触发 GC拍摄操作后快照对比差异。如果新增对象总大小超过阈值测试失败。自动化快照对比的价值在于它可以作为 CI 流水线的一部分每次代码提交都自动运行。如果某个提交引入了泄漏CI 会立即标记失败防止泄漏代码合并到主分支。四、自动化检测的工程实现4.1 场景切换泄漏测试场景切换泄漏测试是最有效的自动化检测方法之一。测试流程为加载场景 A等待稳定后记录内存基线切换到场景 B等待加载完成触发 GC 回收记录最终内存对比差异。如果内存增长超过阈值测试失败。阈值的设置需要根据项目的具体情况确定。一般来说场景切换后的内存增长应该小于 10MB不包括场景 B 本身的新增资源。如果增长超过这个值说明场景 A 的资源没有被正确卸载。4.2 静态字段泄漏检测静态字段泄漏检测通过分析静态字段中持有的 UnityEngine.Object 引用实现。通过反射获取所有类型的所有静态字段检查哪些字段持有 UnityEngine.Object 或其子类型的引用。对于每个发现的静态引用检查它是否应该被持有。这种检测应该在编辑器中定期运行输出报告。对于每个静态持有的资源对象标注其类型、大小、持有时间。如果某个静态引用持有超过预期时间输出警告。4.3 事件泄漏检测事件泄漏检测通过分析事件订阅关系实现。对于每个事件源检查它的订阅列表找出订阅者对象是否应该仍然活跃。如果订阅者对象已经被 Destroy 但订阅仍然存在说明缺少解绑逻辑。五、治理流程的深度实践5.1 资源生命周期清单资源生命周期清单是治理工作的基础文档。它记录了项目中每类资源的加载方式、加载时机、卸载方式、卸载时机和负责人。建立清单的价值在于在代码审查时对照清单检查每条加载路径是否有对应的卸载路径。缺少卸载路径的就是泄漏。清单的维护应该是持续的。每次新增资源加载逻辑时必须同步更新清单。每次发现泄漏时必须更新清单中对应的条目补充遗漏的卸载路径。5.2 代码审查检查清单代码审查是防止泄漏的第一道防线。审查检查清单包括新增的资源加载代码是否有对应的卸载路径静态字段是否持有 UnityEngine.Object 引用事件绑定是否在生命周期结束时解除协程是否在对象销毁时停止是否有新的内存分配通过 Profiler 验证5.3 泄漏治理的标准流程泄漏治理的标准流程是发现泄漏后使用 Memory Profiler 拍摄操作前快照执行可疑操作触发 GC 回收拍摄操作后快照对比差异追踪引用链定位根对象修复代码验证修复编写自动化测试防止回归。这个流程的核心价值在于它将泄漏治理从经验驱动转变为数据驱动。通过快照对比和引用链追踪可以精确定位泄漏根源而非凭猜测修改代码。通过编写自动化测试确保修复不会回归。六、泄漏检测工具链6.1 工具链的层次结构完整的泄漏检测工具链包含多个层次Memory Profiler 检测托管堆泄漏用于本地测试。Profiler Memory 检测原生内存泄漏用于本地测试。RenderDoc 检测显存泄漏用于 GPU 调试。CI 自动化检测堆增长回归用于每次代码提交。崩溃平台监控 OOM 崩溃率用于线上追踪。6.2 工具链的协作模式工具链的各个工具不是孤立的而是协作的。Memory Profiler 发现托管堆泄漏后可以通过引用链追踪定位到具体的 C# 代码行。Profiler Memory 发现原生内存增长后可以通过 FindObjectsOfTypeAll 统计各类资源数量变化。RenderDoc 发现显存泄漏后可以回溯到创建这些 GPU 资源的 C# 代码。CI 自动化发现堆增长回归后可以自动关联到最近的代码提交通知相关开发者。七、泄漏治理的团队协作7.1 开发规范泄漏治理需要全团队遵循统一的开发规范。所有 AddListener 必须有对应的 RemoveListener写在同一个方法块中。所有 Resources.Load 必须有对应的缓存和卸载逻辑。所有 AssetBundle.Load 必须有对应的 Unload。所有 StartCoroutine 必须在 OnDestroy 中 StopAllCoroutines。7.2 定期审查每周运行一次 Memory Profiler 快照对比检查是否有新的泄漏模式出现。每月审查一次资源生命周期清单确保清单与实际代码同步。每季度进行一次全面的内存审计检查整体内存健康状况。7.3 线上监控上线后监控 OOM 崩溃率是泄漏治理的最后防线。通过崩溃分析服务追踪 OOM 崩溃的设备型号、操作系统版本、游戏时长、崩溃前的操作序列。这些信息可以帮助复现和修复线上泄漏问题。八、总结资源泄漏检测核心是快照对比法加引用链追踪。治理关键是建立资源生命周期清单代码审查中成对检查创建和销毁。标准流程是发现、快照、对比、追踪、修复、验证、防回归。泄漏治理不是一次性的任务而是持续的过程。它需要工具链支持、流程保障、团队协作和持续监控。只有建立完整的治理体系才能将泄漏风险控制在可接受范围内确保游戏在长时间运行后仍然保持稳定的内存占用。7.1 泄漏治理的成熟度模型泄漏治理的能力可以分为五个成熟度等级。第一级初始级没有自动化工具依赖开发者经验发现泄漏。第二级可重复级建立了基本的代码审查流程但缺乏自动化检测。第三级已定义级建立了资源生命周期清单代码审查有明确检查项。第四级已管理级CI 集成自动化泄漏检测每次提交都验证。第五级优化级线上实时监控泄漏趋势AI 辅助定位泄漏根因。项目应该根据自身情况设定目标等级并制定提升计划。大多数项目的合理目标是达到第四级——CI 自动化检测。这需要将泄漏测试集成到现有的 CI 流水线中设置合理的阈值和告警机制。7.2 泄漏治理的度量指标有效的泄漏治理需要可量化的度量指标。核心指标包括泄漏发现平均时间MTTD从泄漏引入到被发现的时间间隔。泄漏修复平均时间MTTR从发现到修复完成的时间间隔。泄漏回归率修复后再次出现同类泄漏的比例。每千行代码泄漏数衡量代码质量的长期趋势指标。这些指标应该定期如每月在团队内部分享作为改进方向的参考。指标的目的不是惩罚开发者而是识别流程中的薄弱环节针对性地改进。7.3 线上泄漏的应急处理即使有完善的检测体系仍可能有泄漏代码流入线上版本。线上泄漏的应急处理流程是通过崩溃分析和用户反馈确认泄漏现象使用远程日志和性能数据定位泄漏模式在热更新中修复泄漏代码在下个大版本中修复原生代码通过 A/B 测试验证修复效果。对于严重的线上泄漏可能需要紧急发布热修复补丁。热修复应该遵循最小变更原则只修复泄漏点不引入新的功能变更。修复后密切监控泄漏指标确保修复有效且没有引入新的问题。从疑似泄漏到可验证修复泄漏判断必须绑定一个本应结束的生命周期。以反复打开角色界面为例先说明关闭界面后哪些对象允许缓存、缓存容量上限是什么再比较第二轮与后续轮次的稳定状态。第一次加载字体、着色器和图集的增长不应直接记为泄漏。缓存超过既定上限仍持续增长则属于另一类同样需要治理的问题。发现新增纹理后先确认它是导入资源、运行时克隆还是插件对象再寻找保留路径。解除某个静态字典条目后如果对象仍存在应继续查事件和异步操作不要重复调用 GC 来试图掩盖所有权缺失。修复应能解释“哪个持有者不该继续存在、在哪条结束路径解除引用”。最终用相同操作脚本复测正常退出和异常退出。报告至少保留对象数变化、稳定状态容量、峰值容量与修复前后的引用链。进程驻留内存可能因为分配器保留而不回到启动值验收重点是对象生命周期是否结束以及长期趋势是否有界。
