Android 性能测试及弱网测试要点

最新推荐文章于 2024-04-15 01:45:42 发布

喵瓶

最新推荐文章于 2024-04-15 01:45:42 发布

阅读量3.2k

点赞数 2

分类专栏：基础知识

原文链接：https://www.zybuluo.com/defias/note/592309

版权

基础知识专栏收录该内容

3 篇文章 0 订阅

订阅专栏

参考来源：https://www.zybuluo.com/defias/note/592309

1. 性能测试

Android性能测试分为两类：
1、一类为rom版本（系统）的性能测试

2、一类为应用app的性能测试

Android的app性能测试包括的测试项比如：
1、资源消耗
2、内存泄露
3、电量功耗
4、耗时
5、网络流量消耗
6、移动终端相关资源利用率
7、帧率
8、渲染等等....

工具：
（工具的原理都是基于调用android底层的一些api来获取到测试所用到的值）GT等

测试方法：
1、设计场景：手工或自动化场景
2、获取数据：可获取的数据包括：内存、cpu、电量功耗、hprof（内存泄露分析文件）、响应时间等等。。。。配合手工或自动化场景来获取数据（最好多取几次而且每次配合不同的设备看平均值）作为最后的对比分析
3、结果分析：拿到数据后分析哪些模块的数据异常再去Check code定位问题的原因

Android系统的几种场景状态：
1、空闲状态：指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲
2、中等规格和满规格状态：中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短

1.1 内存篇

背景知识：
C/C++申请的内存空间在native heap中，而java申请的内存空间则在dalvik heap中。这个是因为Android系统对dalvik的vmheapsize作了硬性限制，当java进程申请的java空间超过阈值时，就会抛出OOM异常（这个阈值可以是48M、24M、16M等，视机型而定），可以通过adb shell getprop | grep dalvik.vm.heapgrowthlimit查看此值。也就是说，程序发生OMM并不表示RAM不足，而是因为程序申请的java heap对象超过了dalvik vmheapgrowthlimit。也就是说，在RAM充足的情况下，也可能发生OOM。

adb shell getprop dalvik.vm.heapgrowthlimit

单个程序内存最大限制为384M

adb shell getprop dalvik.vm.heapsize

这样的设计似乎有些不合理，但是Google为什么这样做呢？这样设计的目的是为了让Android系统能同时让比较多的进程常驻内存，这样程序启动时就不用每次都重新加载到内存，能够给用户更快的响应。迫使每个应用程序使用较小的内存，移动设备非常有限的RAM就能使比较多的app常驻其中。但是有一些大型应用程序是无法忍受vmheapgrowthlimit的限制的

实际上dalvik.vm.heapgrowthlimit和dalvik.vm.heapsize都是java虚拟机的最大内存限制，应用如果不想在dalvikheap达到heapgrowthlimit限制的时候出现OOM，需要在Manifest中的application标签中声明android：largeHeap=“true”，声明后应用dalvik heap达到heapsize的时候才会出现OOM

1.1.1内存测试中的测试子项：

1）空闲状态下的应用内存消耗情况
2）中等规格状态下的应用内存消耗情况
3）满规格状态下的应用内存消耗情况
4）应用内存峰值情况
5）应用内存泄露情况
6）应用是否常驻内存
7）压力测试后的内存使用情况

1.1.2内存问题现象：

1）内存抖动
2）大内存对象被分配
3）内存不断增长
4）频繁GC

1.1.3内存数据获取：

1、各种linux命令（top、free、meminfo…）

1.1.4查看CPU信息

输入命令：top -m 10 -s cpu（-m显示最大数量，-s 按指定行排序）

参数含义：

PID : progress identification，应用程序ID

S : 进程的状态，其中S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值是负数

#THR : 程序当前所用的线程数

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

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

PCY : 前台(fg)和后台(bg)进程

UID : User　Identification，用户身份ID

Name : 应用程序名称

top -d 1 | grep "com.guideir.app " > /mnt/sdcard/performance.txt

android device monitor 使用需root手机后才能查看文件夹

adb shell dumpsys cpuinfo | find "com.guideir.app"

1.1.5查看应用启动时间

adb logcat -c && adb logcat -f /mnt/sdcard/up.txt -s ActivityManager

注意：从结果看没有访问权限，网上查阅教程需root手机

尝试修改文件权限但没成功

adb logcat -c && adb logcat -s ActivityManager -f > C:\Users\...\up.txt

adb logcat -c && adb logcat -f > C:\Users\...\up.txt -s ActivityManager

选项说明

-c 清屏

-f 指定运行结果输出文件，默认输出到标准设备（一般是显示器

-s 设置默认的过滤级别为Silent

tag 仅显示priority/tag

更多信息烦请参考 adb logcat -help

1.1.6查看电量信息

adb shell dumpsys battery

1.1.7电量测试方法

1.首先需下载historian.py脚本，下载地址：https://github.com/google/battery-historian

2.下载后解压，进入到D:\battery-historian-master\battery-historian-master\scripts目录下

3.在此目录下执行操作（在此打开CMD窗口）

4.执行步骤

1）首先要初始化batterystats数据

adb shell dumpsys batterystats –reset OK

2）上面的操作执行完毕后，拔掉手机，操作你的App，操作完成后，重新连接手机，执行下面的命令，收集Battery数据:

adb shell dumpsys batterystats > batterystats.txt OK

3）得到这些数据后，这个时候使用我们的battery-historian来生成我们可见HTML报告:

python historian.py batterystats.txt > batterystats.html

运行出错 historian.py文件异常

4）用google浏览器打开此文件即可

2、通过dumpsys
adb shell dumpsys meminfo [pakagename | pid]

adb shell dumpsys meminfo com.guideir.app

（1）Native/Dalvik 的 Heap 信息

它分别给出的是JNI层和Java层的内存分配情况，如果发现这个值一直增长，则代表程序可能出现了内存泄漏。

Dalvik Heap就是常说的堆内存，Dalvik Heap不能超过最大限制；超过单个程序内存的最大限制时，就可能出现OOM（内存溢出）。

（2）Total 的 PSS 信息

PSS- Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存），这个值就是你的应用真正占据的内存大小，通过这个信息，你可以轻松判别手机中哪些程序占内存比较大。

参数含义：

dalvik : dalvik使用的内存

native : native堆上的内存，指C\C++堆的内存（android 3.0以后bitmap就是放在这儿）

other : 除了dalvik和native的内存，包含C\C++非堆内存······

Pss : 该内存指将共享内存按比例分配到使用了共享内存的进程

allocated : 已使用的内存

free : 空闲的内存

private dirty : 非共享，又不能被换页出去的内存（比如linux系统中为了提高分配内存速度而缓冲的小对象，即使你的进程已经退出，该内存也不会被释放）

share dirty : 共享，但有不能被换页出去的内存

使用ctrl + c，退出adb命令行。

3、通过/system/xbin/procrank工具
adb shell procrank

前提条件：
1.手机已root，能够获取得到读写手机system目录权限；
2.下载procrank文件，下载链接：https://pan.baidu.com/s/1gfIcA7D，密码：r2fu；

说明：
VSS – Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS – Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS – Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS – Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存） USS 是针对某个进程开始有可疑内存泄露的情况，是一个程序启动了会产生的虚拟内存，一旦这个程序进程杀掉就会释放。不过USS需要通过root的手机。一般没有root的手机我们可以获取PSS。

而PSS通过如下命令来获取：adb shell dumpsys meminfo <Package Name>|grep TOTAL

4、通过android提供的procrank
1）首先去google获取procrank、procmem、libpagemap.so三个文件
2）然后push文件，执行 adb push procrank /system/xbin adb push procmem
/system/xbin adb push libpagemap.so /system/lib
3）赋权 adb shell chmod 6755 /system/xbin/procrank adb shell chmod 6755 /system/xbin/procmem adb shell chmod 6755 /system/lib/libpagemap.so ,
4）在开启工具记录 adb shell procrank |grep packagename >/address/procrank.txt

5、通过android提供的ActivityManager的getMemoryInfo(ActivityManager.MemoryInfo outInfo)（这个方法是写一个简单的app去监控的时候用到的，轻便简单）

private void GetMemory()

{

final ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);

ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo();

activityManager.getMemoryInfo(info);

Log.i(tag,"系统剩余内存:"+(info.availMem >> 10)+"k");

Log.i(tag,"系统是否处于低内存运行："+info.lowMemory);

Log.i(tag,"当系统剩余内存低于"+info.threshold+"时就看成低内存运行");

}

6、Memory Monitor （android studio的插件）【makedown？？？】

4. /proc/meminfo文件里列出的字段解释：

MemTotal: 所有可用RAM大小。

MemFree: LowFree与HighFree的总和，被系统留着未使用的内存。
Buffers: 用来给文件做缓冲大小。

Cached: 被高速缓冲存储器（cache memory）用的内存的大小（等于diskcache
minus SwapCache）。

SwapCached:被高速缓冲存储器（cachememory）用的交换空间的大小。已经被交换出来的内存，仍然被存放在swapfile中，用来在需要的时候很快的被替换而不需要再次打开I/O端口。
Active: 在活跃使用中的缓冲或高速缓冲存储器页面文件的大小，除非非常必要，否则不会被移作他用。

Inactive:在不经常使用中的缓冲或高速缓冲存储器页面文件的大小，可能被用于其他途径。

SwapTotal: 交换空间的总大小。

SwapFree:未被使用交换空间的大小。

Dirty: 等待被写回到磁盘的内存大小。

Writeback: 正在被写回到磁盘的内存大小。
AnonPages：未映射页的内存大小。

Mapped: 设备和文件等映射的大小。

Slab:内核数据结构缓存的大小，可以减少申请和释放内存带来的消耗。 SReclaimable:可收回Slab的大小。
SUnreclaim：不可收回Slab的大小（SUnreclaim+SReclaimable＝Slab）。
PageTables：管理内存分页页面的索引表的大小。 NFS_Unstable:不稳定页表的大小。

5. android检查内存泄露步骤：

1、运行Monkey进行压力测试：
adb shell monkey -p com.guideir.app --pct-touch 100 --ignore-crashes --throttle 1000 -s 100 -v -v 50

参数说明：

(1)-p:包名;

(2)-v:用于显示反馈信息级别，一共三级;

(3)-s:用于指定伪随机数生成器的seed值，如果seed相同，则两次Monkey测试所产生的事件序列也相同的;

(4)-throttle <毫秒>用于指定用户操作（即事件）间的时延，单位是毫秒;

(5) --ignore-crashes

用于指定当应用程序崩溃时（Force& Close错误），Monkey是否停止运行。如果使用此参数，即使应用程序崩溃，Monkey依然会发送事件，直到事件计数完成。

(6) --ignore-timeouts

用于指定当应用程序发生ANR（Application No Responding）错误时，Monkey是否停止运行。如果使用此参数，即使应用程序发生ANR错误，

Monkey依然会发送事件，直到事件计数完成。

(7) --ignore-security-exceptions

用于指定当应用程序发生许可错误时（如证书许可，网络许可等），Monkey是否停止运行。如果使用此参数，即使应用程序发生许可错误，

Monkey依然会发送事件，直到事件计数完成。

(8) --kill-process-after-error

用于指定当应用程序发生错误时，是否停止其运行。如果指定此参数，当应用程序发生错误时，应用程序停止运行并保持在当前状态（注意：应用程序仅是静止在发生错误时的状态，系统并不会结束该应用程序的进程）

(9) --monitor-native-crashes

用于指定是否监视并报告应用程序发生崩溃的本地代码。

(10) 参数： --pct-｛+事件类别｝｛+事件类别百分比｝

用于指定每种类别事件的数目百分比（在Monkey事件序列中，该类事件数目占总事件数目的百分比）

这些是我们进行操作时一般会用到的参数。执行过程中，在dos命令里日志显示只有一小部分，我们就需要在我们编写的命令行后再加上>log.txt就可以在我们保存adb路径中自动生成日志，方便我们进行查看。

比如：

Adb shell -p com.htc.xxx -v -v -v -s 2505000>log.txt

adb shell –p com.guideir.app –f > C:\Users\04495hjp\log.txt 验证OK

2、监控内存值，如果出现过大等递增异常则保存HPROF文件（hprof文件是Java 虚拟机的Heap快照）用于分析查看应用内存的命令：

adb shell dumpsys meminfo cn.microinvestment.weitou(进程名)

adb shell dumpsys meminfo com.guideir.app

如果发现内存过大，则保存HPROF文件：adb shell am dumpheap <进程名> <保存路径>

adb shell am dumpheap –n 23039 > C:\Users\04495hjp\dumpheap.hprof 验证OK

3、分析hprof文件
用工具MAT来查看，首先还要这个HPROF文件转换成MAT可读的文件
在Android SDK tool里面有个hprof-conv命令：
hprof-conv <原HPROF文件路径> <转换后的HPROF路径>
hprof-conv a.hprof b.hprof

使用MAT工具进行查看时报错

4、用MAT工具打开转换后的HPROF文件
一般选择Leak Suspects Report（通过SQL语句来查询对象有没有被释放掉，如果有多个相同的对象，则会存在内存泄露的问题）

1.2 CPU篇

1.2.1CPU测试中的测试子项：

1）空闲状态下的应用CPU消耗情况
2）中等规格状态下的应用CPU消耗情况
3）满规格状态下的应用CPU消耗情况
4）应用CPU峰值情况

1.2.2CPU数据获取：

1）adb shell dumpsys cpuinfo | grep packagename

adb shell dumpsys cpuinfo com.guideir.app

2)top命令
adb shell top -m 10 -s cpu #查看占用cpu最高的前10个程序（-t 显示进程名称，-s 按指定行排序，-n 在退出前刷新几次，-d 刷新间隔，-m 显示最大数量）
adb shell top | grep PackageName > /address/cpu.txt

adb shell top –m 10 –s cpu –d 10

1.3 流量篇

概念：
中等负荷：应用正常操作
高负荷：应用极限操作

1.3.1流量测试中的测试子项：

1、应用首次启动流量值
2、应用后台连续运行 2 小时的流量值
3、应用高负荷运行的流量峰值
4、应用中等负荷运行时的流量均值

1.3.2获取流量数据：

1、tcpdump＋wireshark

tcpdump是用来抓取数据非常方便，Wireshark则是用于分析抓取到的数据比较方便

博客地址：https://blog.csdn.net/gebitan505/article/details/19044857

2、/proc/net/目录下相关文件
cat /proc/net/dev 获取系统的流量信息

adb shell cat /proc/net/dev

最左边的表示接口的名字，Receive表示收包，Transmit表示发包；

bytes表示收发的字节数；

packets表示收发正确的包量；

errs表示收发错误的包量；

drop表示收发丢弃的包量；

adb shell cat /proc/net/snmp

通过访问该文件系统，可以对TCP和UDP进行监控：

平均每秒新增TCP连接数

通过/proc/net/snmp文件得到最近240秒内PassiveOpens的增量，除以240得到每秒的平均增量

机器的TCP连接数

通过/proc/net/snmp文件的CurrEstab得到TCP连接数

平均每秒的UDP接收数据报

通过/proc/net/snmp文件得到最近240秒内InDatagrams的增量，除以240得到平均每秒的UDP接收数据报。

平均每秒的UDP发送数据报

通过/proc/net/snmp文件得到最近240秒内OutDatagrams的增量，除以240得到平均每秒的UDP发送数据报。

3、查询应用的pid： adb shell ps | grep tataufo #如：31002
通过PID获取该应用的流量数据： adb shell cat /proc/31002/net/dev
（wlan0代表wifi上传下载量标识, 单位是字节可以/1024换算成KB, 打开手机飞行模式再关掉就可以将wlan0中的值初始化0）

adb shell cat /proc/29036/net/dev

4、查询应用的pid： adb shell ps | grep tataufo #如：31002

通过PID获取UID：adb shell cat /proc/29036/status

通过UID获取：adb shell cat /proc/net/xt_qtaguid/stats | grep 31002

adb shell cat /proc/net/xt_qtaguid/stats

5、通过adb shell dumpsys package来获取应用的uid信息，然后在未操作应用之前，通过查看：
adb shell cat /proc/uid_stat/uid/tcp_rcv
adb shell cat /proc/uid_stat/uid/tcp_snd
获取到应用的起始的接收及发送的流量，然后我们再操作应用，再次通过上述2条命令可以获取到应用的结束的接收及发送的流量，通过相减及得到应用的整体流量消耗

adb shell cat /proc/uid_stat/29036/tcp_rcv
adb shell cat /proc/uid_stat/29036/tcp_snd

6、Android代码：Android的TrafficStats类

1.4 功耗篇

功耗测试中的测试子项：
1、手机安装目标APK前后待机功耗无明显差异
2、常见使用场景中能够正常进入待机，待机电流在正常范围内
3、长时间连续使用应用无异常耗电现象

功耗测试方法：
方法一：软件
1、采用市场上提供的第三方工具，如金山电池管家之类的。
2、就是自写工具进行，这里一般会使用3种方法：
1）基于android提供的PowerManager.WakeLock来进行
2）比较复杂一点，功耗的计算=CPU消耗+Wake lock消耗+数据传输消耗+GPS消耗+Wi-Fi连接消耗
3）通过 adb shell dumpsys battery来获取

3、battery-historian（google开源工具）
方法二：硬件
一般使用万用表或者功耗仪安捷伦进行测试，使用功耗仪测试的时候，需要制作假电池来进行的，有些不能拔插电池的手机还需要焊接才能进行功耗测试

1.5 GPU篇（FPS）

1.5.1概念：

过度绘制：界面显示的activity套接了多层而导致
帧率：屏幕滑动帧速率
帧方差：屏幕滑动平滑度
**FPS：**Frames Per Second 每秒显示的帧数根据人眼的生理结构，帧率高于24时就被认为是连贯的。对于游戏画面30fps是最低能接受的，60fps逼真感，如果帧率高于屏幕刷新频率就是浪费。要达到30fps，每帧所占用的时间要小于33毫秒

1.5.2 GPU测试中的测试子项：

1、界面过度绘制
2、屏幕滑动帧速率
3、屏幕滑动平滑度

1.5.3过度绘制测试：（人工进行测试）

打开开发者选项中的显示GPU过度绘制（Debug GPU overdraw）
验收的标准:
1、不允许出现黑色像素
2、不允许存在4x过度绘制
3、不允许存在面积超过屏幕1/4区域的3x过度绘制（淡红色区域）

1.5.4屏幕滑动帧速率测试：

方法一：
1.手机端打开开发者选项中的启用跟踪后勾选Graphics和View
2.启动SDK工具Systrace，勾选被测应用，点击Systrace，在弹出的对话框中设置持续抓取时间，在trace taps下面勾选gfx及view选项
3.手工滑动界面可以通过节拍来进行滑动或者扫动，帧率数据会保存到默认路径下，默认名称为trace.html
4.将trace.html文件拷贝到linux系统下通过命令进行转换，生成trace.csv文件
grep 'postFramebuffer' trace.html | sed -e 's/.]\W//g' -e 's/:.*$//g' -e 's/.//g' > trace.csv
5.用excel打开文件计算得到帧率

方法二：
硬件的方法，打开高速相机，开启摄像模式，录制手工滑动或者扫动被测应用的视频，再通过人工或者程序数帧的方法对结果进行计算得到帧率

屏幕滑动平滑度的测试：
方法如同帧率测试，唯一的差异就是最后的结果计算公式的差异

1.5.5捕获app帧率（android流畅度FPS测试）：

1、打开手机开发者选项，勾选GPU显示配置文件（系统会记录保留每个界面最后128帧图像绘制的相关时间信息）

2、adb shell dumpsys gfxinfo com.xxx.xxx > zinfo.txt

adb shell dumpsys gfxinfo com.guideir.app > zinfo.txt

运行结果：

Applications Graphics Acceleration Info:

Uptime: 43238608 Realtime: 96878999

** Graphics info for pid 735 [com.guideir.app] **

Stats since: 1255527228453ns

Total frames rendered: 3300

Janky frames: 47 (1.42%)

50th percentile: 12ms

90th percentile: 13ms

95th percentile: 14ms

99th percentile: 20ms

Number Missed Vsync: 11

Number High input latency: 0

Number Slow UI thread: 30

Number Slow bitmap uploads: 15

Number Slow issue draw commands: 29

HISTOGRAM: 5ms=55 6ms=55 7ms=58 8ms=102 9ms=122 10ms=463 11ms=618 12ms=573 13ms=1020 14ms=182 15ms=3 16ms=4 17ms=3 18ms=4 19ms=5 20ms=1 21ms=2 22ms=0 23ms=2 24ms=0 25ms=1 26ms=0 27ms=0 28ms=1 29ms=2 30ms=0 31ms=1 32ms=1 34ms=1 36ms=0 38ms=0 40ms=1 42ms=1 44ms=0 46ms=0 48ms=0 53ms=4 57ms=1 61ms=1 65ms=2 69ms=3 73ms=0 77ms=1 81ms=0 85ms=1 89ms=0 93ms=1 97ms=0 101ms=0 105ms=1 109ms=0 113ms=0 117ms=0 121ms=0 125ms=0 129ms=0 133ms=1 150ms=2 200ms=0 250ms=0 300ms=0 350ms=1 400ms=0 450ms=0 500ms=0 550ms=0 600ms=0 650ms=0 700ms=0 750ms=0 800ms=0 850ms=0 900ms=0 950ms=0 1000ms=0 1050ms=0 1100ms=0 1150ms=0 1200ms=0 1250ms=0 1300ms=0 1350ms=0 1400ms=0 1450ms=0 1500ms=0 1550ms=0 1600ms=0 1650ms=0 1700ms=0 1750ms=0 1800ms=0 1850ms=0 1900ms=0 1950ms=0 2000ms=0 2050ms=0 2100ms=0 2150ms=0 2200ms=0 2250ms=0 2300ms=0 2350ms=0 2400ms=0 2450ms=0 2500ms=0 2550ms=0 2600ms=0 2650ms=0 2700ms=0 2750ms=0 2800ms=0 2850ms=0 2900ms=0 2950ms=0 3000ms=0 3050ms=0 3100ms=0 3150ms=0 3200ms=0 3250ms=0 3300ms=0 3350ms=0 3400ms=0 3450ms=0 3500ms=0 3550ms=0 3600ms=0 3650ms=0 3700ms=0 3750ms=0 3800ms=0 3850ms=0 3900ms=0 3950ms=0 4000ms=0 4050ms=0 4100ms=0 4150ms=0 4200ms=0 4250ms=0 4300ms=0 4350ms=0 4400ms=0 4450ms=0 4500ms=0 4550ms=0 4600ms=0 4650ms=0 4700ms=0 4750ms=0 4800ms=0 4850ms=0 4900ms=0 4950ms=0

Caches:

Current memory usage / total memory usage (bytes):

TextureCache 2859152 / 75497472

LayerCache 0 / 50331648 (numLayers = 0)

Layers total 0 (numLayers = 0)

RenderBufferCache 0 / 8388608

GradientCache 0 / 1048576

PathCache 0 / 16777216

TessellationCache 4008 / 1048576

TextDropShadowCache 0 / 6291456

PatchCache 0 / 0

FontRenderer A8 1048576 / 1048576

FontRenderer RGBA 0 / 0

FontRenderer total 1048576 / 1048576

Other:

FboCache 0 / 0

Total memory usage:

3911736 bytes, 3.73 MB

Pipeline=FrameBuilder

Profile data in ms:

com.guideir.app/com.guideir.app.home.activity.MainActivity/android.view.ViewRootImpl@4fa2c09 (visibility=8)

com.guideir.app/com.guideir.app.home.activity.GuideirActivity/android.view.ViewRootImpl@fe5ae0e (visibility=0)

View hierarchy:

com.guideir.app/com.guideir.app.home.activity.MainActivity/android.view.ViewRootImpl@4fa2c09

19 views, 13.51 kB of display lists

com.guideir.app/com.guideir.app.home.activity.GuideirActivity/android.view.ViewRootImpl@fe5ae0e

38 views, 27.02 kB of display lists

Total ViewRootImpl: 2

Total Views: 57

Total DisplayList: 40.52 kB

————————————————————————————————————

3、结果数据分析
Profile data in ms部分：
Draw：创建显示列表的时间（DisplayList），所有View对象OnDraw方法占用的时间
Process： Android 2D渲染引擎执行显示列表所花的时间，View越多时间越长
Execute：将一帧图像交给合成器（compsitor）的时间，较小

其他工具：
GameBench 测试android app的FPS工具
Gfxinfo 查看app绘制性能工具

1.6 响应时间篇

理解：
1）从单击事件触发到容器启动NativeAPP消耗的时间（埋点）
2）NativeAPP完整启动消耗的时间（可以通过system.log获取）
3）Native调用RPC请求方法的延迟时间（埋点）
4）RPC请求发出去过程中的具体数据（req_size req_header req_time等，通过埋点获取）
5）RPC请求返回的具体数据（res_size res_header res_time等，通过埋点获取）
6）本地解析返回数据所消耗的时间（埋点或者TraceView工具可获取）
7）界面渲染的时间（可以通过慢速摄像机或者埋点获取）

android app启动时间测试
（安卓Activity启动过程性能剖视: http://www.rudy-yuan.net/archives/59/）

应用的启动时间的测试，分为三类：
1）首次启动 --应用首次启动所花费的时间
2）非首次启动 --应用非首次启动所花费的时间
3）应用界面切换--应用界面内切换所花费的时间

应用启动时间数据获取：
1、adb logcat > /address/logcat.txt #所有activity打印的日志
find “Displayed” /address/logcat.txt > /newaddress/fl.txt #通过日志过滤关键字Displayed来过滤
find “ActivityName” /newaddress/fl.txt > /newaddress/last.txt #通过activity名来过滤获取所测应用
通过计算activity最后剩余的时间之和即可
2、硬件测试，使用高速相机或者手机采用录像的方法把应用启动过程给录制下来，然后通过人工数帧或者程序数帧的方式计算启动时间

2 弱网测试

测试方法：
1、使用真实的SIM卡、运营商网络来进行测试（移动无线测试中存在一些特别的BUG必须在特定的真实的运营商网络下才会发现）
2、通过代理的方式模拟弱网环境进行测试（charles 硬延迟）
3、连接模拟弱网的热点进行测试

热点模拟方法：
1）通过设置iPhone的开发者模式之后共享热点（硬延迟）
2）FaceBook开源的ATC（可使用树莓派来搭建ACT环境）

用户体验需要做的：
1）在应用中统一弱网加载的界面样式、动画效果、菊花icon等
2）统一网络错误、服务端错误、超时等展现给用户的界面和提示语句
3）定义清楚在每个中间过程是的用户交互行为

喵瓶

关注

2
点赞
踩
12

收藏

觉得还不错? 一键收藏
0
评论
Android 性能测试及弱网测试要点

1. 性能测试Android性能测试分为两类：1、一类为rom版本（系统）的性能测试2、一类为应用app的性能测试Android的app性能测试包括的测试项比如：1、资源消耗2、内存泄露3、电量功耗4、耗时5、网络流量消耗6、移动终端相关资源利用率7、帧率8、渲染等等....工具：（工具的原理都是基于调用android底层的一些api来获取到测试所用到的值...
复制链接

扫一扫