本文干货较多，都是硬菜，请做好准备！

性能测试是初级工程师向高级成长绕不开的话题，很多大公司都明确的在招聘要求上点明了需要具备性能测试经验，而对现在越来越普遍的移动端测试，我们如何更好的进行Android的性能测试，实际上如今我们能很方便的获取到各类优秀的性能测试工具，诸如腾讯的WeTest、PerfDog等等，但今天笔者希望从原生的角度来分享如何利用Android本身的工具进行性能测试，理解了这些你也就能够理解WeTest等工具是如何制作出来的，更甚至你也可以制作自己的WeTest工具了。

为什么需要APP性能测试

1、发现非功能性的Bug

我们可以通过性能测试发现诸如内存泄漏、卡顿、闪退等非功能性的Bug，这类Bug只有通过专项的性能测试方法，才能够给出准确的指标来定性，不能再功能测试阶段用一些类似“用起来不顺畅”等模糊不清的描述来概括。

2、给出APP体验上不同维度的评估

在测试过程中我们可能会感觉产品的启动慢、页面响应慢或是耗电快等等，这类体验上的感知同样也需要我们通过专项的性能测试来得出结果指标，从而对产品的体验给出性能维度的定性。

3、分析APP是否满足产品预期

产品工程师在初期往往会对产品有一个预期，比如主打中端机还是高端机等等，这类产品预期也需要我们通过对不同档位的机型进行性能测试，给出最终的评估结果是否满足预期。

ADB

要做Android的性能测试，就不得不提一下ADB工具，我们今天提到的几乎所有测试手段，都基于ADB来实现。

1、什么是ADB

ADB的全称为Android Debug Bridge，就是起到调试桥的作用。

ADB是Android sdk里的一个工具，用这个工具可以直接操作管理android模拟器或者真实的andriod设备(如手机)

Google将丰富的对Android系统的操作接口都放进了ADB工具中，使得我们可以通过它进行我们性能测试相关的各类需求。

2、ADB的组成

ADB由以下三个部分组成

• 运行在PC端Client
• 运行在设备中Deamon守护进程
• 运行在PC端的Service

ADB架构

由上图就可以看出

ADB在手机端有一个服务进程来相应相关的指令

PC端则也起了一个服务起了承上启下的作用，它接收PC端Client的指令，并将其转化为相应的手机指令转递给手机端的服务进程，PC端则可以有多个Client向PC端的服务进程发送指令。

3、ADB基本命令

这里介绍一些基础的ADB命令，在后续的章节，会接着介绍跟性能测试相关的更高级的指令

ADB命令

Android性能测试

有了ADB工具，我们现在可以利用它开始各类Android的性能测试了。

实践中，我们往往会从以下几个方面来进行Android的性能测试，我们一一来介绍。

Android性能测试

1、响应时间

响应时间指我们做出一个操作后，页面响应需要花费的时间

Android响应时间

我们会从上图中的几个方面来进行响应时间的评估

• 冷启动：当启动应用时，后台没有该应用的进程，这时系统会首先会创建一个新的进程分配给该应用，这种启动方式就是冷启动。
• 热启动：当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动。
• 温启动 ：当启动应用时，后台已有该应用的进程，但是启动的入口Activity被杀掉了，比如按了back键，应用虽然退出了，但是该应用的进程是依然会保留在后台，这种启动方式叫温启动。

可以通过下图中Android的Activity的生命周期来分析各类启动方式触发的流程转换

Activity生命周期

那么对应如何获取某个操作后具体的响应时间，我们大致有两种方式可以选择

ADB命令

adb shell am satrt –W –n <package>/<activity>

通过上述命令我们可以获取到三个参数指标

• ThisTime：应用有界面Activity启动耗时
• TotalTime：应用自身启动耗时
• WaitTime：系统启动应用耗时

他们对应到一个Activity的响应时间的三个维度，往往我们会选择TotalTime来作为启动时间的结果。

通过ADB命令的方式，我们可以获取启动时间的结果，但却无法获得页面跳转时的响应时间

视频解帧

我们还可以通过手机录屏或是高速摄像机拍摄的方式，将整个启动过程给录制下来，然后对录制的视频进行分帧处理，计算出从操作开始到响应结束的总耗时长。

这种方式适用于包含启动时间和页面跳转时间等所有响应时间相关的测试项，且不光可用于Android，由于这是一种外部物理手段，所以可以应用于包括iOS在内的所有移动端测试。

2、内存

对Android内存相关的性能测试，我们主要关注以下三种场景

• 空负荷：app已经在后台运行，但是用户没有使用
• 中负荷：app在前台运行，用户进行了少量操作
• 满负荷：用户持续频繁大量操作，app接近饱和状态运行

Android的内存指标有如下几种

• VSS：Virtual Set Size，虚拟内存VSS= RSS+ 未分配实际物理内存
• RSS：Resident Set Size，物理内存RSS= USS+ 包含共享库
• PSS：Proportion Set Size，实际使用的物理内存，共享库等按比例分配。
• USS：Unique Set Size，物理内存进程独占的内存

其中VSS >= RSS >= PSS >= USS

往往我们只需要关注PSS即可，我们可以通过ADB命令获取该值，命令如下

• procrank：可以查询VSS、RSS、PSS、USS的信息
• dumpsys meminfo：则可以直接查询PSS的详细信息

一般地，我们可以一边操作APP，一边获取一段时间内的内存情况，绘制成内存曲线，观察内存占用是否合理以及是否存在内存泄漏导致内存持续增长的问题。

3、CPU

CPU测试的关注场景和内存测试完全相同，只不过关注的指标变为了CPU而已。

我们可以通过以下两种方式来获取CPU的占用情况

adb shell dumpsys cpuinfo <package> pid //获取当前cpu占有情况

adb shell top -n 20 -d 2 |grep <package_name> //连续获取CPU情况

4、GPU

GPU的关注点实际上是检验APP本身是否存在卡顿、掉帧等现象，这些现象都与帧率也就是FPS这个指标息息相关。

FPS即Frames per second，有两个关键指标60帧每秒以及16.67毫秒，因为60帧每秒的流畅度是最佳的，所以每帧的耗时为16.67ms。实际上，测试的标准是24帧和41.67ms，也就是说低于24帧则会在感知上能够感受到卡顿。

想要获取手机的FPS，我们需要进行如下操作

• 在开发者选项中GPU呈现模式分析选择“在adbshell dumpsysgfxinfo中”
• 使用命令adbshell dumpsysgfxinfo<package>获取FPS

当我们能够获取到FPS值之后，我们就可以像CPU、内存测试一样，一边在手机端进行我们需要覆盖的页面和操作，一边记录FPS的值并绘制成曲线，最终分析曲线中的最小值和平均值等得出我们的GPU测试结论。

而实际上，真正深入的进行卡顿、掉帧测试时，要比上面复杂的多，往往我们还需要对APP进行插桩或打上性能工具SDK，通过一些卡顿、掉帧的算法，更精准的得到APP在哪些时间出现了连续掉帧等等，感兴趣的可以留言或关注笔者进行进一步的交流

5、电量

电量实际上是一个弱性能测试项，大多数APP可能并不关注这个指标，游戏类的APP会更关注电量指标。

而在电量的测试方法上我们可以分为三大类

• CPU间接反馈：也就是把电量的消耗模糊的近似于CPU的占用，CPU占用越高电量消耗越大，从而把电量测试转化为CPU测试
• 手机电量获取：通过手机自身的电量管理或是第三方的电量监控工具等绘制电量使用的曲线图来分析，实际上手机自身提供的电量消耗并不是一个准确值，而是手机厂商利用算法给出的近似值。
• 电流仪：这种方案是最深入的测试方式，往往不会应用于单个APP的测试，而是手机本身的测试多一些，使用电流仪可以精准的测量出手机的电量消耗情况，所以这种方式测试的结论是最准确的。

6、流量

流量测试就是分析APP本身的使用对流量的消耗情况，毕竟用户使用APP产生了流量消耗直接跟话费相关，所以一些大流量消耗的APP会关注自身流量消耗的测试结果。

那么如何获取流量的消耗情况呢，我们也有两种方式

抓包分析

使用tcpdump+ wireshark的方式（需要root权限）

我们可以在手机Root之后给手机安装tcpdump工具，熟悉抓包相关的朋友应该很清楚，tcpdump可以抓包手机所有进出的报文，然后我们再导出这些报文进行流量的计算即可

ADB命令

使用adb shell cat /proc/pid/status获取上下行流量

我们可以通过adb命令获取某个进程的上下行流量，那么我们首先查询我们要测试的APP的pid，接着我们可以在时间点A通过命令获取上下行流量，然后在时间点B再次获取上下行流量，最后相减后就能得到A到B这段时间消耗的总流量了。

对于流量测试我们往往覆盖我们的核心操作，得出这些操作最终消耗的流量大小汇总即可。

好了，到此我们分享了所有Android性能测试相关的方法，不知是否对你有帮助呢，基于这些方法你也可以开发属于公司自己的测试工具出来，方便进行各类的性能测试，想要进一步交流的欢迎留言。

实际上很多朋友把Monkey测试也当成是性能测试的一种，我个人更偏向把它定位为单独的稳定性测试，因为Monkey往往有测试周期长的特性，后续我们会专门花时间来系统性的介绍如何进行Monkey测试，感兴趣的朋友可以关注我。