如何让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性能分析工作台同样给到了性能分析方法和指标，可以用作性能数据的参考
- Perfdog
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 |
|
|
|
|
AnyTrace |
|
|
APP性能测试怎么做
性能测试场景的设计
- 场景可能是一个操作的不断重复，也可能是几个操作的组合再重复，对于性能测试的场景来说，他一定有重复的操作或者持续的操作，目的是通过重复或者持续的操作，把性能问题放大到一定程度，能够让我们发现问题
- 比如：以Monkey中who likes you页面为例，想测试页面列表滑动情况下的性能表现，那性能场景可以设计成，页面向上滑动50次，每次滑动间隔1.5s。或是Monkey中的划卡，左右滑动100次，每次间隔2s
规范化执行流程
- 场景和指标都定义好了以后，就要开始执行了，这里要求要规范化执行，规范化执行不是简单的按照场景的定义去执行就好，而是要有很多关注的点
- 例如：
- 场景开始执行前需要等待多少s
- 执行后需要等待多少s
- 每次测试需不需要冷启或是必须重新安装
- 安装好需要等待多久才可以开始测试
- 测试账号、测试数据、设备、网络需不需要固定
- 每一个点都可能影响的性能数据的准确性，必须要定义规范，每次都要按着规范去执行，而且这个规范是动态，随着我们不断的测试，会发现很多影响性能数据的问题，都必须定制规范，加以规避。同时好的规范能够未我们后面进行性能数据分析打下基础
测试资源准备
- 测试前需要准备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工具可能更适用，其调试修改成本较低，脚本录制更简单便捷