（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

原文链接：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

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

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过度绘制->显示过度绘制区域

打开被测的应用，进行操作

颜色深的区域为过度绘制的地方

原色：无过度绘制

蓝色：绘制一次

绿色：绘制两次

浅红：绘制三次（可以优化了）

深红：绘制四次（必须优化）

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

测试工具

perfdog，adb

参考资料

VSS、RSS、PSS、USS内存

VSS：Virtual Set Size ，虚拟耗用内存。它是一个进程能访问的所有内存空间地址的大小。这个大小包含了一些没有驻留在RAM中的内存，就像mallocs已经被分配，但还没有写入。VSS很少用来测量程序的实际使用内存。

RSS：Resident Set Size ，实际使用物理内存。RSS是一个进程在RAM中实际持有的内存大小。RSS可能会产生误导，因为它包含了所有该进程使用的共享库所占用的内存，一个被加载到内存中的共享库可能有很多进程会使用它。RSS不是单个进程使用内存量的精确表示。

PSS：Proportional Set Size ，实际使用的物理内存，它与RSS不同，它会按比例分配共享库所占用的内存。

例如，如果有三个进程共享一个占30页内存控件的共享库，每个进程在计算PSS的时候，只会计算10页。

PSS是一个非常有用的数值，如果系统中所有的进程的PSS相加，所得和即为系统占用内存的总和。当一个进程被杀死后，它所占用的共享库内存将会被其他仍然使用该共享库的进程所分担。在这种方式下，PSS也会带来误导，因为当一个进程被杀后，PSS并不代表系统回收的内存大小。

USS：Unique Set Size ，进程独自占用的物理内存。这部分内存完全是该进程独享的 。USS是一个非常有用的数值，因为它表明了运行一个特定进程所需的真正内存成本。当一个进程被杀死，USS就是所有系统回收的内存。USS是用来检查进程中是否有内存泄露的最好选择。