移动端 - App性能专项测试

如何让APP使用体验更好

性能测试的目的是什么？为什么要做性能测试？

性能测试的短/中/长期的目标是什么？

性能指标有哪些？具体代表什么？如果一个指标异常能说明是哪块的问题？

APP性能分析工作台 - 性能测评指标

性能测试指标的标准是什么？(行业内，公司内部)

性能测试工具调研，各个工具的优劣

APP性能测试怎么做

性能测试场景的设计

规范化执行流程

测试资源准备

测试环境准备

如何在团队内推行？具体步骤是什么？如何去监督？

如何让APP使用体验更好

用户体验、流畅度、功耗、启动时长等指标是移动端产品最关注的层面，最直观的表现是用户在前台使用 App 时的主观体验。

客户端性能测试需要从业务和用户的角度出发，设计合理且有效的性能测试场景，制定各性能场景下的客户端性能指标(内存、CPU、卡顿数、帧率、电量、加载时长等)，并制定规范化的执行流程，按照执行标准执行性能场景同时使用性能测试具收集性能数据，并对数据进行分析，如果有性能问题并对问题进行定位，配合开发进行修复验证发布，最后输出完整的性能报告。

性能测试的目的是什么？为什么要做性能测试？

• 根本目的：为用户做产品，让用户有更好的使用体验；避免我们做出了一些优质玩法或内容，但却由于性能而造成了用户的大量流失
• 把部分隐性问题暴露到功能上线前，规避线上对性能的损失，提高我们产品的线上质量
• 确定产品核心功能所接受的最低硬件标准，针对不同档位机型，在产品上做对应的功能调整或适配

性能测试的短/中/长期的目标是什么？

• 短期目标：
  • 保证功能上线前无严重性能问题
  • 确定性能指标，制定APP性能测试评分初版标准建立团队内对性能测试的基本概念
  • 获取当前各个业务线APP的基础性能数据
• 中期目标：
  • 建立性能巡检规范以及落地方案
  • 归档性能数据，定期进行数据对比，识别是否有性能问题在新版本产生
• 长期目标：
  • 建立性能评分标准
  • 建设性能监控大盘以及预警

性能指标有哪些？具体代表什么？如果一个指标异常能说明是哪块的问题？

• 性能指标的定义
  • 常见的移动端性能指标有：内存、cpu、帧率(FPS)、卡顿数、wakp up数、展示时长等，关注什么性能指标是依托于我们的性能测试场景
  • 比如：以Monkey为例，当我们冷启APP进入首页tab的时候，更关注数据展示时长，滑动场景更关注卡顿数，为不同场景设计合理的性能指标也是我们需要认真考虑的
• 需要关注的指标
  • 通常我们需要关注的有三大指标：CPU、内存、FPS，三者本质上是相辅相成的，一个指标有问题，大概率其他指标也会有异常
• 性能指标参考文档：
  • Perfdog
    • https://perfdog.qq.com/article_detail?id=10089&issue_id=0&plat_id=1
    • Perfdog官方文档给到的性能指标及其详细，在出现问题时可以针对性的获取更详细的数据去做排查
  • AnyTrace
    • https://www.volcengine.com/docs/6431/82892
    • App性能分析工作台同样给到了性能分析方法和指标，可以用作性能数据的参考

APP性能分析工作台 - 性能测评指标

Android
大指标	细分指标	说明	备注
CPU	Sys	整机CPU使用率，用于衡量设备的负载情况。数值越大，表明当前手机任务越繁忙
	App	用于衡量App对CPU的使用情况
	SysNormalized	系统规范化使用率
	AppNormalized	APP规范化使用率
内存	PSS	Proportional Set Size 实际使用的物理内存（按比例分配共享库占用的内存） 即进程实际占有内存（不含分配但未使用的内存）+ 按比例分配的共享库内存
	VmSize	虚拟内存大小 32位CPU架构可使用的地址空间大小为 2 ^ 32 = 4GB，其中高位部分为内核空间。一个32位的应用，它基于32位的 zygote fork得来，Linux进程在fork时会继承父进程所有虚拟地址空间，因此在一个应用出生时，它的虚拟内存空间基本就在 1.8G以上 32位应用+ 32位设备：内核空间占用1G地址空间，应用可用虚拟地址上限为3G - 1.8G = 1.2G 32位应用+ 64位设备：内核运行在64位，应用可用虚拟地址上限为4G - 1.8G = 2.2G 64位CPU + 64位应用基本可以认为虚拟空间是足够的。但我们仍然要关注不合理占用	无需关注
	当App发生非Java OOM的时候，大部分是因为虚拟内存不足，所以，我们推荐重点关注VmSize的增长情况
	Java	从 Java 或 Kotlin 代码分配的对象的内存。由于 Java 堆之外的内存分配与Java分配绑定。应用程序将调用Android框架，Android框架调用Native库，并且内存分配。它们的生命周期将与Java对象相关联。优化Java Heap上的对象，也有助于 其它类型内存的回收	Android中容易出问题的两项
	Native	Natie Heap （从 C 或 C++ 代码分配的对象内存。即使应用中不使用C++，也可能会看到此处使用的一些原生内存，因为Android框架使用原生内存代表处理各种任务，如处理图像资源和其他图形时
	Stack	测评结果里很多时候显示为0，是因为小于1M
	Graphic	指图形缓冲区队列向屏幕显示像素（包括 GL表面、GL纹理等等）所使用的内存
	Code	dex jar so ttf 等文件占用的内存
	System	系统代码占用的内存
FPS	FPS	数据获取时间周期内，实际渲染帧数/数据驶取间隔时间
	Jank	单帧绘制耗时> MOVIE_FRAME_TIME时，计一次jank MOVIE_FRAME_TIME 即一帧电影的耗时，一般电影是24帧每秒 MOVIE_FRAME_TIME = 1000 / 24
	BigJank	单帧绘制耗时> 3 * MOVIE_FRAME_TIME 时，计一次big jank
	Stutter	卡顿比。当发生jank的帧的累计时长与区间时长的比值

iOS
大指标	细分指标	说明	备注
CPU	TotalCPU	表示整机CPU使用率
	ProcessCPU	表示进程CPU使用率
FPS	fps_Avg	平均帔率（一段时间内平均FPS）
	Jank	当前帧耗时> 两帧电影帧耗时（ 1000ms /24 *2 =84ms）
	Big Jank	当前帧耗时> 三帧电影帧耗时（ 1000ms /24 *3 =125ms）
	jankTime	卡顿总时长
	Stutter	指定时间内卡顿的时长占比，Stutter（卡顿率）= 卡顿时长/总时长, Jank为卡顿次数，Stutter为卡顿率，Jank和Stutter趋势有一致性，但并非完全线性，因为每次Jank卡顿严重性是不一样的。同时也说明了，没有 Jank卡顿出现，卡顿率自然也就是0了
Mem ory	Footprint	应用实际使用的物理内存（包含压缩内存的实际大小），OOM与Footprint有关，常看的Memory指标（与PerfDog中Memory对应）htt p://www.samirchen.com/ios-app-memory-usage/
	VM	64位CPU的最大寻址空间为2的64次方bytes，计算后其可寻址空间达到了惊人的16TB （ treabytes），即16384GB
	RealMemory	实际物理内存占用，既Instruments中Resident Memory Size。注：物理内存系统策格有关，衡量内存指标时不会关注，但是它有助于分析定位整体性能问题。比如：footprint没有降低，说明应用没有释放内存，但是real memory却降低了，说明系统对内存做了压缩。由于压缩会占用CPU资源，同时相应会导致FPS降低
GPU	Device	设备利用率（整体GPU利用率）
	Render	渲染器利用率（像素着色处理阶段，若占比高，说明是PS阶段出现瓶颈，shader过于复杂或纹理大小、采样复杂等）
	Tiler	Tiler利用率（顶点着色处理阶段，若占比高，说明是VS阶段出现瓶颈，顶点数太多等原因）

性能测试指标的标准是什么？(行业内，公司内部)

行业内

腾讯游戏发行标准 / 2020年11月 / 以下数据指标来源于Perfdog
OS	档位	基线	内存消耗	帧率	流畅度	CPU占用率【(90%)为采集样本的90%】
iOS	一档机型	iPhone X/iPhone8	PeakFootprint<=1100MB	>=25FPS	卡顿率＜=2%	综合CPU平均占用(90%)小于80%单核CPU曜值占用(90%)小于90%
	二档机型	iPhone 7 / iPhone7 Plus	PeakFootprint<=900MB	>=25FPS	卡顿率＜=2%
	三档机型	iPhone 6S/ iPhone6S Plus	PeakFootprint<=800MB	>=18FPS	卡顿率＜=10%
Android	一档机型	OPPO Reno / 荣耀9X	最高PSS <= 1400MB	>=25FPS	卡顿率＜=2%	综合CPU平均占用(90%)小于60%单核CPU曜值占用(90%)小于90%
	二档机型	华为P20/VIVO X20	最高PSS <= 1200MB	>=25FPS	卡顿率＜=2%
	三档机型	OPPO A5 /荣耀畅玩7X	最高PSS <= 1000MB	>=18FPS	卡顿率＜=10%

公司内部产品

标准待定
OS	档位	基线	内存消耗	帧率	流畅度	CPU占用率【(90%)为采集样本的90%】
iOS	一档机型
	二档机型
	三档机型
Android	一档机型
	二档机型
	三档机型

性能测试工具调研，各个工具的优劣

目前市场上个各家的App性能测试工具繁多，但基本都是只适用于企业自己内部的业务场景，全平台支持的App性能测试工具非常少，目前市场上仅有腾讯和字节两家平台

性能工具	优点	缺点	备注
Perfdog	老牌客户端性能工具，功能完善，是移动全平台iOS\Android性能测试工具 APP无需做任何更改，不需要接入SDK，即插即用 支持全平台几乎所有应用 可自动生成性能测试报告，可进行性能数据对比 可在PC端多开，支持同时测多台手机 有详细的引导文档，基本可解决所有问题	当前无免费版，费用较高 腾讯王者荣耀团队自研测试平台，可能更适合游戏类产品
AnyTrace	界面简洁，操作简单，免费使用 性能数据分析指标更加细化 可设置Activity黑白名单，支持场景细粒度控制 字节火山视频团队自研测试平台，可能对视频直播聊天场景支持更好	无法上传报告到云端 工具推出时间较短，很多信息待考量 目前免费，但后续可能收费

APP性能测试怎么做

性能测试场景的设计

• 场景可能是一个操作的不断重复，也可能是几个操作的组合再重复，对于性能测试的场景来说，他一定有重复的操作或者持续的操作，目的是通过重复或者持续的操作，把性能问题放大到一定程度，能够让我们发现问题
• 比如：以Monkey中who likes you页面为例，想测试页面列表滑动情况下的性能表现，那性能场景可以设计成，页面向上滑动50次，每次滑动间隔1.5s。或是Monkey中的划卡，左右滑动100次，每次间隔2s

规范化执行流程

• 场景和指标都定义好了以后，就要开始执行了，这里要求要规范化执行，规范化执行不是简单的按照场景的定义去执行就好，而是要有很多关注的点
• 例如：

1. 场景开始执行前需要等待多少s
2. 执行后需要等待多少s
3. 每次测试需不需要冷启或是必须重新安装
4. 安装好需要等待多久才可以开始测试
5. 测试账号、测试数据、设备、网络需不需要固定

• 每一个点都可能影响的性能数据的准确性，必须要定义规范，每次都要按着规范去执行，而且这个规范是动态，随着我们不断的测试，会发现很多影响性能数据的问题，都必须定制规范，加以规避。同时好的规范能够未我们后面进行性能数据分析打下基础

测试资源准备

• 测试前需要准备4台Android设备，两台高配机型，一台中配机型，一台低配机型；这4台设备在未来的性能测试中作为常用测试设备；可以选择自己产品的线上用户月度常用设备前10的机型

Android平台	RAM内存	手机型号	备注
高配手机	4G/6G	华为Mate20/VIVO X21	2019年TOP300中4G机型占比42.3%，6G机型占比27.67%
中配手机	3G/4G	华为Mate9
低配手机	2G/3G	VIVO Y66

测试环境准备

• 专项测试建议放在集成测试阶段进行，测试前需尽量确保需求都已上车，取release包在正式环境下进行测试

如何在团队内推行？具体步骤是什么？如何去监督？

• 核心：按照性能测试的短/中/长期目标
• 为减少测试数据的误差，采用UI自动化脚本录制性能场景，考虑业务场景更新变动频繁，Airtest工具可能更适用，其调试修改成本较低，脚本录制更简单便捷