Android APP 性能测试指标汇总

Android性能测试中主要有两种类型

rom系统性能测试

APP应用性能测试

响应时间

响应时间是衡量操作的APP达到期望效果的时间范围。如果一个软件，加载数据一直加载不出来，会对软件的日活、留存产生影响。

响应时间指标测试点共有三类：

冷启动：应用首次启动所花费的时间

热启动：应用非首次启动所花费的时间

跳转：应用界面切换所花费的时间

启动速度测试点有如下五点：

冷启动速度

热启动速度

完全启动速度

有网启动速度

无网启动速度

启动时间验收标准为 冷启动不超过1.5S，热启动不超过1S

启动时间获取方法

方法一：adb 方法

冷启动 需要提前确认程序是否在后台跑，如有则需要先kill应用程序

启动程序应用：adb shell am start -W -n package/activity

停止APP命令：adb shell am force-stop package

方法二：使用charls 抓包，查看duration

流量

如今，网络类型主要有2G、3G、4G、5G和WiFi，APP在使用不同网络时，我们要对其采取不同流量控制策略。如常用的视频APP，主要使用的网络类型为WiFi环境和蜂窝网络环境。

流量指标中涉及到的概念：

中等负荷：应用正常操作

高负荷：应用极限操作

关于流量测试点需要关注：

应用首次启动流量值

应用后台持续运行时长2H的流量值

应用高负荷运行的流量峰值

应用中等负荷运行中的流量均值

电量

Android设备中，运行大量的程序，对电量的消耗对于手机设备来说也是需要关注的。

电量指标需要关注以下场景：

设备安装APK前后，待机功耗无明显差异

待机、操作页面、启动APK等常见操作，电量消耗均值正常

长时间使用APK，无异常耗电现象

电量数据获取方法

方式一：adb 命令

adb shell dumpsys battery

status：1 代表非充电状态、2 代表充电状态

level：电量信息

获取整个设备的电量信息：adb shell dumpsys batterystats | more

获取某个APK的电量信息：adb shell dumpsys batterystats APK包名

方式二：使用第三方工具itest\GT

电量指标需要从软件和硬件两方面进行测试

硬件端：需要硬件测试工程师使用万用表、功耗仪进行测试。满足市场行业标准

软件端：

方式一：可以使用第三方工具进行测评

方式二：命令端获取电量数据

温度

Android 设备运行过程中，设备温度异常不仅对用户体验带来不好影响，同时也存在安全方面隐患。

温度指标需要关注如下几个场景：

设备满负荷情况，设备温度峰值无异常

设备APK长时间播放，设备温度均值无异常

设备常规操作如点击、启动APK等温度正常

温度指标数据与电量指标获取方式都是一样的

adb shell dumpsys battery

temperature：温度（int类型），单位：0.1度

性能测试常见问题

在性能测试过程中，经常会遇到如下问题及原因：

问题原因APP连接超时网络中断；APP 请求接口异常APP 闪退Android缓存垃圾过多；运行程序多，导致内存不足等；版本兼容问题；卡顿、黑白屏系统CPU、GPU资源不够；过度绘制崩溃APP常常表现为Crash交互性能差其他APK、弹框干扰内存泄漏APK新建的对象没有释放，导致内存一直被占用内存溢出APK申请内存不够时。

内存

在Android系统中，每个APP内存包括两部分：

与其他进程共享内存（shared drity）

APP独占的私有内存（private dirty）

在行业内，我们通常会使用PSS（USS+共享的内存）来判断APP的内存开销

查看指令为：adb shell dumpsys meminfo 应用包名或者 adb shell procrank

内存测试测试项中，需要对系统不同情况进行测试

空闲状态下，应用内存消耗

中等规格状态下（操作时间较长），应用内存消耗

满格状态下（操作时间较短），应用内存消耗

测试过程中，同时要关注内存峰值、泄漏、内存释放、压测后内存使用情况

内存场景问题

内存抖动：频繁的GC，导致UI卡顿

内存溢出：应用申请的内存不够引发的

内存泄漏：应用结束后无法释放内存空间，存在大量次数就会导致内存泄漏

频繁GC

CPU

CPU 是衡量APP应用程序占用系统资源情况。

如果APP应用程序占用过多的CPU资源，会导致整个系统的稳定性，系统操作会异常的卡顿。

因此，Android CPU指标我们需要关注两点：

CPU 总体使用率

应用程序CPU占有率

我们可以通过下列命令查看CPU资源使用情况：

adb shell dumpsys cpuinfo | grep packagename

adb shell dumpsys top -n 10 -s cpu 显示占比CPU最高的钱10个程序

(-t 显示进程名称，-s按指定行排序,-n 在退出前刷新几次，-d 刷新间隔，-m显示最大数量)

CPU Usage: 传统CPU利用率，也称为未规范化CPU利用率

计算方法：当前时刻CPU频率下，CPU Usage = CPU执行时间/CPU总时间

CPU Usage（normalized）:规范化CPU利用率

计算方法：CPU usage（normalized）= (CPU执行时间/CPU总时间)*（当下时刻所有CPU频率之后/所有CPU频率最大值之后）

我们在面对问题如：APP操作时出现发烫、卡顿、ANR现象，排查是否是CPU问题时：

如果是ANR，则在logcat文件里搜索ANR in,以及adb pull 拉取trace文件

如果没有ANR则使用上述方法获取到CPU占用率，如果某个场景CPU占用率走势异常，峰值存在异常均值大于基线，则可以使用traceview查看分析Trace文件，反馈给RD解决。

GPU

当一个APP操作过程中，出现卡顿，存在的原因可以有CPU问题，也有可能是GPU问题。

GPU指标专门衡量一个APP画面渲染的速度，当过度绘制对画面性能影响是极其严重的。

GPU指标中需要关注点：

过度绘制：界面显示的activity嵌套多层

屏幕滑动帧率

屏幕滑动平滑度

GPU数据获取步骤：

adb shell dumpsys gfxinfo 包名 > GPU.txt

pull GPU.txt 文件到本地

定位到Profile datain ms 复制到Excel中绘制表格展示

GPU测试点：

过度绘制测试：

打开开发者选项

进行操作测试APP

测试指标：

控制过度绘制为2X

不允许存在4X过度绘制

不允许在面积超过屏幕1/4的3X过度绘制

画面卡顿

FPS

FPS指标是衡量APP画面每秒传输的帧数，每秒钟帧数越多，操作APP的动作越流畅。

FPS指标是显示指标一种，显示指标主要有两大类：

系统层级的指标仅有FPS，本身的Surface的合成需要在SurfaceFlinger中进行

应用层级的指标有三类：

Aggregate frame stats，属于HWUI功能。HWUI进行Surface绘制后才能分析

Jankiness count、MAx accumulate frames、Frame rate适合范围广

SM、Skipped frames 需要Choreographer 绘制Surface 才能正常工作

FPS指标普遍要求：

在android 屏幕中刷新率为60帧/秒

每一帧时间不超过16.6ms，画面流畅不卡顿

FPS 数据获取命令：

adb shell dumpsys SurfaceFlinger --latency 当前activity

adb shell dumpsys gfxinfo 包名

通常情况下，FPS和GPU两个是结合的一起看的，两者的关系是相辅相成。