开场上周 Code Review 时，小李提交了一个"性能优化"PR：把场景里 200 个装饰物合并成了一个材质，信心满满地说"这样就只有 1 个 DrawCall 了"。我打开 Frame Debugger 一抓，DrawCall 数字依然在 80 左右徘徊。小李当场愣住了——这就是今天要聊的经典误区：一个材质 ≠ 一个 DrawCall，而反方向的推论"两个材质 = 两个 DrawCall"也只是理论下限，实际往往更多。很多团队把"减少材质数"当成万能优化药方，却忽视了真正决定 DrawCall 数量的整条因果链：Pass 数 → 渲染状态分组 → 合批窗口 → 每实例数据。这篇文章就沿着这条链往下挖，先建立正确的心智模型，再讲清楚"切材质为什么贵"，最后给出能落地的优化清单。一、DrawCall 与材质的真实关系1.1 正确的心智模型：DrawCall 按"渲染状态 × Pass"计数先把结论钉死：DrawCall 的数量 ≈ Σ（每个互不相同的渲染状态组 × 该状态在每个 Pass 中需要绘制的批次）。材质只是"渲染状态组"里最显眼的一个成员。除了 Shader 和贴图，阴影开关、Light Probe 用法、渲染队列、甚至 Per-Renderer 数据的差异，都会把物体踢进不同的组。所以：一个材质，N 个 DrawCall：200 个物体共享一个材质，但 Shader 有 ForwardLit + ShadowCaster + D 单材质与多材质的 DrawCall 差异及合批机制解析
开场上周 Code Review 时，小李提交了一个"性能优化"PR：把场景里 200 个装饰物合并成了一个材质，信心满满地说"这样就只有 1 个 DrawCall 了"。我打开 Frame Debugger 一抓，DrawCall 数字依然在 80 左右徘徊。小李当场愣住了——这就是今天要聊的经典误区：一个材质 ≠ 一个 DrawCall，而反方向的推论"两个材质 = 两个 DrawCall"也只是理论下限，实际往往更多。很多团队把"减少材质数"当成万能优化药方，却忽视了真正决定 DrawCall 数量的整条因果链：Pass 数 → 渲染状态分组 → 合批窗口 → 每实例数据。这篇文章就沿着这条链往下挖，先建立正确的心智模型，再讲清楚"切材质为什么贵"，最后给出能落地的优化清单。一、DrawCall 与材质的真实关系1.1 正确的心智模型：DrawCall 按"渲染状态 × Pass"计数先把结论钉死：DrawCall 的数量 ≈ Σ（每个互不相同的渲染状态组 × 该状态在每个 Pass 中需要绘制的批次）。材质只是"渲染状态组"里最显眼的一个成员。除了 Shader 和贴图，阴影开关、Light Probe 用法、渲染队列、甚至 Per-Renderer 数据的差异，都会把物体踢进不同的组。所以：一个材质，N 个 DrawCall：200 个物体共享一个材质，但 Shader 有 ForwardLit + ShadowCaster + D RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
