APP性能测试中的几个重要概念

转载一篇文章，关于app性能测试的几个概念，对于想要接触app测试的朋友或许有些帮助。

咱们在使用各类 App 的时候基本会关注到：这款软件挺耗流量的？运行起来设备掉电有点快嘛？切换页面的时候还会有卡顿等现象？若是遇到有这些问题的 App 咱们基本会将它请出咱们的爱机。因而可知软件是否受欢迎除了提供必要的功能外，流畅性、流量/电池消耗也是很重要的指标。

　　今天就来从咱们 测试人员的角度，谈一谈 App 验收测试过程当中须要关注到一些指标项目：

　　●内存占用

　　●CPU 占用

　　●流量耗用

　　●电量耗用

　　●启动时间

　　由于最近就着 腾讯 TMQ 团队出版的《移动 App 性能评测与优化》这本书在看 App  性能测试这一块的东西，看着看着发现有些名词或者概念不是很明白，因此在看这块东西的时候，还要一边去查询一些其余的点，如今将这些点 记录下来，也算是一篇读书笔记了吧，下面针对每个方面的一些重要知识点进行了整理。

　　一. 内存

　　1. 内存泄漏

　　说到内存方面，最经典的内存问题当数内存泄漏。 百度上对内存泄漏的定义是这样的：内存泄漏（Memory Leak）是指程序中己动态分配的堆内存因为某种缘由程序未释放或没法释放，形成系统内存的浪费，致使程序运行速度减慢甚至系统崩溃等严重后果。通俗点讲，在大部分应用中，会有一类功能是须要加载附加资源的，好比显示从网络下载的文本或图片。这类功能每每须要在内存中存放要使用的资源对象，退出该功能后，就须要将这些资源对象清空。若是忘了清理，或者是代码缘由形成的清理无效，就会造成内存泄漏。

　　 2. 垃圾回收

　　说到了内存泄漏，又不得不提到垃圾回收（Garbage Collector，简称 GC），内存中的垃圾，主要指的是内存中已无效但又没法自动释放的空间，除非是重启系统否则永远也不会还给 操做系统。这样以来，时间久了当程序运行的时候就会产生不少垃圾，一方面浪费了很多内存空间，另外一方面若是同一个内存地址被删除两次的话，程序就会不稳定，甚至奔溃。

　　在 Java 程序运行过程当中，一个垃圾回收器会不定时地被唤起检查是否有再也不被使用的对象，并释放它们占用的内存空间。但垃圾回收器的回收是随机的，可能在程序的运行的过程当中，一次也没有启动，也可能启动不少次，它并不会由于程序一产生垃圾，就立刻被唤起而自动回收垃圾。因此垃圾回收也并不能彻底避免内存泄漏的问题。

　　另外一方面，垃圾回收也会给系统资源带来额外的负担和时空开销。它被启动的概率越小，带来的负担的概率就越小。

　　 3. 内存指标

　　内存指标有 VSS、RSS、PSS、USS，他们的含义分别是：

　　VSS：Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）

　　RSS：Resident Set Size 实际使用物理内存（包含共享库占用的内存）

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

　　USS：Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

　　通常来讲内存占用大小有以下规律：VSS >= RSS >= PSS >= USS，通常测试中关注的比较多的是 PSS 这个指标。

　　 4. 监控与分析工具

　　如下是几种常见的内存分析工具，具体使用方法这里就不详述了。

　 　4.1 Memory Monitor

　　该工具位于  Android Monitor 下面，Android Monitor 是 Android Studio 自带的一个强大的性能分析工具，里面一共包含 5 个模块：Logcat、Memory、CPU、Network 及 GPU。

　　Memory Monitor 能够实时查看 App 的内存分配状况，判断 App 是否因为 GC 操做形成卡顿以及判断 App 的 Crash 是不是由于超出了内存。

　 　4.2 Heap Viewer

　　该内存检测工具位于 DDMS 下面，在 Android Studio 里面能够经过 Tools-Android-Android Device Monitor 打开，Heap Viewer 能够实时查看 App 分配的内存大小和空闲内存大小，而且发现 Memory Leaks。

　 　4.3 MAT

　　MAT（Memory Analyzer Tool），是一个被老生常谈的 Android 内存分析工具，它能够清楚的获知总体内存使用状况。虽然是 Eclipse 的工具，但也能够单独运行，不须要安装 Eclipse。

　 　二. CPU

　　1. 时间片

　　时间片即 CPU 分配给各个程序的时间，每一个线程被分配一个时间段，称做它的时间片，即该进程容许运行的时间，使各个程序从表面上看是同时进行的。

　　 2. Jiffies

　　2.1 Jiffies的概念

　　要讲 Jiffies 须要先提到这两个概念：HZ 和 Tick

HZ： Linux 核心每隔固定周期会发出 timer interrupt (IRQ 0)，HZ 是用来定义每一秒有几回 timer interrupts。例如 HZ 为 1000，就表明每秒有 1000 次 timer interrupts。 　　Tick：HZ 的倒数，Tick = 1/HZ，即 timer interrupt 每发生一次中断的时间。如 HZ 为 250 时，tick 为 4 毫秒（millisecond）。

　　而 Jiffies 为 Linux 核心变量，是一个 unsigned long 类型的变量，被用来记录系统自开机以来，已通过了多少 tick。每发生一次 timer interrupt，Jiffies 变数会被加 1。

　　 2.2 查看 Jiffies 的方法

　　Linux 下使用命令cat /proc/stat，查看具体整机的 Jiffies，如图：

　　Linux 下使用命令cat /proc/<进程id>/stat，查看具体某个进程的 Jiffies：

　　 3. CPU 使用率

　　在 Linux 系统下，CPU 利用率分为用户态、系统态和空闲态，他们分别表明的含义为：用户态表示 CPU 处于用户态执行的时间，系统态表示系统内核执行的时间，空闲态表示空闲系统进程执行的时间。

　　而一个 App 的 CPU 使用率 = CPU 执行非系统空闲进程时间 / CPU 总的执行时间，也能够表示为 App 用户态 Jiffies + App 系统态 Jiffies /  手机总 Jiffies。

　 　4. CPU 太高会带来的影响

　　可能会使整个手机没法响应，总体性能下降，引发 ANR，致使手机更耗电，下降用户体验等。

 

三. 流量

　　1. 定义

　　咱们的手机经过运营商的网络访问 Internet，运营商替咱们的手机转发数据报文，数据报文的总大小（字节数）即流量，数据报文是包含手机上下行的报文。

　 　2. 经常使用流量测试方法

　　2.1 抓包测试法

　　主要是利用工具 Tcpdump 抓包，导出 pcap 文件，再在 wireshark 中打开进行分析。

　 　2.2 统计测试法

　　2.2.1 读取 linux 流量统计文件

　　利用 Android 自身提供的 TCP 收发长度的统计功能，获取 App 的 tcp_snd 和 tcp_rcv 的值，测试一段时间后再分别统计一次，用 tcp_snd

　　二者的差值获得发送流量，用 tcp_rcv 二者的差值获得接受流量。

　　2.2.2 利用 Android 流量统计 API

　　TrafficStats

　　Android 2.2 版本开始加入 android.net.TrafficStats 类来实现对流量统计的操做。

　　部分方法以下：

static long getMobileRxBytes() //获取经过移动数据网络收到的字节总数  　　static long getMobileTxBytes() //经过移动数据网发送的总字节数  　　static long getTotalRxBytes() //获取设备总的接收字节数  　　static long getTotalTxBytes() //获取设备总的发送字节数  　　static long getUidRxBytes(int uid) //获取指定uid的接收字节数  　　static long getUidTxBytes(int uid) //获取指定uid的发送字节数

　　●NetworkStatsManager

　　Android 6.0 版本开始，为了打破了本来 TrafficStats 类的查询限制，官方又提供了 NetworkStatsManager 类，能够获取更精准的网络历史数据，也再也不是设备重启以来的数据。部分方法以下：

NetworkStats.Bucket querySummaryForDevice(int networkType, String subscriberId, long startTime, long endTime) // 查询指定网络类型在某时间间隔内的总的流量统计信息 　　 NetworkStats queryDetailsForUid(int networkType, String subscriberId, long startTime, long endTime, int uid) // 查询某uid在指定网络类型和时间间隔内的流量统计信息 　　 NetworkStats queryDetails(int networkType, String subscriberId, long startTime, long endTime) // 查询指定网络类型在某时间间隔内的详细的流量统计信息（包括每一个uid）

　　四. 电量

　　1.耗电场景

　　定位，尤为是调用 GPS 定位。

　　网络传输，尤为是非 Wifi 环境。

　　屏幕亮度

　　CPU 频率

　　内存调度频度

　　wake_locker 时间和次数

　　其余传感器

　 　2.测试方法

　　2.1 经过系统文件获取电量记录

　　使用命令 adb shell dumpsys batterystats> batterystats.txt 能够打印出详细的耗电相关信息并保存统计的电量信息到 batterystats.txt 这个文件里。

　　 2.2 经过导入 batterystats.txt 到 Google 开源工具 battery historian 进行分析

　　由于这个工具是 Go 语言开发，因此须要预装Go语言开发环境，固然若是你不想配置Go语言环境，官方还提供了一种更方便的方案，经过安装 docker 环境来使用这个工具。具体这个工具的配置安装和具体使用方法以及参数的表明含义，我会单独再写一篇文章记录，先抛砖引玉放一张这个工具的运行截图。

　 　3.优化方法

　　3.1 CPU 时间片

　　当应用退到后台运行时，尽可能减小应用的主动运行，当检测到 CPU 时间片消耗异常时，深刻线程进行分析。

　　 3.2 wake lock

　　前台运行时不要注册 wake lock。

　　后台运行时，在保证业务须要的前提下，应尽可能减小注册 wake lock。

　　下降对系统的唤醒频率， 使用 partial wake lock 代替 wake lock。

　 　3.3 传感器

　　合理设置 GPS 的使用时长和使用频率。

　　 3.4 云省电策略

　　考虑到用户使用场景的多样性，致使很难定位用户异常耗电的根源，因此为了更深一层弄清楚这些问题，能够考虑按期上报灰度用户手机电量数据的方式来分析问题。

　 　五. 启动时间

　　可以使用命令 adb shell am start -W packagename/activity 查看 App 启动耗时，查看了一下咱们本身的 App Android 版本的启动耗时以下：

　　注释：

　　WaitTime：总的耗时，包括前一个应用 Activity pause 的时间和新应用启动的时间

　　ThisTime：一连串启动 Activity 的最后一个 Activity 的启动耗时

　　TotalTime：新应用启动的耗时，包括新进程的启动和 Activity 的启动，但不包括前一个应用 Activity pause 的耗时

　 　六. 总结

　　App性能问题会直接影响产品体验：耗流量、掉电快、卡顿、崩溃等现象会给用户形成不良的体验和印象，不利于产品的活跃及用户留存。许多经验丰富的程序员也会常常忽视这些不起眼的性能问题，所以做为测试人员，在版本发布前及早关注并发现上述性能问题就显得尤为重要。但真正作起App性能测试才发现这条路并不容易走，抓取内存、CPU 等一些项目的指标容易，但对一些数据的敏感度和处理方式都是要靠经验的慢慢积累。总之，性能测试算是一项比较繁琐的工做，但难者不易，易者不难，但愿已经行走在这条路上的或者准备踏上这条路的同行都能不断提升自身素养，坚持到底。

 

原文地址：http://www.51testing.com/html/64/n-3724964.html