TA的每日心情 | 无聊 3 天前 |
---|
签到天数: 1050 天 连续签到: 1 天 [LV.10]测试总司令
|
一、Android系统背景介绍
Android系统是一种基于Linux内核的自由及开源的操作系统,广泛应用于智能手机,平板,TV, 车载等场景,由Google和开放手机联盟领导及开发。Android操作系统最初由安迪·鲁宾开发,主 要支持手机。
2005年8月由Google收购注资。2007年11月,Google与84家硬件制造商、软件开 发商及电信营运商组建开放手机联盟共同研发改良Android系统。随后Google以Apache开源许可 证的授权方式,发布了Android的源代码。第一部Android智能手机发布于2008年10月。Android 逐渐扩展到平板电脑及其他领域上,如电视、数码相机、游戏机、智能手表等。2011年第一季 度,Android在全球的市场份额首次超过塞班系统,跃居全球第一。 2013年的第四季度, Android平台手机的全球市场份额已经达到78.1%。2013年09月24日谷歌开发的操作系统Android 在迎来了5岁生日,全世界采用这款系统的设备数量已经达到10亿台。
二 、车载场景介绍
Android在车载场景下的使用相对于手机而言具有如下差异点:
- 车载平台普遍具有大屏的特点,所以UI风格上和手机有显著的差异
- 车载平台一般很少会重启,因此需要车载平台上的应用保持长时间稳定运行,这对稳定性测 试要求非常高
- 车载平台需要对接语音,支持非常多的语音指令,可见即可说等,因此整体的功能复杂度较 高,对开发者和测试的要求也较高
- 车载平台的测试周期比较长,手机上一般做功能测试即可,但是在车载上,既有功能测试, 也有跨域测试,继承测试,部分应用甚至要路测等。
- 车载平台一般会有自己的平台特性,例如方控功能,STR模式等,这在手机平台上都是没有 的
因此针对于车载平台,我们需要总结出一套行之有效的测试方法论。
三、性能测试内容
传统的性能测试主要包括以下几个方面
- CPU测试:主要是监测应用的CPU使用是否会超标
- MEM测试:主要是监测应用是否有内存泄漏和内存溢出
- 响应时间测试:主要是监测应用的冷热启动时间
3.1 CPU测试方法
由于Android系统是基于Linux内核开发出来的,所以很多Linux上的命令,在Android中也可以使 用
在 Linux 中,top命令用于实时监视系统的进程和资源使用情况。它有很多选项和命令,可以帮 助你查看和管理系统性能。以下是top命令的所有选项和常用命令的详细解释:
3.2 top命令的常用选项
top -b - n 1> top_output .txt
top -d 5
3.-n <次数>:指定top 更新的次数后退出
top -n 10
4.-p <ID>: 仅显示指定的进程ID
top -p 1234
5.-H :显示线程而非进程。
top -H
6.-u <用户名>:仅显示指定用户的进程
top -U 1000
7.-U<uid>:仅显示指定 UID 的进程
top -U 1000
8.-s:安全模式,防止在 top 界面中接受用户输入。
top -s
top -c
10.-c :显示完整的命令行,而不是只显示程序名称。
top -c
11.- e<时间 >:设置显示更新时间的格式(例如秒、毫秒)。
top -e ms
3.3 在top界面中常用的交互命令
h或 ?:显示帮助信息。
q:退出top 。
P:按 CPU 使用率排序。
M:按内存使用量排序。
T:按运行时间排序。
R:反转排序顺序。
k:杀死进程。输入进程 ID 后,确认要发送的信号(通常是 SIGTERM)。
r:重新调整进程的优先级(更改其nice值)。
u:显示指定用户的进程。
d:更改更新间隔时间。
1:显示每个 CPU 核心的使用情况(多核系统下)。
top是一个功能强大的工具,通过掌握其各种选项和命令,可以更有效地监控和管理 Linux 系统 的性能。
常用的命令模式
查看某个应用程序的占用资源情况
- <font face="微软雅黑" size="3" color="#000000">top -H -b -d 1 -n 100 -p 'pidof com,example.app'</font>
复制代码
这个命令用于实时监控系统进程的状态。具体来说:
-H显示线程信息。
-b以批处理模式运行。
-d 1每秒更新一次信息。
-n 100 总共更新100次。
p指定进程ID或进程名,com . example .app 是你要监控的应用程序。
输出的结果如下:
- Threads: 31 total, 0 running, 31 sleeping, 0 stopped, 0 zombie
- Mem: 7710420K total, 7530984K used, 179436K free, 2972K buffers
- Swap: 4194300K total, 4017240K used, 177060K free, 1793980K cached
- 800%cpu 9%user 0%nice 18%sys 767%idle 0%iow 4%irq 2%sirq 0%host
- TID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ THREAD
- PROCESS
- 19445 u0_a100 18 -2 6.7G 132M 70M S 0.0 1.7 0:00.00 queued-workloo com.example.app
- 18913 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-compiler
- com.example.app
- 18908 u0_a100 0 -20 6.7G 132M 70M S 0.0 1.7 0:00.00 hwuiTask1
- com.example.app
- 18907 u0_a100 0 -20 6.7G 132M 70M S 0.0 1.7 0:00.00 hwuiTask0
- com.example.app
- 18902 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utilitywo com.example.app
- 18901 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utilitywo com.example.app
- 18900 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utilitywo com.example.app
- 18899 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utilitywo com.example.app
- 18898 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utilitywo com.example.app
- 18897 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utilitywo com.example.app
- 18893 u0_a100 20 0 6.7G 132M 70M S 0.0 1.7 0:00.00 Binder:18693_5
- com.example.app
- 18896 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-mem-purge
- com.example.app
- 18905 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-cmarbacke com.example.app
- 18904 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utilitywo com.example.app
- 18903 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utilitywo com.example.app
- 18865 u0_a100 30 10 6.7G 132M 70M S 0.0 1.7 0:00.00 AsyncTask #1
- com.example.app
- 18844 u0_a100 16 -4 6.7G 132M 70M S 0.0 1.7 0:00.03 RenderThread
- com.example.app
- 18808 u0_a100 29 9 6.7G 132M 70M S 0.0 1.7 0:00.02 Profile Saver
- com.example.app
- 18750 u0_a100 20 0 6.7G 132M 70M S 0.0 1.7 0:00.00 Binder:18693_4
- com.example.app
- 18740 u0_a100 20 0 6.7G 132M 70M S 0.0 1.7 0:00.00 Binder:18693_3
- com.example.app
- 18718 u0_a100 20 0 6.7G 132M 70M S 0.0 1.7 0:00.00 Binder:18693_2
- com.example.app
- 18717 u0_a100 20 0 6.7G 132M 70M S 0.0 1.7 0:00.01 Binder:18693_1
- com.example.app
- 18716 u0_a100 24 4 6.7G 132M 70M S 0.0 1.7 0:00.00
- FinalizerWatchd com.example.app
- 18715 u0_a100 24 4 6.7G 132M 70M S 0.0 1.7 0:00.00
- FinalizerDaemon com.example.app
复制代码
如果我们重点关注的是CPU专项,那么我们需要关注第九列[%CPU]这一项,在业务测试的过程 中,可以通过这个命令不断的抓取这个参数值,保存到车机的某个特定文件夹下,然后通过adb
命令拉取对应的文件夹,将里面的输出的结果通过pytho进行数值分析,就可以得到对应的性能 占用表现,建议通过折现图的方式进行输出,可以更加直观的看到cpu的表现。
3.4 利用Simpleperf定位CPU耗时函数
在做性能测试的过程中,我们不仅仅要做到发现问题,更重要的是解决问题。Simpleperf就是一 款帮助开发定位和解决问题的利器。Simpleperf是Android平台的一个本地层性能分析工具,该工 具可帮助找到使用Java、C/C++和Kotlin编写的应用的热点函数(所谓热点,也就是占用应用大部 分执行时间的部分原生代码)。详细的介绍大家可以参考官网:Simpleperf (googlesource.com)Simpleperf | Android NDK | Android Developers
3.5 Simpleperf的工作原理
现代的CPU具有一个硬件组件,称为性能监控单元(PMU)。PMU具有一些硬件计数器,计数一些 诸如经历了多少次CPU周期,执行了多少条指令,或发生了多少次缓存未命中等的事件。Linux 内核将这些硬件计数器包装到硬件perf事件(hardware perf events)中。此外,Linux内核还提供了 独立于硬件的软件事件和跟踪点事件。Linux内核通过perf_event_open系统调用将这些都暴露给 了用户空间。
这正是simpleperf所使用的机制。
Simpleperf具有三个主要的功能:stat、record和report。
Stat命令给出了在一个时间段内被分析的进程中发生了多少事件的摘要。以下是它的工作原理:
给定用户选项,simpleperf通过对linux内核进行系统调用来启用分析;
Linux 内核在调度到被分析进程时启用计数器;
分析之后,simpleperf从内核读取计数器,并报告计数器摘要。 Record命令在一段时间内记录剖析进程的样本。它的工作原理如下:
给定用户选项,simpleperf通过对linux内核进行系统调用来启用分析;
Simpleperf在simpleperf和linux内核之间创建映射缓冲区;
Linux内核在调度到被分析进程时启用计数器;
每次给定数量的事件发生时,linux内核将样本转储到映射缓冲区;
Simpleperf从映射缓冲区读取样本并生成perf.data。
Report命令读取perf.data文件及所有被剖析进程用到的共享库,并输出一份报告,展示时 间消耗在了哪里。
3.6 实战
通过如下命令抓取simpleperf
- simpleperf record -e task-clock -f 3000 --call-graph fp -o
- /sdcard/example_simpleperf.data --duration 100 -p `pidof com.example.app`
复制代码
运行完以后,将生成的文件/sdcard/example_simpleperf.data通过adb命令拉取到本地,然后通 过gecko_profile_generator工具将其格式转换为Firefox Profiler可以识别的格式
转换命令如下:
- python .\gecko_profile_generator.py -i .\example_simpleperf.data >
- data.json.gz
复制代码
然后将data.json.gz文件拖拽到Firefox Profiler, 便可以查看如下分析结果
开发通过对应的data文件,可以非常方便快速的定位到有问题的函数
|
|