如何理解Unity中batches、saved by batching统计及渲染卡顿排查

开发与运行场景 #

• 开发载体为安卓平台游戏，整体场景负载很低：全场景总三角形面数仅2000左右，使用的是逻辑简易的Shader，但在Unity Profiler的渲染分类栏下，仍然观测到明显的性能卡顿。
• 查看Unity统计面板的批次（Batches）指标发现，关卡加载生成完成后，统计显示总规模约250个批次，其中95%的计数属于Saved by batching（批处理节省）的优化覆盖范畴——场景内绝大多数对象都预先标记了静态属性，对应统计参考截图如下：
  

前期认知与初步排查过程 #

• 此前通过公开资料了解到Unity批处理的基础计算逻辑：未经过批处理优化的原始总批次量，等于统计面板显示的实际提交至GPU的批次数与Saved by batching对应统计数值之和。
• 按照该逻辑代入当前场景的统计值：实际提交的批次数为27，Saved by batching对应值为256，反推优化前总共有271个批次，按照公开的安卓平台性能适配经验，这个规模的批次量属于明显过高的水平。
• 排查过程中的观测现象：尝试通过逐个移除场景对象定位高批次来源时，每移除一个标记为静态的对象，Saved by batching的统计值就会同步下降。

核心待解答疑问 #

• 移除静态对象时Saved by batching数值同步降低的现象，是否代表该对象已经被正常纳入批处理优化范畴？
• 当前场景实际需要提交的有效GPU批次总量是271，还是就是统计面板直接显示的27？
• 按照「未优化总批次 - 批处理节省值 = 实际提交有效批次」的计算逻辑，代入271总批次、256的批处理节省值推算，仅会得到15个有效提交批次的结果，按照这个结果场景本该达到流畅运行表现，那当前观测到的渲染卡顿，根本成因是什么？

内容的提问来源于stack exchange，提问作者Leoverload