移动APP性能测试 - 走看看

一、 App 性能指标

 App 性能问题如 app 使用时卡顿严重或者加载页面慢，cpu 占用率高，app 闪退等，在测试过程中，则需特别关注性能方面的体验，app 性能差，通常会导致用户对 app 的使用率下降，卸载率上升。

性能专项测试用户维度

 性能专项测试技术维度

响应

软件的响应时间和响应速度直接影响到用户的体验度，如果一个软件，迟迟加载不出来，会直接影响到软件的日活、留存。因此对于一个软件，对响应速度测试是必不可少的。

优秀：0～400ms，标准：400ms～2000ms，轻微隐患：2000ms～5000ms，严重隐患：5000ms 以上。

内存

在 Android 系统中，每个 APP 进程除了同其他进程共享内存(shared dirty)外，还独用私有内存(private dirty)，通常我们使用 PSS(私有内存+比例分配共享内存)来衡量一个 APP 的内存开销。由于一个移动设备的内存是固定的，如果内存消耗过大就会造成应用卡顿或者闪退，需要对内存进行测试。正常情况下，应用不应占用过多的内存资源，且能够及时释放内存，保证整个应用内的稳定性和流畅性。

CPU

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

FPS

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

一般，Android 设备的屏幕刷新率为 60 帧/s，要保持画面流畅不卡顿，要求每一帧的时间不超过 1000/60=16.6ms，这就是 16ms 的黄金准则，如果中间的某些帧的渲染时间超过 16ms，就会导致这段时间的画面发生了跳帧，因此原本流畅的画面变发生了卡顿。

GPU 过度渲染

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

耗电量

测试应用对电量的消耗前需要对手机本身的电量消耗有个大概了解，测试前先看规定时间内手机正常待机下（重启后待机）电量消耗为多少，然后再启动待测试 APP看看消耗的电量增加了多少取差值。

测试点：

测试手机安装目标 APK 前后待机功耗无明显差异；

常见使用场景中能够正常进入待机，待机电流在正常范围内；

长时间连续使用应用无异常耗电现象。

流量测试

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

每秒钟平均流量，建议值<5.12kb，每 10 分钟平均流量，建议值<3MB,不存在 app偷跑流量等行为。 

二、 使用 adb 进行测试

1.App 响应时间和响应速度测试

1.1 主要测试点

冷启动：首次启动 app 的时间间隔（只是启动时间，不包括页面加载）

热启动：非首次启动 app 的时间间隔（只是启动时间，不包括页面加载）

Activity的启动流程

1.2 测试方法

冷启动

adb shell am start -W com.tencent.mm/.ui.LauncherUI（启动App)

adb shell am force -stop 包名（停止APP）

绝对路径，首个 Activity

 am 是 shell 中集成的一个命令，ActivityManager 的简写。

 -W 是指启动完成之后，返回启动耗时。

可能存在 app 缓存（提示 Warning: Activity not started, intent has been delivered to currently running top-most instance），建议重新打开模拟器后，直接运行命令

含义

 ThisTime: 该 Activity 的启动耗时，单位 ms；

 TotalTime: 应用自身启动耗时, ThisTime+应用application等资源启动时间；

 WaitTime: 系统启动应用耗时, TotalTime+系统资源启动时间。

如果只关心某个应用自身启动耗时，参考 TotalTime；如果关心系统启动应用耗时，参考 WaitTime；如果关心应用所有界面 Activity 启动耗时，参考 ThisTime。

热启动

按返回按键（adb shell input keyevent 3）后再启动 adb 命令

测试标准：冷启动时间不超过 1.5s，热启动不超过 1s。

注意：此种方法不包含页面渲染时间。

可以通过录屏逐帧的方式获取到首屏渲染时间。

andriod录屏方式：

adb shell screenrecord --time-limit 10 /sdcard/video.mp4（--time-limit 10：限制录制时间10s,不做限制默认为180s）

adb pull  /sdcard/video.mp4 /user/desktop/video

录屏逐帧

通过ffmpeg分帧（ffepeg的配置参考：https://blog.csdn.net/chy466071353/article/details/54949221）

ffmpeg -i d:/test/video.mp4 -r 10 -threads 2 d:/test/Android-Capture-%05d.png  (-r 10 表示1s分成10帧,即1帧为0.1s)

视频内容包含：桌面 → 被测 App 图标变黑 → 展示知乎开屏 → 展示主体框架 → 首页内容加载完成。

由于首页内容加载完成是异步实现的，因此我们选取分析的关键节点，是「被测 App 图标变黑」和「展示主体框架」这两个点。

通过 FFmpeg 将视频转换成分帧后的图像，用[展示主体框架]图片的后缀减去[被测图片APP变黑]的后缀*0.1s。

 (49-11)*0.1=3.8s

1.3ios启动时长的获取

参考知乎 iOS App 启动时间测试实践 - 知乎，主要方式也是录屏。

常见的 iOS 启动时长测试方法，主要有以下几种

1. Xcode Developer Tool： 使用 Instruments 的 Time Profiler 插件，可以检测 App CPU 的使用情况。能看到 App 的启动时间和各个方法消耗的时间；
2. 客户端计算统计： 通过 hook 关键函数的调用，计算获得性能数据。目前知乎 App 性能监控已有启动时长数据，类似的还有一些第三方的性能测试工具；
3. 录屏：使用截屏、录屏、高速摄像机录像等方法，记录移动设备屏幕上的变化，分析启动的起止点，获取 app 启动的耗时。

方法 1 可以精确获取各个方法调用的耗时，需要 App 是 developer 证书签名，否则无法执行测试；

方法 2 可以精确获取各个启动项耗时，但和实际用户体验感受有一定出入，且需要拿到客户端源码，将工具嵌入客户端中；

方法 3 和用户直观感受一致，但分析截屏、视频较麻烦，且发现问题时，无法定位到具体的启动耗时项。

目前对于竞品启动时长的对比测试，由于源码和签名的限制，方法 1 和 2 都不太合适。

注意：有时会存在启动页面广告，而各 App 在展示开屏广告的过程中，可能会有其他启动项在执行。所以需要分两个场景进行测试，有广告和无广告。

2 .内存占用测试

2.1 主要测试点

空闲状态

　　切换至后台或者启动后不做任何操作，消耗内存最少。

中强度状态

　　时间偏长的操作应用。

高强度状态

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

　　内存泄漏(OOM）:指使用 malloc 或 new 申请了一块内存，但是没有通过 free 或 delete 将内存释放，导致这块内存一直处于占用状态。

2.2 测试方法

使用 adb 命令

 adb shell dumpsys meminfo com.tencent.mm

主要指标

  Native heap allocNative：代码分配的内存，虚拟机和Android框架分配内存。

  Dalvik heap alloc：Java对象分配的占据内存

     若这两个值一直增长，说明可能出现内存泄漏

   PSS：App 实际占用的内存大小。

主要关注

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

   如果没有及时回落，且程序自动 GC（Garbage Collection，垃圾回收）或者手动 GC，那便可确认有问题。

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

   如果增长过快，也有可能存在风险，需重复操作确认

android内存主要有四种形式：VSS 、RSS 、PSS 、 USS

一般来说内存占用大小有如下规律：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是用来检查进程中是否有内存泄露的最好选择。

内存

JAVA是在JVM所虚拟出的内存环境中运行的，JVM的内存可以分成三个区，堆（heap）、栈（stack）和方法区（method）。

栈（stack）

是最简单的数据结构，但在计算机中使用广泛。栈最显著的特征是：LIFO(后进先出），栈中只存放基本类型和对象的引用（不是对象）

堆（heap）

堆内存用于存放由new创建的对象和数组。在堆中分配的内存，由java虚拟机自动垃圾回收器来管理。JVM只有一个堆区被所有线程共享，堆中不存放基本类型和对象引用，只存放对象本身。

方法区（method）

又叫静态区，跟堆一样，所有的线程共享。方法区包含所有的static变量。

内存泄露

程序在向系统申请分配内存空间后（new）,在使用完毕后未释放。结果导致一直占用该内存单元，我们和程序都无法再使用该内存单元，直到程序结束。

内存溢出

程序向系统申请的内存空间超出了系统能给的，比如一车最多坐5个人，你确非要塞下10个，车就挤爆了。

大量的内存泄露会导致内存溢出（OOM）

内存泄露对应用的影响

内存泄露对于APP没有直接危害，即使有发现内存泄露的情况，也不一定会引起APP崩溃

内存得不到释放，慢慢的会造成app内存溢出，导致崩溃

内存泄露同时会触发系统频繁GC,发生内存抖动，会导致性能问题（卡顿不流畅）

3.CPU 繁忙测试

3.1 主要测试点

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

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

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

3.2 具体场景

应用空闲状态运行监测 CPU 占用率

   应用按 Home 键退到后台，不再占用系统的状态（通常是灭屏半分钟后）

   CPU 占用率=0%

应用中等规格运行监测 CPU 占用率

   模拟用户最常见的使用场景

   CPU 占用率≤30%

应用满规格长时间正常运行监测 CPU 占用率

   应用正常运行，打开应用进行基本操作

   CPU 占用率≤50%

3.3 测试方法

adb shell dumpsys cpuinfo apk 包名

adb shell top -m -s | findstr packageName

 -m 数字

   显示指定数目的最大值，一般后面不再接 findstr

   使用-m 会导致隐藏列名

 -s 数字

   按指定列号进行倒序排列

   从 1 开始，最大 11

    9 代表 CPU，10 代表内存

 -n 数字

    刷新几次后退出

 -d 秒数

   刷新间隔

 q 回车

   退出

4.FPS 应用流畅度测试

帧率(Frame Rate)：代表GPU在一秒内绘制操作的帧数，例如：30fps，60fps

刷新频率(Refresh Rate):代表屏幕在一秒内刷新屏幕的次数，这取决于硬件的固定参数，如60HZ.

(1)开启 Profile GPU rendering Settings→System→Advanced→Developer options→查找 profile→找到并单击 Profile GPU rendering→In adb shell dumpsys gfxinfo

(2)打开要测试的 app

adb shell dumpsys gfxinfo 包名

 Graphics info for pid 1331 [com.tencent.mm]：表明当前 dump 的为 com.tencent.mm的帧信息，pid 为 1331。

 Total frames rendered: 2218：本次 dump 搜集了 2218 帧的信息。

 Janky frames: 26 (1.17%)：帧中有 26 帧的耗时超过了 16ms，卡顿概率为 1.17%。

 Number Missed Vsync: 3：垂直同步失败的帧

 Number High input latency:2213：处理 input 时间超时的帧

 Number Slow UI thread: 1：因为 ui 线程导致 slow 的帧

 Number Slow bitmap uploads: 0：因为 bitmap 加载 slow 的帧

 Number Slow issue draw commands: 3：因为绘制导致 slow 的帧

 Draw: 表示在 Java 中创建显示列表部分中的 OnDraw()方法占用的时间。

 Prepare：表示渲染引擎准备时间。

 Process：表示渲染引擎执行显示列表所花的时间，view 越多，时间就越长。

 Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。其实是实际显示帧数据的后台缓冲区与前台缓冲区交换后，将前台缓冲区的内容显示到屏幕上的时间。

 Draw + Perpare+Process + Execute = 完整显示一帧 ，这个时间要小于 16ms 才能保存每秒60 帧。

通过 execl 进行表格处理可以直观的查看软件的流畅度

只保留 Process、Draw、Execute,将三列加和绘制线图;16ms 以上的卡顿，需要优化

 Settings→System→Advanced→Developer options→查找 profile→on screen as bars结果以图形形式显示在设备中

    开启此功能后，随着屏幕刷新，界面上会滚动显示垂直的柱状图来表示每帧画面所需要渲染的时间，柱状图越高表示花费的渲染时间越长。

    每个直方条代表一帧，每个直方条的高度表示该帧渲染所用的时间（以毫秒为单位）

   界面中间一根绿色水平线代表 16ms，每一帧的柱状线都在这条绿线以下，才能避免出现由丢帧引起的卡顿。

颜色含义（Android 6.0 及更高版本中的竖条区段）

5.GPU 过度渲染测试

开启 GPU 过度渲染

设置→开发者选项→单击 Debug GPU overdraw→选择 show overdraw areas

 GPU 过渡渲染不同的颜色代表不同的绘制程度

原色：无过渡绘制

蓝色：绘制一次 （理想状态）

绿色：绘制二次

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

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

测试指标

控制过渡绘制为 2x

不允许存在 4x 过渡绘制

不允许存在面积超过屏幕 1/4 的 3x 过渡绘制

6、流量数据获取

先获取进程命令 adb shell ps | grep 包名

获取流量：adb shell cat /proc/进程名/net/dev

receive表示收包（下行）

Transmit表示收包（上行）

bytes表示收发的字节数

packets表示收发正确的包量

errs:表示收发错误的包量

drop表示收发丢弃的包量

7、电量数据获取

adb shell dumpsys battery set status 1（设置手机进入非充电状态  2为充电状态） 

db shell dumpsys battery（获取电量）  level表示电量

8、如何开展性能专项测试

1）什么时间点开展？

一般情况只有大版本迭代或者重点性能优化才进行

2）基于什么基础上测试？

历史版本&竞品

3）什么时间点开展？

一般在第一轮测试结束无需大修改

4）要哪些场景？

App核心场景，需要优化场景

5）要测什么包？

一般测正式包，反应真是用户体感

6）要测几轮？

一般正式测试一轮，剩余看开发优化

9、性能专项测试流程

1）跟进版本确定这个版本性能测试需求

2）跟开发确定测试场景和侧重点，并且确定基线数据和测试手段

基线数据：前三个版本的最优数据和竞品数据

3）执行性能测试采集数据

4）编写性能测试报告

10、性能专项测试报告

1）基本信息：版本/测试机型/测试场景/基线场景

2）问题概述：具体问题列表

3）具体性能专项数据列表

4）修复建议/风险

实例：