Android 车载场景性能测试：CPU 测试方法大揭秘
一、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命令的常用选项
[*]b：批处理模式，适用于将 输出重定向到文件。
top -b - n 1> top_output .txt
[*]-d 秒数 >：设置更新的间隔时间（秒）。
top-d 5
3.-n <次数>:指定top 更新的次数后退出
top-n10
4.-p <;PID>: 仅显示指定的进程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
[*]- i:忽略闲置和僵尸进程
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以批处理模式运行。
-d1每秒更新一次信息。
-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文件，可以非常方便快速的定位到有问题的函数
:victory:感谢分享
页:
[1]
