性能 Profiling 开发短记一次故障复盘留下什么性能复盘最有用的产物不是“优化了多少”而是一条别人能按图复现的证据链。若没有固定场景、设备、画质和操作路径帧时间曲线只能说明某次录制发生过抖动不能支持修改决策。先写清采样问题开始录制前先回答要定位什么主线程持续过载、偶发卡顿、GPU 饱和还是内存持续增长。一个录制只服务一个问题。CPU 问题记录主线程调用栈和 Job 等待GPU 问题记录渲染 pass、批次和 overdraw内存问题区分临时分配、资源常驻和疑似泄漏。不要把三类图表拼在一起给出一个“性能变差”的结论。基线记录至少包含构建号、目标设备、图形 API、质量等级、场景入口和操作脚本。对操作脚本的要求很简单另一位同事能从同一入口走到同一段战斗或 UI而不是凭记忆重复点击。从尖峰回到触发条件发现单帧尖峰后先在 Timeline 中标出它对应的调用栈再回看这一帧发生了什么是否加载资源、创建大量对象、切换场景、等待 Job或启用了新的渲染 pass。若尖峰无法稳定复现保留录制引用和设备状态不急着修改代码。例如某次尖峰显示在资源反序列化不应马上优化渲染管线先确认该资源是否在不合适的时机同步加载。反过来GPU 帧时间持续上升时检查相机数量、透明物体和后处理开关而不是把主线程 GC 当作唯一原因。修改后用同一口径验证每次只改一个假设例如把对象创建移出热路径或限制某个后处理 pass。用同一设备和脚本重新录制比较帧时间分布、调用栈和分配来源同时确认画面、输入和资源释放没有回归。关闭功能来换取表面帧率不算完成必须说明用户体验发生了什么变化。复盘文档最后保留三项触发条件、采取的修改、仍未确认的假设。若修复只适用于某一设备或场景要直接写明。下一次类似问题出现时团队可以从已有证据开始而不是重新用一张截图猜测瓶颈位置。交接时附上原始采样文件、场景入口和构建号的引用。没有这些材料的结论只能作为线索不能作为下一次优化的基线。