游戏测试 游戏测试 - 客户端性能 - drawcall 工具链

陈子昂 · 2021年10月09日 · 最后由 asd751985 回复于 2021年10月14日 · 1128 次阅读
本帖已被设为精华帖!

drawcall 工具链

一般 drawCall 可以理解成是调用次数,到底是调用了什么,一般性能测试里面会关注哪些。
提交给程序,Good 程序会说:这个地方可能是真有问题,我有空时看看。
Bad 结果 程序:这真没法修,一定让我对着这个修,我就原地下线了。
那么应该怎么做,本文会去掉公式和一些学术词汇。

简述下基本概念

移动端目前主流还是 OpenGL,drawCall 是 OpenGL 的绘制次数,也是优化参考指标,可以占到 4 分之一。
每次 Cpu 演算好,预设好顶点数据,在绘图前,会把顶点数据,位置,法线,颜色,纹理坐标,切线通知 Gpu 进行渲染绘制
drawcall 数量越多就分别进行对不同的顶点数据进行上面一样的渲染绘制的次数越多,次数等于 drawcall 数量。
drawcall 数越多,Cpu 不会处理不过来(有些文章会说堵在 Cpu,于是 Cpu 笑了),这样 Gpu 渲染承担的就更多。
drawcall 会对物件进行分类,不同分类相似度高的,drawcall 会缓存一部分,因为可以批量处理。

切入点

我们说下 drawcall 过高,可以找到一处切入点的
1.设置场景内粒子,但是只有发射,没有销毁。

游戏测试会怎么做,首先编写好用例,tag=客户端性能测试
关键性:执行反复操作一个特定事务,操作行为一般为 准备就绪-A-B-A-B,不会掺杂到其他的操作。
事务特定性注意是不能用打开关闭背包这种,需要对场景进行实际操作的,如果 2D 游戏,去通过打开关闭把背景界面降低到下一层做遮挡也是可以的。

3D 游戏事务实例

准备就绪-移动到水波淋漓的湖边(A可见水波淋漓的湖边),B-丢出了一个特效技能比如6级不规则体冰球,A-可见水波淋漓的湖边,B-丢出了一个特效技能6级不规则体冰球。

操作方式:绑定自动化测试框架优于人工测试,原因是机器每次的执行步骤是严格一致的,而人不一定会严格按照操作步骤。
启动一个新的进程对自动化测试框架做监听服务,由这个进行收集 drawcall,最好的方式是由该进程是一个接收数据的进程,程序 rpc 用字节流形式进入接收数据的管道。

准备就绪环境 - 最好是有一个 mock 服务,因为 gm 指令可以移动到指定位置,但是造号正常情况下需要先过引导,达成技能冰球条件,比如满足某个等级冰球。
在跑自动化的时候,可以通过 mock 服务 (聚合多个接口,支持组合条件生成的创号规则) 返回造号成功后,自动衔接自动化进行采集。
程序或者调用引擎收集方式都应该可以获得以下数据。

{"type":"湖面","triangles":200,"Instance":2,"total_triangle":400}  
{"type":"冰球","triangles":1200,"Instance":2,"total_triangle":2400}  

1 个湖面会有好多个湖面,1 个冰球也会不止 1 个 type=冰球的,所以上面数据是一个对象,应该是一个对象数组的形式,数组的个数也就是 drawCall 次数。

数据敏感度
1.多次操作可以关注 Instance 实例数。
2.类型是否合理,如果视野内湖面很大,但是冰球数很多,也是需要记录的
以上自动化脚本是可以预设的,数据敏感度的断言也是一样的。

自动化采集的话,会在同一个位置做二次复查,才会定位 Bug,这个作用是查看复现步骤。

Bug 产出:数据敏感度部分 +drawcall 持续增长 就是该工具 Bug 产出。

那个场景有一些动图(2D 看场景背景图比如一些特效,3D 要看当前摄像机镜头,测试时请先固定摄像机镜头),并且渲染范围比较大,则对性能影响更大。

所需基建能力
1.录屏方案:安卓录制屏幕的,因为 adb 会占用 adb forward,并且只能 3 分钟一个视频,如果其他录制方案的,记得端口号和 adb 用同一个。
2.多媒体处理能力:ffmpeg 去开发根据视频长度去抽帧,作用很大,最大作用不是按一帧一张事后拆不用堵塞 IO。
3.logcat 日志,不同版本的内容数量有差别。

产出打法
1.开始记录监听的地方,开始录制屏幕 (需要提高分辨率的),完成后,最后在使用多媒体处理能力基建,drawcall 高的地方提供一组照片。
logcat 日志加上面的,可以做操作复现。
程序会获得对应 Bug 单子:里面附加可见测试用例,drawcall 高的地方有一组图片和 logcat 日志。

2.根据上面的html{"type":"湖面","triangles":200,"Instance":2,"total_triangle":400}[]数组 和另外一个数组,统计出一个完整的数据
测试用例总会有个名字的

sessionId = 用例名操作1次(事务的一半)
sessionId:{
        "type":"湖面",
      “image":"素材的位置","drawCall_nums":50,"Instance_nums":10,
}

drawCall_nums=上面同一个类型数组总数,Instance_nums 是实例总和
drawCall_nums 和 type 不合理的数据是通过公式计算出来的。

多个 sessionId 就能根据一次的结果去分析到 drawCall_nums 和 Instance_nums 的上升和下降。所以这里看到需要预约一个标准,也可以找程序要一个标杆场景,如果比这个还要高的肯定是要修复的。

3.历史数据,每个阶段跑一下,看趋势。

4.补充信息:根据到这个排查出的结果,去游戏内复现后找到具体函数执行的,看 Profiles,等于是通过多组自动化行为去达到扫描和分工合作(一个人使用,一个人去编辑器版本那边拿补充信息)。

尾声

事务该如何找和有啥其他技巧,请等待下个文章: 客户端性能热力图

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 9 条回复 时间 点赞

大佬,关于 drawcall 的统计,你是怎么处理场景是否静态合批 (Static Batching) 对于 drawcall 的影响的呢

我有个想法,写一个插件统计 drawcall 然后绘制成曲线,把这个加入到性能测试报告里面去,但是不太确定这个曲线对于性能分析的意义有多大

大猫,有兴趣来分享下呀

49875183 将本帖设为了精华贴 10月09日 12:04
水山 回复

静态合批不一定是好事情,因为一些材质相近的单位就算没有光照影响也是不能进行静态合批的,比如会导致内存泄漏。合批前后是可以用自动化采集对照的,包含用不同的路径跑过去,这个就是热点图部分的。
这个工具 不是平台服务,插件统计 drawcall 然后绘制成曲线也提到了,是有必要的(可以来回拉锯跑 2 次 用代码获取结果写一个判断方式进行自动确认下),因为我们在跑采集时用时间,那么可以把图片和引擎日志给关联起来,这样不是单纯的曲线。
关联方式就是点击 drawcall 一直增加和其他上文数据的地方,这种情况下会展开看到更细的数据,文章中提到的。有具体产出的方式。

大佬们这些知识是怎么 get 到的,直接撸了 unity 的引擎层代码吗?

陈子昂 游戏测试 - 客户端性能 - 寻路采集热点图 中提及了此贴 10月12日 08:24
gf 回复

不至于,找个 Unity 教程学一下呗,或者直接看官方文档

感觉大佬都好高级啊,能介绍下工作都在干嘛,我现在虽然也在干游戏测试,但根本没有涉及到这方面的测试,都是普通用性能狗记录帧率,然后用 unity 进行一下游戏测试,感觉大家干着同一个工作,内容听起来差别好大啊。

asd751985 回复

开发方面,Q3 季度再帮同事一起开发一些平台,fixed 问题,开发自动化稳定性测试功能和一些数据整理修复数据的工作,做了一些工具类,给 gin 增加了一些特性等等。

陈子昂 回复

果然是大佬😂 ,我们就是普通的测功能,像玩游戏一样

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册