作用与适用场景

Frame Debugger 是 Unity 的渲染逐事件回放工具，用于排查：

• 渲染顺序是否符合预期（先画谁、后画谁、哪一步清屏、哪一步写入 RT）
• 单帧内 Render Event / Draw Call / Pass 的组成与来源
• 合批是否生效（SRP Batcher / Instancing 等）以及“不生效的原因”
• 材质/关键字切换导致的 SetPass 增多、变体切换异常
• 粉色/丢 Shader、渲染结果不对、透明排序/深度问题等“正确性问题”

[!NOTE] 注意：Frame Debugger 主要用于正确性与渲染链路排查，不用于衡量性能。开启后会改变渲染节奏（逐事件回放），性能数据请以 Profiler/平台 GPU 工具为准。

使用方式

打开方式

Window -> Analysis -> Frame Debugger

使用

Debugger 未开启状态界面

截图就是FrameDebugger的操作界面，这是没开启debugger的状态 Enable 按钮： 点击打开功能

Debugger开启状态界面

图上都标识了序号，我先按照顺序解释一下界面上的序号

• 1 Enable：开启/关闭 Debugger 调试（点击复用，注意它会暂停游戏）
• 2 Target：Debugger 的设备，默认是Editor，也可以选择移动设备
  • 直接 Play Mode 运行后开启即可（Target 选 Editor）
  • 调试真机/Player 需要连接 Profiler
• 3 Frame Slider：当前渲染帧的 index，滑动 slider，可以回放 Draw Call
• 4 Previous：跳到上一个 DrawCall
• 5 Next：跳到下一个 DrawCall
• 6 Hierarchy：当前场景所有的渲染帧事件列表（按执行顺序排列）
• 7 Details：当前帧绘制的信息，包括输出的界面，当前的mesh，还有就是当前shader的信息等

模块 7 就是我们在调试的时候主要看的参数，看是否符合我们的预期。

推荐使用流程（稳定高效的排查套路）

Step 1：锁定问题帧

• 让画面停在“出问题”的时刻（比如粉色、闪烁、排序错、某个 UI 被遮挡）
• 打开 Frame Debugger，选择 Target（Editor/Player），点击 Enable

Step 2：从“最终结果”反推事件

• 在事件列表中从靠后位置开始看（通常越后越接近最终画面：UI、后处理、Overlay）
• 选中事件后看右侧预览（Game View 会同步变化），判断“哪一个事件开始把画面画坏”或者“哪一步少画了东西”

Step 3：定位到具体 Draw/Pass/材质切换

• 选中可疑 DrawMesh/DrawCall
• 在详情区（右侧面板）确认：
  • 用了哪个 Shader/Pass/关键词
  • Mesh 是否正确
  • 是否发生了不必要的材质/关键词切换（导致 SetPass 上升）
  • SRP Batcher 若未生效，直接看 Batch cause（非常重要！）

Step 4：回到工程侧验证“原因 → 修改点”

• 常见落点：
  • 材质没复用（同效果用了多个材质实例）
  • 关键字开关不一致（变体不一致导致无法合批）
  • Pass 选择不一致（同一个 Shader 走了不同 LightMode/Pass）
  • RenderQueue/Sorting/Stencil/DepthWrite 等配置不一致导致排序异常

高频问题与 Frame Debugger 怎么用（面试/实战都高价值）

1. 粉色（Shader 丢失/变体缺失/材质异常）

• 在“粉色出现的那条 Draw 事件”上看：
  • Shader 是否为预期的那个
  • Pass 是否存在
  • 关键词/变体是否匹配（有时是关键字组合导致变体缺失）
• 进一步需要更深入的 GPU 级信息时，可结合 RenderDoc 等第三方帧调试器（Unity 也支持与其联动）。

2. SetPass/DrawCall 过高，想知道“到底是谁在切”

• 找到事件序列里频繁出现的材质切换点
• 对比相邻事件：Shader/Pass/关键字/渲染状态是否一致
• 若使用 SRP Batcher：重点看 Batch cause，它往往能直接给“为什么没批”的可执行线索。

3. 合批不生效（以 SRP Batcher 为例）

• 先确认项目开启了 SRP Batcher（URP/HDRP 常见）
• 在事件详情里看 Batch cause
• 典型原因是：材质属性布局不一致、不同 Pass、不同关键字组合导致无法批。