Android 应用性能评估
Android* 应用性能评估
| 2011年10月09日 08:00 | |
作者：Tuan H. Bui
要监控运行在 Android* 上的应用的性能，第一项任务是在应用运行相关工作负载的同时，运行性能监控实用程序。例如，我们希望监控视频播放应用的性能，以了解该应用没有按照既定帧速率运行的原因。由于在上述情况下，我们要监控的应用 – 视频播放器运行在前台，因此我们需要寻找其它方法来监控视频播放器运行时的性能。为了达到这个目的，我们采取的办法是：编写一个持续在后台运行的 Android* 服务，以将性能数据记录到一个随后可查看的文件中。更简单的方法是使用 Android* 调试桥 (adb) 实用程序。通过 USB 电缆或 TCPIP 端口，Android* ADB 可为 Android* 操作系统提供一个调试 shell。通过 TCPIP 端口启用 adb 调试的步骤如下：
以下是 Android* 媒体播放器在 Motorola Xoom*1 平板电脑上播放 720p H264 视频时，以 5 秒的时间间隔捕获的两个 /proc/stat 样本。为便于阅读，我们将数据导入到一个电子表格中。
/proc/stat 中包含大量数据。其中最相关的信息是报告 CPU 活动总数的第一行。之后以‘cpuN’开头的每行报告该特定 CPU 的活动。我们发现这里的示例设备具有两个处理器。每个字段的含义解释如下：
1* 文中涉及的其它名称及商标属于各自所有者资产。
时间单位在 USER_HZ 中定义，通常为百分之一秒。系统重启后，这些统计数据的数值将逐个进行累加。要获取每个间隔时段的性能数据，您只需计算该时段开始时捕获的数据与该时段结束时捕获的数据的差异即可。
对于运行时间相当长的工作负载（如视频播放），我们可制作一张时间表，用以显示该工作负载随时间推移的 CPU 利用率。通过研究以上时间表，我们可以发现该工作负载耗费处理器资源的不同阶段。图 1 显示了一个图像型工作负载的时间表。我们注意到该工作负载的最大 CPU 利用率仅为 50%。这表明该工作负载仅能够利用一个 CPU。如果有必要加快该工作负载的速度，可能值得想办法利用另一个 CPU。
图 1 - An3DBenchXL 的 CPU 利用率
CPU 利用率并不能代表性能的全部。现代处理器通常能够在几种不同的频率（称作 Pstate）下运行。对于移动设备，操作系统可以改变处理器的运行频率，以最大限度地降低功耗和延长电池的使用时间。
图 2 显示了同一台笔记本电脑在播放两段相同的视频剪辑（编码分别为 720p H264 和 360p H264）时的 CPU 利用率和平均处理器运行频率。数据显示，相较于 CPU利用率可能显示出的差异，播放 720p H264 视频实际耗费的 CPU 资源更多。解码 720p H264 视频不仅需要大约 4 倍的 CPU 利用率，而且处理器的运行频率也比在解码另一个视频时要高 2.4 倍。
图 2 – 视频播放性能
Android* 在 /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state 文件中报告其处理器运行频率或 pstate。以下脚本进行了修改，现包含各种处理器 pstate 数据。
从 Motorola Xoom 的处理器 pstate 信息中返回的数据如下所示：
每个数据对代表一种 pstate 频率（单位为 KHz）及系统启动后该状态下所耗费的时间 （单位为百分之一秒）。每个处理器提供的 pstate 数各不相同。本例中，用于驱动 Motorola Xoom 的 NVIDIA Tegra2 处理器提供了 8 种可能的 pstate，频率从 216 MHz 到 1 GHz。
运用同计算 CPU 利用率相同的技巧，我们可计算出在取样间隔一定的情况下，处理器在每种 pstate 下所耗费的时间百分比。通过计算 pstate 频率的加权总和及该状态下所耗费时间的百分比，我们还可以得出相同间隔的平均频率。获得的数据如图 1 所示。
* 文中涉及的其他名称及商标属于各自所有者资产
概述
要优化应用以提供最佳用户体验，了解该应用对于某个特定平台的性能需求十分重要。在 Linux* 操作系统上，我们可使用 vmstat 来监控应用的多个性能要素，如内存占用空间、CPU 和 IO 需求等。Windows* 任务管理器为 Windows* 操作系统提供了类似的功能。本文中，我们将探讨如何为 Android* 操作系统获取相似的性能数据。讨论
Android* 本质上是一种 Linux* 操作系统，因此可提供类似的性能数据。由于手机/平板电脑的使用模式仅允许前台一次运行一个应用，因此获得这些数据有些困难。要监控运行在 Android* 上的应用的性能，第一项任务是在应用运行相关工作负载的同时，运行性能监控实用程序。例如，我们希望监控视频播放应用的性能，以了解该应用没有按照既定帧速率运行的原因。由于在上述情况下，我们要监控的应用 – 视频播放器运行在前台，因此我们需要寻找其它方法来监控视频播放器运行时的性能。为了达到这个目的，我们采取的办法是：编写一个持续在后台运行的 Android* 服务，以将性能数据记录到一个随后可查看的文件中。更简单的方法是使用 Android* 调试桥 (adb) 实用程序。通过 USB 电缆或 TCPIP 端口，Android* ADB 可为 Android* 操作系统提供一个调试 shell。通过 TCPIP 端口启用 adb 调试的步骤如下：
- 在 Android* 控制面板中启用 USB 调试。
- 通过 USB 电缆将设备与主机相连。如果您使用的是 Windows* 主机，则可能需要从设备制造商处获取 USB 设备驱动程序。如果使用的是 Linux* 主机，则通常无需特殊的设备驱动程序。
- 通过发出‘adb devices’命令，确保主机能发现设备。该命令应当返回一串连接到主机的设备。
- 通过发出‘adb tcpip 5555’命令启用 TCPIP 调试。该命令指示 adb 重启并侦听端口 5555，以获取 adb 连接消息。
- 通过发出‘adb
’命令断开 USB 电缆连接和重新连接到设备。
while :
do
echo Date: `date +”%Y-%m-%d %H:%M:%S”`
cat /proc/stat >> /data/local/tmp/myvmstat.out
sleep 5
done
以下是 Android* 媒体播放器在 Motorola Xoom*1 平板电脑上播放 720p H264 视频时，以 5 秒的时间间隔捕获的两个 /proc/stat 样本。为便于阅读，我们将数据导入到一个电子表格中。
/proc/stat 中包含大量数据。其中最相关的信息是报告 CPU 活动总数的第一行。之后以‘cpuN’开头的每行报告该特定 CPU 的活动。我们发现这里的示例设备具有两个处理器。每个字段的含义解释如下：
1* 文中涉及的其它名称及商标属于各自所有者资产。
时间单位在 USER_HZ 中定义，通常为百分之一秒。系统重启后，这些统计数据的数值将逐个进行累加。要获取每个间隔时段的性能数据，您只需计算该时段开始时捕获的数据与该时段结束时捕获的数据的差异即可。
User（用户）：以‘user（用户）’模式执行进程所耗费的时间
Nice（优先）：以‘niced（优先）’模式执行进程所耗费的时间。Niced（优先）进程指的是以默认优先级之外的优先级运行的进程。
System（系统）：以‘kernel（内核）’或‘supervisory（监管）’模式执行进程所耗费的时间。
Idle（闲置）：执行闲置进程的时间。此时不存在运行的进程。
Iowait：等待 IO（输入输出）完成的时间
Irq：处理中断的时间
Softirq：处理 softIRQ 的时间
Steal Time、Guest Time、Guest Nice Time：在虚拟客户操作系统中耗费的时间。在 Android* 中，这些值通常为零
/proc/stats 中报告的其余数据描述如下：
Nice（优先）：以‘niced（优先）’模式执行进程所耗费的时间。Niced（优先）进程指的是以默认优先级之外的优先级运行的进程。
System（系统）：以‘kernel（内核）’或‘supervisory（监管）’模式执行进程所耗费的时间。
Idle（闲置）：执行闲置进程的时间。此时不存在运行的进程。
Iowait：等待 IO（输入输出）完成的时间
Irq：处理中断的时间
Softirq：处理 softIRQ 的时间
Steal Time、Guest Time、Guest Nice Time：在虚拟客户操作系统中耗费的时间。在 Android* 中，这些值通常为零
Intr：系统出现的中断的次数。标志‘intr’之后的第一列表示系统在重启后出现的中断的总次数。后续各列的值表示出现的中断次数，使用从 interrupt 0 开始的列编号进行表示。
Ctxt：系统重启后发生的环境切换次数。
Btime：系统启动时间，使用自格林威治标准时间 1970 年 1 月 1 日之后发生的偏移量表示（单位：秒）。
进程：系统在启动后创建的进程数
Procs running（运行的进程）：运行的进程数
Procs blocked（被阻止的进程）：被阻止以等待 IO 完成的进程。
Softirq：已处理的 softirq 的总数。SoftIRQ 是对时间要求不严格的软件中断。
以上两个数据样本之间的差异如下表所示。Sum（总数）列显示的是不同任务所耗费的总时间。CPU Util 列显示的是非闲置任务的总数。每个 CPU 下的一行以占总时间百分比的形式显示了相同的数据。注意各种任务所耗费的总时间加起来应为 5 秒。由于本系统包含两个处理器，因此每个样本的总 CPU 时间为 2x5 = 10 秒。
Ctxt：系统重启后发生的环境切换次数。
Btime：系统启动时间，使用自格林威治标准时间 1970 年 1 月 1 日之后发生的偏移量表示（单位：秒）。
进程：系统在启动后创建的进程数
Procs running（运行的进程）：运行的进程数
Procs blocked（被阻止的进程）：被阻止以等待 IO 完成的进程。
Softirq：已处理的 softirq 的总数。SoftIRQ 是对时间要求不严格的软件中断。
对于运行时间相当长的工作负载（如视频播放），我们可制作一张时间表，用以显示该工作负载随时间推移的 CPU 利用率。通过研究以上时间表，我们可以发现该工作负载耗费处理器资源的不同阶段。图 1 显示了一个图像型工作负载的时间表。我们注意到该工作负载的最大 CPU 利用率仅为 50%。这表明该工作负载仅能够利用一个 CPU。如果有必要加快该工作负载的速度，可能值得想办法利用另一个 CPU。
图 1 - An3DBenchXL 的 CPU 利用率
CPU 利用率并不能代表性能的全部。现代处理器通常能够在几种不同的频率（称作 Pstate）下运行。对于移动设备，操作系统可以改变处理器的运行频率，以最大限度地降低功耗和延长电池的使用时间。
图 2 显示了同一台笔记本电脑在播放两段相同的视频剪辑（编码分别为 720p H264 和 360p H264）时的 CPU 利用率和平均处理器运行频率。数据显示，相较于 CPU利用率可能显示出的差异，播放 720p H264 视频实际耗费的 CPU 资源更多。解码 720p H264 视频不仅需要大约 4 倍的 CPU 利用率，而且处理器的运行频率也比在解码另一个视频时要高 2.4 倍。
图 2 – 视频播放性能
Android* 在 /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state 文件中报告其处理器运行频率或 pstate。以下脚本进行了修改，现包含各种处理器 pstate 数据。
while :
do
echo Date: `date +”%Y-%m-%d %H:%M:%S”`
cat /proc/stat >> /data/local/tmp/myvmstat.out
echo CPU0 Pstate Residency
cat /sys/devices/cpu/cpu0/cpufreq/stats/time_in_state
echo CPU1 Pstate Residency
cat /sys/devices/cpu/cpu1/cpufreq/stats/time_in_state
sleep 5
done
从 Motorola Xoom 的处理器 pstate 信息中返回的数据如下所示：
CPU0 PState Residency
216000 4356448
312000 400626
456000 559897
608000 398231
760000 92081
816000 0
912000 0
1000000 1485891
每个数据对代表一种 pstate 频率（单位为 KHz）及系统启动后该状态下所耗费的时间 （单位为百分之一秒）。每个处理器提供的 pstate 数各不相同。本例中，用于驱动 Motorola Xoom 的 NVIDIA Tegra2 处理器提供了 8 种可能的 pstate，频率从 216 MHz 到 1 GHz。
运用同计算 CPU 利用率相同的技巧，我们可计算出在取样间隔一定的情况下，处理器在每种 pstate 下所耗费的时间百分比。通过计算 pstate 频率的加权总和及该状态下所耗费时间的百分比，我们还可以得出相同间隔的平均频率。获得的数据如图 1 所示。
总结
通过使用 adb 和 Android* 从 Linux* 继承而来的现有性能基础设施，我们可深入了解 Android* 应用的性能特征。在此基础上，我们可对应用进行提升用户体验和降低功耗等优化操作。* 文中涉及的其他名称及商标属于各自所有者资产