疯狂就是重复做相同的事情，却期待不同的结果。

——阿尔伯特 爱因斯坦

性能测试推论:

“疯了” 就是同一件事只做一次，却希望得到最佳结果。

——不是爱因斯坦说的

通过点击图标来连续多次启动应用是一件非常繁琐的事情。而且这种操作不具备一致性，且有许多难以预测的因素，因为很容易就会引入变量——如您偶然间错误地启动了另一个应用，或者使系统做了额外的工作而无法获得计时结果。

因此，我真正想要的是某种从命令行启动应用的方式。有了它，我就可以反复运行该命令来执行相同的操作，从而避免手动启动应用带来的可变性 (和乏味)。

adb (Android 调试桥，阅读至此的读者应该都对它很熟悉了吧) 提供了我所需要的东西。更具体地说，adb shell 提供了用于启动应用的命令行界面: adb shell am start-activity。该命令还能够在应用启动完成之前保持阻塞状态，因此我们还要使用 -W 参数 (这对下一步来说是必需的。我们下一步将使用后续命令杀死启动后的应用)。这是完整的启动命令:

$ adb shell am start-activity -W -n

com.android.samples.mytest/.MainActivity

复制代码

最后一个参数是应用的包名与组件信息。您可以看到它们与上一部分中 ActivityTaskManager 输出的日志相同。

运行此命令将启动应用 (除非该应用已经在前台，但这种情况并不是理想的状态，我们将在下一步对这种情况进行处理)，并输出以下信息:

Starting: Intent { cmp=com.android.samples.mytest/.MainActivity }

Status:
ok

LaunchState: COLD

Activity: com.android.samples.mytest/.MainActivity

TotalTime: 1380

WaitTime: 1381

Complete

复制代码

检查一下 TotalTime 结果: 结果与我们在日志中看到的信息完全相同:

ActivityTaskManager: Displayed

com.android.samples.mytest/.MainActivity: +1s380ms

复制代码

这意味着我们无需翻看 logcat，而是可以直接从运行命令的控制台中便可获取这些信息。更棒的是，我们可以剥离多余的文本并仅保留启动结果，从而更轻松地提取此数据以供其他地方使用。

为了将上面的输出转换为启动持续时间，我使用 grep 和 cut shell 命令来输出内容 (有多种方法可以执行此操作，我只是随机选择了其中一个):

adb shell am start-activity -W -n

com.android.samples.mytest/.MainActivity | grep “TotalTime” | cut -d ’ ’ -f 2

复制代码

现在，当我运行这条命令时，就能如我预期般的只获得一个简单的数字:

$ [start-activity command as above…]

1380

复制代码

冷启动是性能测试的最佳起点

---

在您检查启动性能前，最好先了解 “冷启动” 和 “热启动” 之间的区别。

“冷启动” 是指您的应用在安装后的第一次启动、重启，或者不在后台时的启动。

另一方面，“热启动” 是指您的应用已经启动且正在后台运行 (但被暂停了) 时的启动。

这两种情况都值得去测试和理解。但总的来说，冷启动才是您进行启动性能测试的最佳起点，这其中有两个原因:

• 一致性 : 冷启动可以确保您的应用每次启动时都经历相同的操作。应用被热启动时，我们没法明确知道哪些步骤被跳过，而哪些步骤被执行，因而也无从得知您到底在对什么进行计时 (也无法保证重复测试时所测试的内容是否一致)；

• 最坏情况 : 按照定义，冷启动是最坏的情况——这是您的用户经历启动过程时间最长的场景。您需要专注于最坏情况的统计数据，而不是状况最好的热启动。如果您忽略最坏情况，许多重大问题将无法被解决。

为了在每次运行时强制进行冷启动，您需要在两次运行期间终止应用。再一次强调，在屏幕上执行这一操作 (例如，将应用从启动器的 “概览” 列表中滑出) 是乏味且容易出错的，而 adb shell 可以解决这一问题。

有几个不同的 shell 命令可用于终止应用。最显而易见的是 adb shell am kill…… 但事实上这条命令并不能解决问题。当您启动应用后，应用会处在前台，而 kill 不会终止处在前台的应用。作为替代，您需要使用 force-quit 命令:

adb shell am force-stop com.android.samples.mytest

复制代码

您可以使用应用的包名告诉它需要终止哪个应用。

我喜欢循环，让我们来循环它

---

现在，您已经有了可以启动应用、输出启动持续时间数据，以及退出应用并使其可以再次启动的一系列命令。您可以一遍又一遍地在控制台中输入这些内容，但是在 shell 中，我们可以将这些命令放在循环里，然后只用一个命令就可以重复运行它。

在执行此操作时，为了避免应用被终止而产生副作用 (例如，当应用程序被终止时，系统会将启动器拉到前台)，您可能会想要在终止应用后延缓下一次的启动。为此，我增加了一秒钟的 sleep 以在两次操作之间插入一个小的缓冲时间。

下面是我所使用的命令的最终版本，其中包括了终止应用、等待一秒钟，然后重启应用。我将这一过程循环执行了 100 次，从而可以提供一个合理的样本量:

$ for i in seq 1 100

do

adb shell am force-stop com.android.samples.mytest

sleep 1

adb shell am start-activity -W -n com.android.samples.mytest/.MainActivity | grep “TotalTime” | cut -d ’ ’ -f 2

done

复制代码

在运行此命令时，每当启动完成，我都可以获得输出到控制台的启动持续时间，而这正是我要跟踪和分析的数据。

注意 : 以上操作其实有更简单的方式，您可以使用 -S (用于首先停止 Activity) 和 -R COUNT (用于执行 start-activity 命令 COUNT 次) 来循环启动 Activity，所以我也可以用下面的命令完成以上操作:

$ adb shell am start-activity -S -W -R 100-n

com.android.samples.mytest/.MainActivity | grep “TotalTime” | cut -d ’ ’ -f 2

复制代码

但是，为了在应用的终止和启动之间加入缓冲时间，以确保其处于非活动的状态，我希望能使用 sleep 1 命令，因此我采用了更为冗长的方式进行循环。此外，shell 脚本的代码非常优雅，不是吗？

尽可能地锁住主频

---

CPU 架构，尤其是 CPU 频率，是影响移动设备性能的重要因素。具体而言，移动设备减少电量消耗及避免出现过热的问题的主要方法之一，便是限制 CPU 速度。

限制 CPU 对于节省电量很有用，但却对性能测试有负面影响，因为在这类测试中，结果的一致性至关重要。

理想情况下，在运行性能测试时，您应该控制 CPU 频率。然而您是否能够执行这一操作取决于您所拥有的设备——您需要拥有设备的 root 访问权限才能控制 CPU 调速器，从而才能控制 CPU 频率，并且不同的设备执行这一行为的方式也可能不同。

接下来的内容仅适用于您的设备允许且您可以取得 root 访问权限的情况。而在设备方面，我知道 Pixel 设备可以获得访问权限，但这不代表其他设备也同样可以。

在任何情况下，如果可以的话，建议您锁定 CPU 主频。对于您特定的测试而言，可能不会有明显的影响 (实际上，系统通常会在启动应用时使 CPU 运行在较高的频率上，因此可能已经提供了所需的一致性)。但是，这么做至少可以消除 CPU 主频这一可变因素。

手动锁定 CPU 频率可能很棘手，但幸运的是，AndroidX benchmark 帮您简化了这一操作。实际上，您甚至不需要为 benchmark API 编写代码——您可以通过使用其提供的 lockClocks 与 unlockClocks 工具来使用该库。

首先，向工程级别的 build.gradle 文件中加入 benchmark 的依赖:

// 查看 Benchmark 库的最新版本号

// https://developer.android.google.cn/jetpack/androidx/releases/benchmark

def benchmark_version = “1.0.0”

classpath “androidx.benchmark:benchmark-gradle-plugin:$benchmark_version”

复制代码

接下来，在应用级别的 build.gradle 文件中应用 benchmark 插件:

apply plugin: androidx.benchmark

复制代码

现在，您可以同步您的工程 (Android Studio 可能已经在强迫您执行此操作)，同步完成后便可以从 gradlew 中使用锁定任务。

现在，您可以通过在命令行上运行命令来锁定主频了 (我是通过 Android Studio 内部的 “终端” 工具运行它的，但是您也可以在 IDE 外部运行它):

$ ./gradlew lockClocks

复制代码

接下来，在应用级别的 build.gradle 文件中应用 benchmark 插件:

apply plugin: androidx.benchmark

复制代码

现在，您可以同步您的工程 (Android Studio 可能已经在强迫您执行此操作)，同步完成后便可以从 gradlew 中使用锁定任务。

现在，您可以通过在命令行上运行命令来锁定主频了 (我是通过 Android Studio 内部的 “终端” 工具运行它的，但是您也可以在 IDE 外部运行它):

$ ./gradlew lockClocks

复制代码