游戏性能 Profiling交付前核对哪些指标和场景交付检查从功能、异常、性能和回退四个方向逐项走。 这篇只讨论可落地的拆法先明确卡顿发生在 CPU、GPU、加载还是脚本分配再选择工具。每次采样固定场景、画质、设备档位和操作路径避免把不同条件下的曲线放在一起比较。先定边界CPU 侧先看主线程与 Job 等待GPU 侧看渲染 pass、批次和 overdraw内存分析把临时分配、资源常驻和泄漏线索分开。优化前保留基线快照。不要用一句“模型会处理”或“框架会处理”掩盖状态变化。把输入来源、允许的副作用和异常返回写进接口说明开发、测试和内容制作才能使用同一套判断标准。实现时盯住三个点状态归属谁创建、谁更新、谁负责清理要能从代码和配置里找到答案。异步边界请求、任务或渲染资源都需要超时、取消和完成回调重复调用不能把旧结果覆盖新状态。可回退性把开关和默认行为放在调用边界失败时返回受控结果不把半成品继续传给下游。这样安排的好处是每次改动都能定位到一个责任模块。问题出现时先看边界记录再改实现不必靠猜测追踪整条链路。验证清单对候选修改重复执行同一段录制路径比较调用栈、帧时间分布和分配来源同时检查画面、交互和资源释放避免用关闭功能换取表面结果。检查配置、资源和接口版本是否随构建物一起发布。对每个降级分支确认用户仍能完成当前操作且状态不会被错误写入。把这次发现的前置条件补到验收样例避免下次只重复同一类检查。收尾交付前回到固定场景复测确认性能数据没有掩盖画面或交互上的退化。