（SUB）app性能测试

APP性能测试(启动速度、内存、CPU、FPS、GPU、耗电量)_性能测试中fps分析-CSDN博客

app性能测试_app性能测试方案-CSDN博客

测试方案

服务端

平均响应时间

错误率

吞吐量

CPU/内存占用率

网络/硬盘的读写速度

客户端

启动速度

手机APP的启动时长是一个很容易被用户感知的性能指标，启动时长过长会让用户极不愿意继续等待。因此启动时长是一项比较靠前的性能指标。APP的启时长分为两种情况，一种是冷启动时间，另一种是热启动。

冷启动：应用序首次启动，进程首次创建并加载资源的过程
热启动：指app没有被后台杀死，仍然在后台运行，通常我们再次去打开这个app，这种启动方式叫热启动

1）场景设计

冷启动

场景设计：清除后台所有应用，等待数秒，启动软件

热启动

场景设计：切换到桌面，等待数秒，重新切换回应用

测试内容
- 冷启动速度
- 热启动速度
- 完全启动速度
- 有网启动速度
- 无网启动速度
- 主要测试冷启动和热启动
测试标准
- 测试标准：冷启动时间不超过1.5s, 热启动不超过1s

2）测试方法

使用adb命令进行测试

冷启动：应用进程首次启动

adb shell am start -W 包名/界面名

热启动：切换到主页后再启动应用

adb shell input keyevent 3（按键操作，3表示home键）
adb shell am start -W 包名/界面名
3）结果分析：

通过adb命令可获取的时间如下：

ThisTime ：该界面 ( activity ) 启动耗时（毫秒）

TotalTime ：应用自身启动耗时 = ThisTime + 应用 application 等资源启动时间（毫秒）

WaitTime ：系统启动应用耗时 = TotalTime + 系统资源启动时间（毫秒）

如何确定启动时间是否符合标准？

根据用户体验

和以往版本进行对比

横向对比，和同类产品一起测试，不超过同类产品的1倍

CPU占用率

某些场景下我们去使用App，可能会碰到手机会出现发热发烫的现象。这是因为CPU使用率过高、CPU过于繁忙，会使得整个系统无法响应用户，整体性能降低，用户体验变得相当差，主要关注的是cpu的占用率

CPU Usage：传统cpu利用率，也叫未规范化cpu利用率

计算方法：当前时刻cpu频率下，CPU Usage = CPU执行时间/CPU总时间，一般adb等获取的都是未规范化的cpu利用率
CPU Usage(Normalized)：规范化cpu利用率

由于移动设备CPU频率时刻变化，用传统CPU利用率计算方法，假定在低频率时刻计算出CPU利用率=30%，和在CPU高频时刻计算出CPU利用率=30%。同样都是30%但性能消耗是完全不样的，明显高频消耗更高。传统CPU利用率已无法真实反映性能消耗。

所以我们需要一种规范化(可量化)的统计方式。将频率因素考虑进去。

CPU Usage(Normalized)= (CPU执行时间/CPU总时间) * (当前时刻所有CPU频率之和/所有CPU频率最大值之和)。

1）CPU 测试场景设计

测试点：

空闲时间(切换至后台)的消耗，基本没大应用使用cpu

在运行一些应用的情况下，cpu已占50%的情况下，观察应用程序占用cpu的情况

在高负荷的情况下看CPU的表现（cpu占用应是在80%以上）

具体场景：

应用空闲状态运行监测CPU占用率，空闲状态：应用按Home键退到后台，不再占用系统的状态（通常是灭屏半分钟后），CPU占用率=0%
应用中等规格运行监测CPU占用率，中等规格：模拟用户最常见的使用场景，CPU占用率≤30%
应用满规格长时间正常运行监测CPU占用率，CPU占用率≤30%
应用正常运行期间监测CPU占用率峰值，应用正常运行：打开应用进行基本操作，CPU占用率≤50%
2）测试方法

方法0：使用perfdog采集不同场景数据

方法1：使用adb
adb shell top -m cpu |grep packageName（查看某个软件的cpu占用率）
adb shell top -m 10 -s cpu （查看cpu占用前10的应用）
top cpu 参数：
-m 显示最大数
-s 按指定行排序
-t 显示进程名称
-n 在退出前刷新几次
-d 刷新间隔
adb shell dumpsys cpuinfo |grep 包名（一段时间的平均值）
方法2：使用第三方工具Emmagee、GT等
方法3：使用androidstudio自带的检测工具android monitor

结果分析：

和自身app的上个版本对比
和竞品对比
自身app各个界面（activity）对比

内存占用率

在Android系统中，每个APP进程除了同其他进程共享内存(shared dirty)外，还独用私有内存(private dirty)，通常我们使用PSS(私有内存+比例分配共享内存)来衡量一个APP的内存开销

app内存有以下几个：

VSS- Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）

RSS- Resident Set Size 实际使用物理内存（包含共享库占用的内存）

PSS- Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）

USS- Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS。

而perfdog的Memory也就是Android PSS Memory，也是我们通常用作代表内存的数据，是实际使用内存的物理内存大小

1）内存测试场景设计

空闲状态：切换至后台或者启动后不做任何操作，消耗内存最少

中强度状态：时间偏长的操作应用

强度状态：高强度使用应用，可以跑monkey来测试（通常用来测内存泄漏）

内存泄漏：指应用里的内存一直没有释放，内存一直增加 ,系统内存一直减少

退出某个页面后，内存是否有回落
进行某个操作后，内存是否增长过快
旧版本和新版本比较
新版本和竞品比较

2) 测试方法

方法0：使用perfdog采集不同场景数据

方法1：使用adb命令
adb shell dumpsys meminfo packageName
获取当前活动的包名和actively（adb shell dumpsys window | findstr mCurrentFocus）（mCurrentFocus—当前焦点）

dumpsys [options]
meminfo 显示内存信息
cpuinfo 显示CPU信息
account 显示accounts信息
activity 显示所有的activities的信息
window 显示键盘，窗口和它们的关系
wifi 显示wifi信息
关注参数
native heap alloc（JNI层的内存分配）
dalvik heap alloc （java层的内存分配）
pss：应用真正占据的内存大小
注意：如果前两个值一直增长，应用程序可能出现了内存泄漏
方法2：使用性能测试工具emmagee
Emmagee是网易开发的一款测安卓应用性能的测试apk
使用方法
安装到emmagee到手机上，启动
选择需要测试性能的应用启动
被测应用界面会展示内存、cpu、电流、流量等数据
stop test后，本地sd卡中会保存一份性能测试数据（（保存地址：/sdcard/Emmagee/******* .csv文件））
可以通过excel将数据转化为图表，更直观的查看各性能指标的数据
方法3：使用AndroidStudio 自带 CPU 和内存检测功能 – Android Monitor
方法4：内存检测工具 DDMS -->Heap
————————————————

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

原文链接：https://blog.csdn.net/xiadanying/article/details/91587096

3) 结果分析：

退出某个页面后，内存是否有回落

进行某个操作后，内存是否增长过快

旧版本和新版本比较

新版本和竞品比较

电量消耗

对于PC来说，移动设备的电池电量是非常有限的，保持持久的续航能力尤为重要。我们必须要慎重检查APP的电量使用，以免导致用户手机耗电发热，带来不良体验

1）耗电量测试场景设计

GPS定位，比如：导航类软件需要获取实时位置的时候
场景设计：打开xx导航软件，开启GPS定位，保持在导航页面中运行十分钟后，关闭GPS定位
原因：开启GPS定位会使用到手机的传感器，所以需要测试开启该功能后的电量消耗
屏幕亮度，比如：用户站在太阳地下看不清屏幕时会调亮手机亮度
场景设计：手机亮度设置为100%的亮度，打开xx软件运行十分钟后退出软件，关闭后台
原因：测试不同屏幕亮度时软件的耗电量
网络传输，比如：即时类聊天软件需要时刻保持网络畅通，或者是一些类似于播放视频软件需要大量使用到网络的软件
场景设计：打开xx视频软件，观看视频十分钟后退出软件，关闭后台
原因：使用网络时会调用到手机的信号接收、发送模块，这个情况下如果程序没有进行合理的调用，会导致这些模块一直在被使用，导致电量消耗大
cpu频率，需要大量运算的页面，比如：页面中有大量动图、视频需要处理，或者大量图表需要绘制
场景设计：打开xx炒股软件的股票走势页面，停留十分钟后退出软件，关闭后台；
原因：在需要动态加载图表的页面时会使用到CPU进行运算绘制，如果程序中出现冗余的循环逻辑时会使CPU进行不必要的负载，导致耗电量剧增
内存调度，比如：每次加载页面都需要加载图像的页面
场景设计：打开xx电商软件商品浏览页，向下浏览页面五分钟后退出软件，关闭后台
原因：该场景需要大量加载图像，频繁调用运行内存，如果每次都需要重新加载的话会大量消耗运行内存，导致电量消耗大，所以需要测试电量消耗
长时间连续使用 / 后台运行状态下应用无异常耗电现象
场景设计：打开xx软件，连续使用一个小时
原因：长时间连续使用过程中电量消耗应该处于一个较为平缓正常的耗电，而不应该在使用一段时间以后出现耗电量剧增的情况；同时软件在后台运行(不进行联网操作、GPS定位等功能)时，电量消耗应该极低
2）测试方法

方法0.使用 perfdog 采集手机耗电量

测的是整机，不是单个APP，测试时要尽量减少系统本身和其他app的干扰，同时无法得知app具体哪方面的耗电量高。

注意！ perfdog电量测试仅支持wifi连接状态

先关闭所有的应用，再打开被测app
方法1：使用第三方测试工具：Emmagee、GT等，只需要测试的电流静置一晚，待机
电流在正常范围内即可。一般是被测应用对比待机电流<=2mA。
方法2：使用adb命令
adb shell dumpsys batterystats |grep packageName

改变手机电池状态
手机连接电脑，默认为充电状态
切换手机电池为非充电状态adb shell dumpsys battery set status 1
获取电量消耗信息
获取整个设备的电量消耗信息： adb shell dumpsys batterystats | more
获取某个apk的电量消耗信息： adb shell dumpsys batterystats com.Package.name | more
————————————————

3）结果分析

场景	测试页面	测试时长	耗电量
使用GPS功能	导航页面	10min	xxx%
置于后台使用GPS功能	导航页面	10min	xxx%
…	…	…	…

根据测试后拿取的结果，与同类产品进行对比，或者与本产品的其他页面进行对比，分析是否有异常耗电的情况。

流量消耗

目前的网络类型包含2G\3G\4G\wifi，其中还有不同运营商的区分，我们在APP的使用中经常遇到大资源，重复请求，调用响应慢，调用失败等各种情况。在不同的网络类型之下，我们不仅要控制流量使用，还需要加快请求的响应。

1）流量测试场景设计

安装后首次启动到全部加载完成的所有耗流
非首次启动到全部加载完成的所有耗流
后台运行耗流
运行某个业务场景消耗的总流量
2）测试方法

使用 perfdog 测试工具采集流量数据

注意！ perfdog流量测试仅支持wifi连接状态

3）测试结果与分析

旧版本和新版本比较

新版本和竞品比较

场景	耗流	是否通过
打开登录页面，输入用户名与密码进行登录，点击签到并签到成功	xxx KB	是/否
打开商品搜索页，搜索xxx，直到第一页搜索的内容全部展示出来	xxx MB	是/否
…	…	…

流畅度

FPS是图像领域中的定义，是指画面每秒传输帧数，通俗来讲就是指动画或视频的画面数。FPS是测量用于保存、显示动态视频的信息数量。每秒钟帧数愈多，所显示的动作就会愈流畅。

一般来说安卓设备的屏幕刷新率为60帧/秒，要保持画面流畅不卡顿，要求每一帧的时间不超过1000/60=16.6ms，否则就会出现跳帧、画面卡顿

关注点
- 高于16ms的帧率（即卡顿率）

FPS（1s内游戏画面或者应用界面真实平均刷新次数，俗称帧率/FPS）

AVG(FPS)：平均帧率（一段时间内的平均FPS）
Var(FPS)：帧率方差（一段时间内FPS方差）
Drop(FPS)：降帧次数（平均每小时相邻的个FPS点下降大于8帧的次数）
Jank（1s内卡顿次数）

BigJank：1s内严重卡顿次数
Jank(/10分钟)：平均每十分钟卡顿次数
BigJank(/10分钟)：平均每十分钟严重卡顿次数
FTime（上下两帧画面显示时间间隔，即认定为帧耗时）

AVG(FTime)：平均帧耗时
Delta(FTime)：增量耗时（平均每小时两帧之间时间差>100ms的次数）
PerfDog-Stutter(卡顿率)

PerfDog Stutter 定义：测试过程中，卡顿时长的占比。即Stutter(卡顿率)=卡顿时长/总时长

1）场景设计

打开被测软件的每一个页面进行测试

2）测试方法

方法0：在app上进行操作，使用perfdog工具采集数据

方法1：adb命令
打开手机：开发者选项->GPU呈现模式分析->在adb shell dumpsys gfxinfo
操作要测试的app
在cmd窗口输入adb shell dumpsys gfxinfo 包名
得到一个矩阵数据，计算矩阵中帧率大于16的点所占比例，即为卡顿比
Draw: 表示在Java中创建显示列表部分中，OnDraw()方法占用的时间。
Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长。
Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。
Draw + Process + Execute = 完整显示一帧，这个时间要小于16ms才能保证每秒60帧
Janky frames：丢帧率
方法2：直接使用开发者选择自带的图标
打开手机：开发者选项->GPU呈现模式分析->在屏幕上显示为条形图
操作要测试的app
绿色的线是16ms的分隔线，可以直接看出来流畅度
方法3：使用第三方工具Emmagee、GT等
方法4：使用androidstudio自带的检测工具android monitor

3）结果分析：

游戏方面

游戏流畅度是最影响用户体验的，所以需要重点关注FPS、Jank及卡顿率。

在这里插入图片描述

app方面

1) 静态页面窗

只需关注FPS，理论FPS应该为0，否则，说明有冗余刷新，容易引起手机发热及耗电。

 2) 有滚动动画页面窗口

只需关注FPS，FPS处于合适值即可，无需高频刷新。

 3) 快速滑动页面窗口

需要关注FPS、Jank及卡顿率。一般滑动状态下，帧率越高越好，Jank越小越好。

 4) 播放视频页面窗口

需要关注FPS、Jank及卡顿率，视频卡顿直接影响用户。视频一般帧率18-24帧，Jank=0。比如微信播放视频、视频播放器等。

GPU渲染

GPU渲染是指在一个像素点上绘制多次（超过一次），过度绘制对动画性能的影响是极其严重的，如果你想要流畅的动画效果，那么一定不能忽视过度绘制。

测试指标
控制过度绘制为2x
不允许存在4x过度绘制
不允许存在面积超过屏幕1/4的3x过度绘制
测试方法
方法1：使用手机的开发者选项
打开手机：开发者选项->调试GPU过度绘制->显示过度绘制区域
打开被测的应用，进行操作
颜色深的区域为过度绘制的地方
原色：无过度绘制
蓝色：绘制一次
绿色：绘制两次
浅红：绘制三次（可以优化了）
深红：绘制四次（必须优化）
————————————————