手游性能测试指南——All In One
1 前言
随着手游3D类型游戏增多，对机器资源占用越发高，但用户手中硬件的提升是一个不可控且缓慢的过程，为了保证在尽量广泛的机型上流畅运行，提高游戏本身的潜在用户群体，所以手游客户端性能审核工作就越发重要，如何做客户端性能审核，如何快速，专业，准确的做客户端性能审核是我们需要重点关注、且持续建设的内容。
什么是客户端性能审核？
客户端性能审核主要针对不同主流机器（一般来自适配TOP10）根据不同配置划分高、中、低机型后，通过在各机型下模拟玩家核心体验场景、进行性能参数收集、评价该游戏的性能表现，并且进一步深入分析造成低性能表现原因的审核过程（见图1-1），通常我们会通过基础性能审核和精准定位两套方案流程来保证整个审核过程，而本文的撰写目的是为了通过清晰的阐述展示性能审核的思路和常用手段。
图1-1
文章导航: 性能瓶颈分析思路 基础性能采集工具AIO介绍 常见性能瓶颈定位介绍 |
2 基础审核方案
2.1 性能基础参数
图2-1
图2-1流程是数据正确输出到前台显示的步骤，其经历CPU处理、内存管理、GPU处理，显存管理等阶段，若过程出现性能不佳，只有可能是中间的某一环节异常导致，而客户端性能审核（第一步）就需要定位具体是哪个环节异常。过程中需要统计的性能参数如图2-2
图2-2
android平台详细采集指标
基础指标： FPS帧率：应用程序每秒钟显示的帧数 CPU占用率：应用程序占用的CPU资源情况 内存：应用程序存放到系统内存中占用情况，目前主要采集PSS 显存：应用程序存放到显卡存储区域的资源数据占用情况，目前主要采集VBO GPU占用率：应用程序占用GPU资源情况 手游特有指标： 流量：单位时间内通过网络端口传输的数据总量 电量：单位时间内应用程序消耗的电荷数量 |
2.2 基础采集工具介绍
统计上述参数，市面上有很多工具，各种试用体验不爽后我们开发了AIO，优劣对比如下，
可采集指标 | bench3D | 备注 | wetest | 备注 | AIO | 备注 |
CPU | √ |
| √ |
| √ |
|
内存 | √ |
| √ |
| √ |
|
FPS | √ |
| × | 限帧游戏，采集帧率异常 | √ |
|
GPU | × | 未实现 | × | 未实现 | √ |
|
VBO | × | 未实现 | × | 未实现 | √ |
|
Draw Call | √ |
| × | 未实现 | √ |
|
Primitive | √ |
| × | 未实现 | √ |
|
TCP流量 | √ |
| √ |
| √ |
|
UDP流量 | × | 读文件方式导致无法实现获取 | × | 读文件方式导致无法实现获取 | √ |
|
电量 | √ |
| √ |
| √ |
|
Null Draw Call | √ |
| × | 未实现 | √ |
|
工具展示
工具框架
工具特色
1）真实帧率，渲染数据采集
采集原理
原理说明
FPS获取：HOOK到libEGL.so中的eglSwapBuffers函数，并获得两次调用的时间差，用1000除以时间差值，即为帧率。
Draw call获取：HOOK到opengl库中，统计glDrawElements,glDrawArrays函数执行次数，即每帧中上述函数的执行次数
Primitive获取：HOOK到opengl库中，统计glDrawElements,glDrawArrays函数中的顶点数，通过其绘制原理进行换算成图元，获取到primitive总数
VBO获取：HOOK到opengl库中，统计glBufferData、glBufferSubData函数参数的size大小，统计获取得到VBO大小
2）精准流量，支持UDP消息统计
采集原理
原理说明
pcap是基于libpcap实现的一个网络数据流量统计模块。libpcap是unix/linux平台下的网络数据包捕获函数库，大多数网络监控软件都以它为基础。Linux下著名的tcpdump就是以它为基础的，通过其可以捕获到链路层的数据帧，通过包解析去头给予应用层的流量大小统计，同时工具可支持对比链路层统计流量大小和应用层流量大小，差异太大一般是由于数据量小的包太多从而判断应用本身是否存在需要合并包。
工具兼容和性能
兼容机型支持情况
兼容机器要求：需root权限 兼容android系统：4.X系统，5.0系统暂不支持 已测兼容机型： 小米系列：MI 1S MI 2S MI3 MI4 HM NOTE 三星系列：N9008V N9006 GT-I9300 N9008 I9508 VIVO: X5L |
工具测试2小时性能情况
CPU和内存如图消耗很低，且2小时间无明显波动或持续增长趋势，工具本身性能影响低
2.3 瓶颈识别
FPS瓶颈识别
GPU相关异常信息，请关注是否绘制对象是否超量，或可尝试单帧分析定位瓶颈
CPU相关异常信息，请关注逻辑函数相关异常，可尝试函数耗时定位分析
VBO上传值超标，可优化相关使用场景，尝试定位当时场景单帧定位问题根因
内存瓶颈识别
1）场景内存PSS峰值上限评估，4核 2G机器<=300M 2 2核 1G机器<=200MB 单核 768M 机器<=150M
2）内存泄露评估，场景设计超1小时以上采集，内存无明显不释放表现趋势
流量瓶颈识别
目前识别方式10分钟消耗流量不超过500KB
显存、电量瓶颈识别
目前暂无特定阈值要求，只做统计参考
3 审核精准定位方案
虽然定位思路可通用于各应用，但由于引擎、代码逻辑上会有差异，定位细节上会存在不同，以下精准定位详解主要针对Unity3D引擎应用。
3.1 定位方法
CPU瓶颈定位
定位参数
函数级CPU占用率统计，执行耗时统计
函数级GC大小统计，执行耗时统计
采集工具
U3D profiler
常见判断准则
GC关注---任何一次性GC ALLOC大于2KB的选项 GC关注---每一帧都GC ALLOC大于20B的选项 CPU占用关注---CPU占用超过33ms以上的选项 CPU占用关注---CPU占用超过50ms以上，但占比小于10%的函数列表重点关注 CPU占用关注---CPU占用TOP选项 |
GPU瓶颈定位
定位参数
Draw call 耗时
Shader复杂度
绘制对象属性
采集工具
Adreno profiler
常见判断准则
渲染关注---Draw call 耗时TOP 渲染关注---Draw call 次数不超过250，图元不超过4W 渲染关注---shader的复杂度Instructions 条目（主流的GPU每帧处理计算条目平均50~10） 渲染关注---shader中纹理采样次数建议不超过2 渲染关注---整体场景透明物件占比不超过30% 渲染关注---深度查看over draw具体情况 |
内存瓶颈定位
定位参数
资源的重复情况
资源的大小是否超阈值
资源是否存在泄漏
采集工具
U3D profiler
常见判断准则
内存阈值关注---ManagedHeap.UsedSize建议不超过20M 内存阈值关注---总体Mone建议不超过40M 内存阈值关注---Reserved Memory建议不超过150M 内存阈值关注---2D纹理建议不超过50M 内存阈值关注---Mesh大小建议不超过20M 内存阈值关注---AnimationClip大小建议不超过15M 内存阈值关注---AudioClip大小建议不超过15M 资源属性关注---Texture2D、AnimationClip、Mesh、AudioClip是否存在重复对象 资源属性关注---Texture2D是否存过大1024的对象 资源泄漏关注---SerializedFile等函数加载后是否有释放（u3d profiler不太方便定位） |