无线性能测试相关知识

几个容易混淆的概念：

备注：灰度测试，小部分的投放市场，大部分用户采用原来的应用，小部分的采用新版本。



性能测试和负载测试等的主要区别是目的不同



负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试是一种测试方法，可以为性能测试、



压力测试所采用。负载测试的加载方式也有很多种，可以根据测试需要来选择。



性能测试是为获取或验证系统性能指标而进行测试(特定负载)。多数情况下，性能测试会在不同负载情况下进行。



·压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。

灰度测试，性能测试，压力测试，负载测试的定义

 

无线性能测试相关指标有：CPU使用，耗电量，流量，响应时间，内存分配等

自然可以利用各种各样的手机管家/卫视，包括阿里内部的摩天轮/易测等。不过从原理上分析：

 

1，内存占用情况测试

方法一：利用adb shell ——> top 可以查看物理内存RSS和虚拟内存VSS

方法二： 进入 adb shell ——> dumpsys meminfo(pid或者包名称)

方法三：利用DDMS的heap和allocation tracker视图，该方法还可以分析内存使用情况

2.1.1 内存测试场景

一般情况下，Android的内存溢出主要有以下几种情况，每种情况在一些特定的场景下容易发生，测试时候可以重点关注：

(1)    对象本身占用内存大，例如Bitmap对象；

(2)    缓存机制不当引起；

(3)    生命周期不一致引起；

易出现内存溢出的场景：

a)    图片较多应用，注意不同界面切换、横竖屏、主题设置、读书阅读翻页、字体设置等频繁切换操作（会使Bitmap对象内存占用增加，而Bitmap对象在越高分辨率手机下生成的图片生成越大，占用内存越大，没有良好的缓存和释放机制，易出现内存溢出）

b)    长列表展示界面，上下来回频繁拖动 （例如，ListView不使用convertView进行缓存，在item越来越多的情况，就易造成OOM了）

c)    关注线程的生命周期，例如下载线程、同步线程等是否在被引用的activity退出后及时关闭；

d)    一些生命周期长的对象是否引用application Context, 而非引用activity Context；

e)    动画页面切换过程；

2.1.2 DDMS-内存测试工具

Android中自带一个强大的工具——DDMS工具包，它提供截屏，查看线程和堆的信息，同时也是一个内存测试工具。 windows->show view->other,输入ddms搜索即可打开DDMS的工作界面。

下面以读书客户端阅读界面频繁设置字体的场景为例，描述下测试的过程。

第一步，先用Heap（内存监测工具）监测应用进程使用内存情况：

1)    DDMS视图，手机连接，连接时确认手机处于“USB调试”模式；

2)    选中监测的应用，例如com.taobao.reader；

3)    点击Devices视图图标中的  (Update Heap)；

4)    点击Heap视图中的“Cause GC”按钮， Heap视图中便会显示当前应用的内存使用量的详细情况； 

 

图 1-2 heap 视图

5)    手机上开始不断设置字体，观察heap size值和data object“Total Size” 的变化 ; 正常Total Size值都会稳定在一个有限的范围内。

发现：在不断设置字体的过程中，data object“Total Size”值螺旋式上升（从1.580M->3.032M），且在手动触发点击cause gc后，其值只回落了一点，初步估计有内存泄露的风险。



 第二步，为具体定位到哪个类哪个方法，占用内存越来越大， 可使用DDMS另一个自带的内存分配跟踪工具Allocation tracker进行跟踪。

利用DDMS的heap和allocation tracker进行内存性能查看

allocation tracker貌似定位到的，也是哪个类的哪个方法，占用的内存较大。

 貌似还有个mat内存分析工具，这里没有用过，暂且略过。

2，响应时间测试

方法一：利用DDMS的method profiling-时间消耗测试工具

响应时间测试的场景主要是在：遍历查询、递归查询等（循环判断）。

Method Profiling（方法分析）是DDMS的一款工具，对于快速概览应用中时间的消耗分布非常有用。

 

图2-1 Method Profiling工作视图

以测试本地上传图书扫描为例，其扫描过程是递归查询扫描，具体操作步骤如下:

a)    devices视图，点击 开始方法分析；

b)    点击不同目录，开始扫描图书；

c)    点击 停止分析，自动打开分析结果；

d)    点incl cpu time%，将各方法时间消耗进行排序；

    Incl cpu time%: inclusive时间占总时间的百分比

    Excl cpu time%: 执行占总时间的白分比

    Calls+Recur Calls/Total: 调用和重复调用的次数

    Time/Call: 总的时间(ms)

发现LocalBookScanManager占用CPU时间过长，定位到代码：

/** 设置当前的文件夹目录 */

        public void resetFilePath(File file) {

            mFilepath = file;

            if (mFilepath == null || !mFilepath.exists()) {

                mFilepath = new File("/mnt");

            }

            setCurrentFolderPath(mFilepath.getAbsolutePath());

            refresh();

        }

手机里两个目录之间出现嵌套关系（阿里云低端手机出现），导致扫描过程中死循环，从而使扫描时间持续延长，而无法终止。

至于普通函数执行时间亦可通过上述方式测试，可针对时间最长者深入分析优化。

method pofiling测试函数响应时间

 

3，CPU性能测试

方法一：

1）adb shell 进入android的linux环境

2）使用top命令 有一个cpu的占比字段

 

方法二：读取日志文件

1）adb shell

2）ps找到系统的进程id

3）系统整体的cpu是在/proc/stat文件中，具体程序对应的cpu信息可以再/proc/$pid/stat中找到

 

4，流量测试

场景包括：

1）程序进入后台，不造成流量消耗。

2）需要触发大的流量消耗的时候，进行提醒告知

流量测试方法：

某个应用的流量数据保存在系统的/proc/uid_stat/$uid/tcp_rcv中

1）利用ps查看进程id，记为pid

2）进入目录/proc/$pid/；查看status文件中的uid值

3）进入/proc/uid_stat/$uid目录，查看tcp_rcv的值，可以利用每隔一秒钟打印日志的形式

方法一：

 

5，电量测试

每一个手机各个硬件单位时间的耗电量都记录在power_profile.xml文件中，这个文件可以利用apktool通过反编译得到

1. adb shell，ps查看要测试进程

2. /proc/pid

3. cat stat, (第14~17列相加=systime)

4. 各个场景下两次systime相减得到此段时间即为目

标进程占用的cpu时间(下⽂文记为app_total_time)



举例说明：

1. /sys/devices/system/cpu/cpu0/cpufreq/stats/time_instate

放了cpu在各个频段的占用时间，注意是整个系统占用时间

2. 将每个频段的占用时间计算出来，例如：频段a占了5s，频段b

占了6s，

那么，5/11*app_total_time=此进程在此频段占用的时间

3. 在power_profile中定义了在此频段的耗电，相乘既得电量

4. 最后把在各个频段的耗电相加就得到此进程的耗电。

配置文件计算耗电量