原文由资深游戏测试开发工程师 陈子昂，发表于TesterHome社区，点击原文链接可与作者交流。

一般 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，等于是通过多组自动化行为去达到扫描和分工合作（一个人使用，一个人去编辑器版本那边拿补充信息）。

尾声

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