性能 Profiling 开发短记：一次故障复盘留下什么

性能 Profiling 开发短记：一次故障复盘留下什么

性能复盘最有用的产物不是“优化了多少”，而是一条别人能按图复现的证据链。若没有固定场景、设备、画质和操作路径，帧时间曲线只能说明某次录制发生过抖动，不能支持修改决策。

先写清采样问题

开始录制前，先回答要定位什么：主线程持续过载、偶发卡顿、GPU 饱和，还是内存持续增长。一个录制只服务一个问题。CPU 问题记录主线程调用栈和 Job 等待；GPU 问题记录渲染 pass、批次和 overdraw；内存问题区分临时分配、资源常驻和疑似泄漏。不要把三类图表拼在一起给出一个“性能变差”的结论。

基线记录至少包含构建号、目标设备、图形 API、质量等级、场景入口和操作脚本。对操作脚本的要求很简单：另一位同事能从同一入口走到同一段战斗或 UI，而不是凭记忆重复点击。

从尖峰回到触发条件

发现单帧尖峰后，先在 Timeline 中标出它对应的调用栈，再回看这一帧发生了什么：是否加载资源、创建大量对象、切换场景、等待 Job，或启用了新的渲染 pass。若尖峰无法稳定复现，保留录制引用和设备状态，不急着修改代码。

例如，某次尖峰显示在资源反序列化，不应马上优化渲染管线；先确认该资源是否在不合适的时机同步加载。反过来，GPU 帧时间持续上升时，检查相机数量、透明物体和后处理开关，而不是把主线程 GC 当作唯一原因。

修改后用同一口径验证

每次只改一个假设，例如把对象创建移出热路径，或限制某个后处理 pass。用同一设备和脚本重新录制，比较帧时间分布、调用栈和分配来源；同时确认画面、输入和资源释放没有回归。关闭功能来换取表面帧率不算完成，必须说明用户体验发生了什么变化。

复盘文档最后保留三项：触发条件、采取的修改、仍未确认的假设。若修复只适用于某一设备或场景，要直接写明。下一次类似问题出现时，团队可以从已有证据开始，而不是重新用一张截图猜测瓶颈位置。

交接时附上原始采样文件、场景入口和构建号的引用。没有这些材料的结论只能作为线索，不能作为下一次优化的基线。