游戏运行时内存曲线持续上升，不足以直接判定泄漏。场景切换、贴图加载、缓存扩容和分配器暂时保留内存，都可能让进程占用增加。做好游戏业务内存泄漏监控与定位，关键是比较相同操作阶段的指标，而不是只盯着一条总内存曲线。
先确认上涨的是哪一种内存
进程 RSS 表示当前驻留在物理内存中的页面，托管堆则是运行时管理的对象区域；原生内存还可能来自引擎、图形接口或第三方库。它们的变化不一定同步。比如托管对象已释放，分配器却暂时保留已申请的内存，RSS 仍可能维持高位。
还要区分显存与系统内存。贴图、网格等资源可能占用图形设备内存，具体统计口径取决于平台和工具。判断前先记录指标名称、采集方式与设备环境，避免把不同口径的数据直接比较。
四类常见误判
- 把峰值当泄漏：首次进入关卡时加载资源，峰值上升是常见现象。回到同一关卡重复操作后，若占用趋于稳定，不能仅凭首轮增长认定泄漏。
- 把缓存当泄漏：游戏可能保留已加载资源以缩短再次打开时的等待。观察缓存是否有容量上限、淘汰策略，以及释放场景资源后是否回落。
- 只看总量不看组成：总进程内存平稳，托管堆可能仍持续增长；反过来，托管堆下降也不代表原生分配一定释放。
- 忽略采样和时序：一次快照只是某个时刻的状态。加载动画、后台任务或垃圾回收时机不同，都会影响结果。
按可复现流程定位
- 固定测试条件。选定设备、构建版本和一段可重复的操作，例如反复进入同一关卡、打开并关闭角色详情页。记录每轮起止时间和操作次数。
- 建立基线。启动后等待初始化完成，记下 RSS、托管堆及可获取的原生内存指标。首次加载与后续重复加载分开记录。
- 观察增长是否收敛。连续执行相同流程并在相同节点采样。若每轮结束后的基线持续抬高，且经过空闲等待或正常回收仍不回落，才值得进一步追踪。
- 比较内存快照。在操作前后采集快照，查找数量或保留大小持续增加的对象类型；沿对象引用链检查它们为何仍可达。Unity 项目可使用 Memory Profiler 对比快照，Unreal 项目可结合 Unreal Insights 的内存分析能力，具体功能取决于引擎版本与构建配置。
- 检查原生分配路径。若托管堆稳定而进程占用仍涨，排查纹理、音频、插件及平台接口的创建与释放配对。对照资源句柄生命周期，并在退出场景后验证资源是否仍被引用。
- 修复后重复验证。用相同设备和步骤复测，检查增长曲线是否收敛，并确认没有用过度清理造成卡顿或重复加载。
监控应关注趋势与边界
游戏业务内存泄漏监控与定位不应只设置一个通用数值门槛。不同设备的可用内存、系统版本、画质和关卡内容差异很大。更实用的做法是按设备档位和玩法阶段建立基线，同时关注连续多轮操作后的基线变化、资源释放后的回落情况，以及接近平台内存限制时是否出现系统回收或进程被终止。
告警最好带上版本、设备档位、关卡和操作阶段。线上数据用于发现异常分布，复现环境中的快照与分配记录才更适合追根因；单个峰值通常不能直接证明代码存在泄漏。
常见问题
内存升高后没有立刻下降，算泄漏吗？
不一定。缓存和分配器可能保留空间。应观察重复操作后的基线，并确认资源是否仍被引用。
垃圾回收后进程占用没降，怎么办？
先分别查看托管堆与进程驻留内存。对象回收不保证分配器立即把内存归还系统。
只有特定设备出现增长，能否忽略？
不能。设备内存和驱动差异可能影响表现，应在相同档位复现，并检查对应构建与资源配置。
因此，内存持续上涨只是排查信号，不是结论。以固定操作建立基线，再区分托管堆、原生内存和缓存，最后通过快照与引用链验证，才是可靠的游戏业务内存泄漏监控与定位路径。