一、 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 -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 启动时长测试方法，主要有以下几种
- Xcode Developer Tool： 使用 Instruments 的 Time Profiler 插件，可以检测 App CPU 的使用情况。能看到 App 的启动时间和各个方法消耗的时间；
- 客户端计算统计： 通过 hook 关键函数的调用，计算获得性能数据。目前知乎 App 性能监控已有启动时长数据，类似的还有一些第三方的性能测试工具；
- 录屏：使用截屏、录屏、高速摄像机录像等方法，记录移动设备屏幕上的变化，分析启动的起止点，获取 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）修复建议/风险
实例：
