DrawCall达到900，渲染耗时为何不高

作者：admin
/
时间：一小时前
/
浏览：9 次
/
分类：厚积薄发

1）DrawCall达到900，渲染耗时为何不高
2）动态目标技能还适合Timeline吗

这是第495篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。

UWA社区主页：community.uwa4d.com
UWA QQ群：793972859

本次推送的实战案例来自于使用UWA服务的项目的真实且典型的问题。UWA将关键线索、定位路径与处理建议整理成了可复用的案例笔记，便于大家快速对照、排查自身项目中的同类问题。

实战案例

Q：URP项目的内城场景中，DrawCall能达到700～900，但Batches只有240～260，渲染模块耗时也没有明显升高。这种情况下还需要继续压低DrawCall吗？

A：当前不需要将降低DrawCall作为首要优化项。开启SRP Batcher后，Unity可以降低为使用相同Shader变体的材质准备和提交DrawCall时的CPU开销。它不一定会直接减少DrawCall，因此可能出现DrawCall较高，但CPU侧渲染耗时仍然较低的情况。

GOT Online报告显示当前场景的DrawCall为700～900，Batches为240～260，渲染模块耗时也没有明显升高，说明这些绘制调用暂未形成明显的CPU侧渲染压力。此时单独压低DrawCall，未必能带来可观的帧率收益。

不过，渲染模块耗时主要反映CPU侧的渲染开销，不能据此排除GPU侧压力。后续可以保留相同设备、镜头和场景作为基线，重点观察以下变化：

Batches和渲染模块耗时同步升高
说明CPU侧的批次准备和提交压力正在增加。可以使用Frame Debugger检查SRP Batcher状态及新Batch产生的原因，重点关注Shader变体或关键字切换、Pass差异，以及材质所用Shader是否兼容SRP Batcher。

GPU Clocks明显升高或持续处于较高区间
说明压力更可能出现在GPU侧，需要进一步排查Overdraw、Shader复杂度、顶点数量以及透明物体、粒子或后处理效果的屏幕覆盖范围。

仅DrawCall上升，其余指标基本稳定
暂时不需要针对DrawCall单独优化，可以继续观察场景内容增加后，Batches、渲染模块耗时和GPU Clocks是否同步变化。

因此，当前没有必要只为了降低DrawCall数值进行优化。后续如果DrawCall和Batches持续增加，并伴随渲染模块耗时明显升高，再通过Frame Debugger定位合批中断和CPU侧提交开销的来源；如果相关耗时仍然稳定，则继续观察即可。

实战案例

Q：项目使用Timeline编辑角色技能的特效、音效和播放顺序，但技能还要根据敌人位置动态计算特效的起点和终点。大量单位同时攻击时，单帧出现了28次Timeline相关调用。这类战斗技能还适合继续使用Timeline吗？

A：Timeline可以继续使用，但建议只负责技能表现编排，动态目标和战斗逻辑仍由技能系统处理。

Timeline适合组织播放顺序相对固定的动画、特效和音效。目标选择、起点、终点、飞行轨迹及命中判断会随战斗状态实时变化，如果全部交由Timeline控制，就需要在运行过程中持续传递和绑定战斗数据，增加表现层与战斗逻辑之间的耦合。

单帧出现28次Timeline相关调用，说明大量单位同时释放技能时，这部分工作会集中发生。但调用次数本身不能证明Timeline已经成为性能瓶颈，还需要结合堆栈确认这些调用主要发生在Playable或PlayableGraph创建、数据绑定（Binding），还是Graph评估（Evaluate）阶段，并观察对应的单次耗时和总耗时。

建议按照以下方式拆分职责：

技能系统
负责释放时机、目标选择、起止位置、飞行轨迹和命中判断。

表现模块
根据技能系统提供的数据，按时间播放特效、动画和音效。

Timeline
保留在剧情、Boss出场、角色Cut-in等播放内容固定、触发频率较低的完整演出中。

现有项目不需要一次性重构。可以先选择普通攻击或触发频率较高的小技能进行调整，在相同设备、单位数量和战斗流程下，对比调整前后的Timeline相关调用次数、逻辑代码耗时和帧率。

如果调用次数和CPU耗时同步下降，说明拆分有效，可以继续扩大调整范围；如果调用次数下降，但整体CPU耗时和帧率变化不明显，说明Timeline并不是当前主要瓶颈，需要继续根据堆栈排查其他CPU热点。