【Android移动端】app应用性能测试以及相关使用方法介绍

最新推荐文章于 2024-02-19 15:07:43 发布

肥肥的黑巧

最新推荐文章于 2024-02-19 15:07:43 发布

阅读量1k

点赞数 1

分类专栏：性能测试崩溃定位文章标签： android

本文链接：https://blog.csdn.net/nightglow/article/details/122407001

版权

崩溃定位同时被 2 个专栏收录

2 篇文章 0 订阅

订阅专栏

性能测试

1 篇文章 0 订阅

订阅专栏

注：性能测试无论对于哪种app产品，主要分为内存，CPU，耗电三大模块去考虑；

1.在执行性能测试前，需要考虑代码中提交的内容，对于保活或者商业化相关功能的接入首先要考虑的就是常驻内存，冷启动时间；
2.低端机可能更容易引起OOM，或是手机空间不足释放不了插件的情况，导致了手机系统本身会出现anr问题，直接影响的就是用户体验，已经产品日活，用户量情况；
3.此外对于安装包的增加，也要考虑，验证是否有新的底层模块接入，包体变大的情况也有多种；

验证点及介绍使用：
**

内存

**原理说明**

对于一个app，我们可以关注它在3种状态下的内存占用情况：

空负荷————app已经在后台运行，但是用户没有使用；

中负荷————app在前台运行，用户进行了少量操作；

满负荷————用户持续频繁大量操作，app接近饱和状态运行。

然而，除了第一种情况，其它两种的主观性很强，不是很容易区分。正常产品测试的时候，只要验证后台运行（5~10分钟为宜）和用户持续频繁大量操作（10~15分钟为宜）这两种情况下就可以了。

内存分为PSS、RSS、VSS、USS

VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）是单个进程全部可访问的地址空间

（VSS：VSS表示一个进程可访问的全部内存地址空间的大小。这个大小包括了进程已经申请但尚未使用的内存空间。在实际中很少用这种方式来表示进程占用内存的情况，用它来表示单个进程的内存使用情况是不准确的。）

RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）是单个进程实际占用的内存大小，对于单个共享库， 尽管无论多少个进程使用，实际该共享库只会被装入内存一次。

（RSS：表示一个进程在RAM中实际使用的空间地址大小，包括了全部共享库占用的内存，这种表示进程占用内存的情况也是不准确的。）

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

（PSS：表示一个进程在RAM中实际使用的空间地址大小，它按比例包含了共享库占用的内存。假如有3个进程使用同一个共享库，那么每个进程的PSS就包括了1/3大小的共享库内存。这种方式表示进程的内存使用情况较准确，但当只有一个进程使用共享库时，其情况和RSS一模一样。）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）USS 是一个非常非常有用的数字， 因为它揭示了运行一个特定进程的真实的内存增量大小。如果进程被终止， USS 就是实际被返还给系统的内存大小。

（USS：表示一个进程本身占用的内存空间大小，不包含其它任何成分，这是表示进程内存大小的最好方式！）
可以看到:VSS>=RSS>=PSS>=USS
USS 是针对某个进程开始有可疑内存泄露的情况，进行检测的最佳数字。怀疑某个程序有内存泄露可以查看这个值是否一直有增加

我们一般观察Uss来反映一个进程的内存使用情况，Uss 的大小代表了只属于本进程正在使用的内存大小,这些内存在此进程被杀掉之后，会被完整的回收掉。

     USS是一个非常有用的数字，因为它揭示了运行一个特定进程的真实的内存增量大小，如果进程被终止，USS就是实际被返还给系统的内存大小。USS 是针对某个进程开始有可疑内存泄露的情况，进行检测的最佳数字。

3.测试方法
测试app内存占用的方法：
adb shell dumpsys meminfo <包名>or pid

代码方面：本人用的是uiautomator1,0开发的脚本，由于低端机权限问题，更多采用1.0版本； 相关自动化代码，下期集中分享，也可私信我~

CPU

主要关注的是cpu的占用率

测试点

在空闲时间（切换至后台）的消耗，基本没大应用使用cpu 在运行一些应用的情况下，cpu已占50%的情况下，观察应用程序占用cpu的情况
在高负荷的情况下看cpu的表现（cpu应该是在80%以上）

关注点

和自身app的上个版本对比
和竞品对比
自身app各个activity对比

测试方法

方法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

FPS（应用的使用流畅度）

 - fps是指画面每秒传输的帧数，每秒钟帧数越多，所显示的动作就会越流畅，一般来说安卓设备的屏幕刷新率为60帧/秒，
 - 要保持画面流畅不卡顿，要求每一帧的时间不超过1000/60=16.6ms，否则就会出现跳帧、画面卡顿

注：根据手机机型不同，帧率>40即不出现界面卡顿，可以通过~

关注点
高于16ms的帧率（即卡顿率）
测试方法

方法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

GPU渲染

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

测试指标
控制过度绘制为2x
不允许存在4x过度绘制
不允许存在面积超过屏幕1/4的3x过度绘制
测试方法

方法1：使用手机的开发者选项
打开手机：开发者选项->调试GPU过度绘制->显示过度绘制区域
打开被测的应用，进行操作
颜色深的区域为过度绘制的地方
原色：无过度绘制
蓝色：绘制一次
绿色：绘制两次
浅红：绘制三次（可以优化了）
深红：绘制四次（必须优化）

**attention：过度绘制大面积标红也间接的体现了其他一些列问题，也可通过强压快速进入退出app，
或功能入口快速进入退出去监控内存，存活线程去判断**

耗电量

 测试应用对电量的消耗前需要对手机本身的电量消耗有个大概了解，然后再启动待测试app看看消耗的电量增加了多少，取差值

测试点

a.测试手机安装目标apk前后待机功率有无明显差异
b.常见使用场景中能够正常进入待机，待机电流在正常范围内
c.长时间连续使用无异常耗电现象

测试方法

先关闭所有的应用，再打开被测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

安装包大小\方法数对比

测试方法

根据代码提交情况去判断，更新插件（商业化及相关插件），apk大小对比；
安装包apk方法数对比；

获取方法数命令：

@echo off
set filename=%~nx1

if defined filename goto work
echo Please input filename
pause
exit

:work

dexdump -f %1 | findstr method_ids_size

pause

问题影响：

CPU对比上个版本增加，会导致app出现anr现象；
内存过高会出现应用在启动或使用某个功能时间出现卡顿卡死，以及应用自杀现象；
启动时间增加会出现启动加载超时，也会导致大量用户卸载应用现象；
安装包对比上个版本增加会导致安装速度过慢，流量下载增加；

下章分享:

下章介绍本人在项目中的一些专项自动化，及压力测试等~
有经验相关的分享~

原文借鉴：https://blog.csdn.net/u012613604/article/details/73294120
https://blog.csdn.net/xiadanying/article/details/91587096?spm=1001.2014.3001.5502

肥肥的黑巧

关注

1
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
【Android移动端】app应用性能测试以及相关使用方法介绍

性能测试无论对于哪种app产品，主要分为内存，CPU，耗电三大模块去考虑
复制链接

扫一扫

专栏目录