Android APP性能指标（一）

文章目录

• 一、内存
• • • 1.1 内存测试
    • 1.2 内存场景问题
    • 1.3 测试标准
    • 1.4 测试点
    • 1.5 关注点
• 二、CPU
• • • 2.1 数据获取
    • 2.2 cpu检测的几种情况
    • 2.3 测试点
    • 2.4 具体场景：
    • 2.5 问题排查
• 三、GPU（过度绘制）
• • • 3.1 数据获取
    • 3.2 绘制程度
    • 3.3 测试标准
• 四、FPS（流畅度）
• • • 4.1 FPS指标要求
    • 4.2 数据获取
    • 4.3 帧率检测

本文围绕以下性能指标介绍测试Android端的测试方法：

• 启动时间：启动APP所需时间
• 流畅度：也称为帧率FPS，指画面每秒传输帧数；帧率越大，页面越流畅。
• 过渡绘制：过度绘制描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。
• 内存：占用系统内存的大小
• CPU：对系统CPU的占用率
• 流量：流量消耗
• 电量：电量消耗

一、内存

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

• 与其他进程共享内存（shared drity）
• APP独占的私有内存（private dirty）

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

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

例如：我们查看快看APP的内存运行情况：

1.1 内存测试

1. 空闲状态下，应用内存消耗
2. 中等规格状态下（操作时间较长），应用内存消耗
3. 满格状态下（操作时间较短），应用内存消耗
4. 测试过程中，同时要关注内存峰值、泄漏、内存释放、压测后内存使用情况

较容易出现内存泄漏的部分场景：

• activity间的切换，只要非静态的匿名类对象没有被回收，MainActivity就不会被回收，MainActivity所关联的资源和视图都不会被回收，发生比较严重的内存泄漏。
• 连续查看和发送大图片，不断反复观看返回继续观看等操作，都有可能因为和之前的内存资源没释放而导致内存不断增长。
• 有执行异步线程的场景后如果未给线程进行结束，会引起内存泄漏，因为activity的结束销毁不会把正在运行的thread也结束回收掉。比如后台下载或加载东西时关闭activity。
• 在activity关闭时Handler还没结束，会到导致内存泄漏。例如一些界面UI还在刷新时关闭activity。
• 从登录界面登录账号后，登录界面的activity只是退到后台或是被登录后的activity覆盖，像这种过渡界面的acticity容易出现未去摧毁而出现内存泄漏。

1.2 内存场景问题

1. 内存抖动：频繁的GC，导致UI卡顿
2. 内存溢出：应用申请的内存不够引发的
3. 内存泄漏：应用结束后无法释放内存空间，存在大量次数就会导致内存泄漏
4. 频繁GC（垃圾收集）

1.3 测试标准

测试场景中内存不会出现持续上升或短时间内出现内存抖动情况和无故申请过大内存的情况

1.4 测试点

1. 空闲状态：切换至后台或者启动后不做任何操作，消耗内存最少
2. 中强度状态：时间偏长的操作应用
3. 高强度状态：高强度使用应用，可以跑monkey来测试（通常用来测试内存泄漏）

1.5 关注点

1、退出某个页面后，内存是否有回落
如果没有及时回落，且程序自动GC或者手动GC，那便可确认有问题

GC即（Gabarage Collector，垃圾回收器）是指将废弃的内存重新回收再次使用的过程。

2、进行某个操作后，内存是否增长过快
如果增长过快，也有可能存在风险，需重复操作确认

二、CPU

  CPU测试，主要关注的是cpu的占用率。很多时候，我们玩手机时，会出现发热发烫，那是因为CPU使用率过高，CPU过于繁忙，会使整个手机无法响应用户，整体性能降低，用户体验就会很差，也容易引起ANR（application not responding, 主线程(UI线程)如果在规定时内没有处理完相应工作，就会出现ANR）等等一系列问题。

静态不超过5%，后台静默不超过1%，一般运行状态不超过30%，高负荷运行不超过75%，峰值不超过90%。

2.1 数据获取

• adb shell dumpsys cpuinfo | grep packagename
  
  可以看出靠前行CPU 占用率 4.9%，这个过程是在用户（user）中花 1.5% 的时间，并在内核空间（kernel）花费 3.4% 的时间。

• adb shell top -d 1：每隔1s获取cpu占用
  -t 显示进程名称
  -s 按指定行排序
  -n 在退出前刷新几次
  -d 刷新间隔
  -m 显示最大数量
  
  注：两种方法直接区别在于，top是持续监控状态，而dumpsys cpuinfo获取的实时CPU占用率数据

2.2 cpu检测的几种情况

1. 空闲状态下的应用CPU消耗情况（程序运行后按home键挂后台）
2. 中等规格状态下的应用CPU消耗情况（程序执行普通操作时的cpu占用）
3. 中等规格状态下长时间的应用CPU消耗情况
4. 满规格状态下的应用CPU消耗情况
5. 针对性的场景测试

2.3 测试点

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

2.4 具体场景：

1. 应用空闲状态运行监测CPU占用率
   空闲状态：应用按Home键退到后台，不再占用系统的状态（通常是灭屏半分钟后）
   CPU占用率=0%

2. 应用中等规格运行监测CPU占用率
   中等规格：模拟用户最常见的使用场景
   CPU占用率≤30%

3. 应用满规格长时间正常运行监测CPU占用率
   Monkey测试
   CPU占用率≤30%

4. 应用正常运行期间监测CPU占用率峰值
   应用正常运行：打开应用进行基本操作
   CPU占用率≤50%

2.5 问题排查

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

• 如果是ANR，则在logcat文件里搜索ANR in,以及adb pull 拉取trace文件
• 如果没有ANR则使用上述方法获取到CPU占用率，如果某个场景CPU占用率走势异常，峰值存在异常均值大于基线，则可以使用traceview查看分析Trace文件，反馈给RD解决

三、GPU（过度绘制）

  GPU渲染是指在一个像素点上绘制多次（超过一次）：显示一个什么都没有做的activity界面算作画了1层，给activity加一个背景是第2层，在上面放了一个Text View（有背景的Text View）是第3层，Text View显示文本就是第4层仅仅只是为了显示一个文本，却在同一个像素点绘制了四次，这是一定要优化的。过度绘制对动画性能的影响是极其严重的，如果你想要流畅的动画效果，那么一定不能忽视过度绘制。

3.1 数据获取

方法一：进入开发者选项->调试GPU过度绘制->显示过度绘制区域

方法二：

1. adb shell dumpsys gfxinfo 包名 > GPU.txt
2. pull GPU.txt 文件到本地
3. 定位到Profile datain ms 复制到Excel中绘制表格展示

3.2 绘制程度

1）原色：无过渡绘制
2）蓝色：绘制一次 （理想状态）
3）绿色：绘制二次
4）浅红：绘制三次 （可以优化）
5）深红：绘制四次 （必须优化）

3.3 测试标准

1. 不允许出现黑色像素
2. 不允许存在4X过渡绘制
3. 不允许存在面积超过屏幕1/4区域的3X过渡绘制
4. 动态页面、可滑动/滚动列表，还可参考CPU的数据

四、FPS（流畅度）

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

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

1. 系统层级的指标仅有FPS，本身的Surface的合成需要在SurfaceFlinger中进行
2. 应用层级的指标有三类：
   （1）Aggregate frame stats，属于HWUI功能。HWUI进行Surface绘制后才能分析
   （2）Jankiness count、MAx accumulate frames、Frame rate适合范围广
   （3）SM、Skipped frames 需要Choreographer 绘制Surface 才能正常工作

4.1 FPS指标要求

• 在android 屏幕中刷新率为60帧/秒
• 每一帧时间不超过16.6ms，画面流畅不卡顿，建议最低大于50FPS
• 帧率<=50需优化，>=55为良好，>=57为优秀
• 不出现连续丢帧情况

4.2 数据获取

方法一：adb命令
（1）手机开启开发者模式，开启“HWUI呈现模式分析”，选择“在adb shell dumpsys gfxinfo中”
（2）adb shell dumpsys gfxinfo 包名获取数据计算滑动帧率和掉帧数

如上图信息表示了每一帧在安卓系统中的四个阶段：

• Draw：表示在Java中创建显示列表部分中，OnDraw()方法占用的时间
• Prepare：准备时间
• Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长
• Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间，其实是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间

将上面的四个时间加起来就是绘制一帧所需要的时间，如果超过了16.67就表示掉帧了

计算帧率公式：FPS=1000/(Draw+Prepare+Process+Execute)

流畅度标准：

• Android定义了流畅度的数据标准，以60FPS为标准(FPS为每秒绘制的帧数)，帧数过小就会出现卡顿感
• 每一帧在安卓系统中分4个阶段，4个阶段的总和超过16.67(1秒60帧，算下来平均1帧的间隔就约是16.67ms)就认为丢帧
• 这个定义在Android6.0以前是一定的，但是现在已经没有固定的标准了，因为目前安卓系统有3层缓存机制，加上硬件上的进步，即使超过16.67，也不一定会出现卡顿感。所以这个数据在测试时作为一种对比和相对衡量标准，也可根据需求自定义标准

方法二：开发者选项自带的分析图
手机开启开发者模式，开启“HWUI呈现模式分析”，选择“在屏幕上显示为条形图”

4.3 帧率检测

1. ListView界面的帧率
2. 可滑动界面帧率，如长的textview或可滑动的长图等
3. 动画较多的页面操作帧率
4. 针对性的场景测试

可能引起掉帧的原因：

1. 手机性能差，CPU + GPU工作效率低下
2. 横竖屏切换，需要用savedInstanceState保存的view信息进行重画
3. 动画效果太多
4. GC太多
5. UI线程阻塞
6. 界面试图结构过于复杂（可以通过Hierachy View查看）
7. 过度绘制

注意：如果只掉了一帧，但是这帧所占时间较长，比如占了几个垂直同步信号的时间，虽然总体的FPS值还不错，但依然能肉眼感知到这帧的卡顿，所以这种情况也需注意。

参考文档：https://juejin.cn/post/7067840066101608484#heading-5