基于Android平台车载场景下性能测试-CPU测试方法介绍

基于Android平台车载场景下性能测试-CPU测试方法介绍

引用

CSDN

1.

https://blog.csdn.net/deerxiaoluaa/article/details/143332620

随着Android系统在车载场景中的广泛应用，性能测试变得尤为重要。本文将详细介绍在Android车载平台上进行CPU性能测试的具体方法，包括使用top命令监控系统资源和使用Simpleperf工具定位性能瓶颈。

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测试：主要是监测应用是否有内存泄漏和内存溢出；
• 响应时间测试：主要是监测应用的冷热启动时间。

CPU测试方法

由于Android系统是基于Linux内核开发出来的，所以很多Linux上的命令，在Android中也可以使用；在Linux中，top命令用于实时监视系统的进程和资源使用情况。它有很多选项和命令，可以帮助你查看和管理系统性能。以下是top命令的所有选项和常用命令的详细解释。

top命令的常用选项

• -b：批处理模式，适用于将top输出重定向到文件。
• -d<秒数>：设置更新的间隔时间（秒）。
• -n<次数>：指定top更新的次数后退出。
• -p<PID>：仅显示指定的进程ID。
• -H：显示线程而非进程。
• -u<用户名>：仅显示指定用户的进程。
• -U<UID>：仅显示指定UID的进程。
• -s：安全模式，防止在top界面中接受用户输入。
• -i：忽略闲置和僵尸进程。
• -c：显示完整的命令行，而不是只显示程序名称。
• -e<时间>：设置显示更新时间的格式（例如秒、毫秒）。

在top界面中常用的交互命令

• h或?：显示帮助信息。
• q：退出top。
• P：按CPU使用率排序。
• M：按内存使用量排序。
• T：按运行时间排序。
• R：反转排序顺序。
• k：杀死进程。输入进程ID后，确认要发送的信号（通常是SIGTERM）。
• r：重新调整进程的优先级（更改其nice值）。
• u：显示指定用户的进程。
• d：更改更新间隔时间。
• 1：显示每个CPU核心的使用情况（多核系统下）。

top是一个功能强大的工具，通过掌握其各种选项和命令，可以更有效地监控和管理Linux系统的性能。

常用的命令模式

查看某个应用程序的占用资源情况

top -H -b -d 1 -n 100 -p $(pidof com.example.app)

这个命令用于实时监控系统进程的状态。具体来说：

• -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-work-loop 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-utility-worker com.example.app
18901 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utility-worker com.example.app
18900 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utility-worker com.example.app
18899 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utility-worker com.example.app
18898 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utility-worker com.example.app
18897 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utility-worker 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-cmar-backend com.example.app
18904 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utility-worker com.example.app
18903 u0_a100 10 -10 6.7G 132M 70M S 0.0 1.7 0:00.00 mali-utility-worker com.example.app
18865 u0_a100 30 10 6.7G 132M 70M S 0.0 1.7 0:00.02 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 FinalizerWatchdogDaemon 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命令拉取对应的文件夹，将里面的输出的结果通过python进行数值分析，就可以得到对应的性能占用表现，建议通过折现图的方式进行输出，可以更加直观的看到cpu的表现。

利用Simpleperf定位CPU耗时函数

在做性能测试的过程中，我们不仅仅要做到发现问题，更重要的是解决问题。Simpleperf就是一款帮助开发定位和解决问题的利器。

Simpleperf是Android平台的一个本地层性能分析工具，该工具可帮助找到使用Java、C/C++和Kotlin编写的应用的热点函数(所谓热点，也就是占用应用大部分执行时间的部分原生代码)。

详细的介绍大家可以参考官网：

Simpleperf
(googlesource.com)
Simpleperf|Android NDK|Android Developers

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文件及所有被剖析进程用到的共享库，并输出一份报告，展示时间消耗在了哪里。

实战

通过如下命令抓取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文件，可以非常方便快速的定位到有问题的函数。