ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

Android ADB实战：应用启动、关闭与重启命令详解

2026/8/13 23:48:12 拓冰建站 浏览量
Android ADB实战：应用启动、关闭与重启命令详解

1. 项目概述：从“点按”到“掌控”

对于大多数Android开发者或测试人员来说，与设备交互的起点往往是图形界面：在屏幕上点击图标启动应用，滑动关闭后台任务。然而，当你需要批量测试、自动化流程、或者在设备无响应时进行深度操作，图形界面就显得力不从心了。这时，adb（Android Debug Bridge）就成了你手中的“瑞士军刀”。它不仅仅是一个调试工具，更是连接开发机与Android设备（或模拟器）的命令行桥梁，让你能直接向系统底层发送指令。

本次聚焦的核心，是三个最基础、最高频，却也最容易混淆的操作：关闭、启动和重启应用。这听起来简单，不就是“打开”和“关上”吗？但在adb的世界里，“关闭”可能意味着温柔地退出，也可能意味着强制终止；“启动”可以打开主界面，也可以直接跳转到某个深层页面；“重启”则涉及一个完整的生命周期轮回。理解这些命令背后的差异，是高效进行自动化测试、问题排查和日常开发调试的关键。无论你是刚接触adb的新手，还是想梳理清楚这些命令细微差别的老手，这篇从实战出发的总结都能提供清晰的路径。

2. 环境准备与基础概念

在挥舞adb命令这把利器之前，确保你的“锻造台”和“武器”都已就绪是第一步。很多初学者遇到的第一个拦路虎往往不是命令本身，而是环境问题。

2.1 ADB工具链的获取与配置

adb是Android SDK Platform-Tools组件的一部分。获取方式主要有两种：

  1. 通过Android Studio安装：这是最推荐的方式。安装Android Studio后，打开SDK Manager，在SDK Tools选项卡中勾选Android SDK Platform-Tools进行安装。安装完成后，工具通常位于[你的SDK目录]/platform-tools/下。
  2. 独立下载Platform-Tools：你可以从Android开发者官网直接下载独立的Platform-Tools包，解压即可使用。

接下来是关键的环境变量配置，目的是让系统在任何目录下都能识别adb命令。

  • Windows系统：将platform-tools目录的完整路径（例如C:\Users\YourName\AppData\Local\Android\Sdk\platform-tools）添加到系统的Path环境变量中。
  • macOS/Linux系统：将上述路径添加到你的shell配置文件（如~/.bashrc或~/.zshrc）中，例如添加一行：export PATH=$PATH:/path/to/platform-tools。之后执行source ~/.zshrc使配置生效。

验证配置是否成功：打开终端（Windows为CMD或PowerShell），输入adb version并回车。如果能看到类似Android Debug Bridge version x.x.x的版本信息，恭喜你，环境搭建成功。

2.2 连接设备与授权

环境就绪后，需要让你的电脑和Android设备建立连接。

  • 物理设备连接：使用USB数据线连接手机和电脑。在手机上，当出现“是否允许USB调试？”的弹窗时，务必勾选“始终允许”并点击确定。这是关键一步，否则会出现adb devices列表显示设备为unauthorized（未授权）的状态。
  • 模拟器连接：如果你使用Android Studio的AVD或雷电、夜神等第三方模拟器，adb通常会自动连接到正在运行的模拟器实例。

连接后，在终端输入adb devices。理想的输出应如下所示：

List of devices attached emulator-5554 device ABCDEF0123456789 device

这里emulator-5554是模拟器，ABCDEF...是物理设备的序列号，后面的device状态表示连接已授权且正常。如果显示offline（离线）或unauthorized（未授权），请检查USB线、重新插拔、或在设备上撤销USB调试授权后重试。

注意：部分国产手机系统（如MIUI、EMUI）在开启USB调试后，还需要进入“开发者选项”中，额外开启“USB调试（安全设置）”或“允许通过USB调试修改权限”等选项，否则adb可能无法执行安装、卸载等高级命令。

2.3 定位目标应用：包名（Package Name）

在adb命令中，我们操作的对象不是应用图标的名字（如“微信”），而是其唯一的包名。包名是应用在Android系统中的身份证，格式通常类似于com.tencent.mm（微信）或com.android.chrome。

如何获取一个应用的包名？有几种常用方法：

  1. adb shell pm list packages：列出设备上所有已安装应用的包名。可以配合grep（Windows用findstr）过滤，如adb shell pm list packages | grep wechat。
  2. 查看已运行应用：adb shell dumpsys window | findstr mCurrentFocus（Windows）或adb shell dumpsys window | grep mCurrentFocus（macOS/Linux）。这条命令会输出当前前台应用的包名和Activity名，非常实用。
  3. 通过APK文件获取：如果你有应用的APK安装包，可以使用aapt工具（在build-tools目录下）来解析：aapt dump badging your_app.apk | findstr package。

记下目标应用的包名，这是我们后续所有命令的核心参数。

3. 核心命令深度解析与实操

掌握了包名，我们就可以深入最核心的三个操作。它们看似简单，但选择哪条命令，完全取决于你的实际场景。

3.1 启动应用（Launch an App）

启动应用不仅仅是打开它，更是启动一个特定的界面（Activity）。核心命令是adb shell am start。

基本语法：

adb shell am start -n [包名]/[Activity全名]
  • am：Activity Manager的缩写，是adb shell中管理Activity的核心命令。
  • -n：用于指定明确的组件名称（包名/Activity名）。

如何获取Activity全名？对于自己开发的应用，你当然知道主Activity是什么。但对于第三方应用，可以通过在启动应用后，立刻执行adb shell dumpsys window | findstr mCurrentFocus来获取当前Activity的名称。更专业的方法是使用adb logcat抓取日志，过滤ActivityManager的STARTintent。

一个完整的启动示例（以系统浏览器为例）：

adb shell am start -n com.android.chrome/com.google.android.apps.chrome.Main

执行后，设备上的Chrome浏览器将被启动并显示主界面。

高级启动选项：

  • 传递数据：使用-e或--es传递字符串类型的数据。
    adb shell am start -n com.example.myapp/.MainActivity -e "key" "value"
  • 指定Action：使用-a指定一个Intent Action，如打开浏览器访问网页。
    adb shell am start -a android.intent.action.VIEW -d https://www.example.com
    这条命令会弹出选择器，让你选择用哪个浏览器打开链接。

实操心得：am start命令非常强大，它模拟了应用内跳转的Intent。在自动化测试中，你可以用它直接跳转到测试的深层页面，跳过繁琐的导航步骤，极大提升测试效率。但前提是你必须知道目标Activity的完整类名。

3.2 关闭应用（Stop/Kill an App）

“关闭”在Android中有不同的力度，对应不同的命令，用错了场景可能无法达到预期效果。

3.2.1 温和结束：adb shell am force-stop

这是最常用、最干净的“关闭”方式。

adb shell am force-stop <包名>

作用：命令系统强制停止目标应用及其所有关联进程、服务、广播接收器等。这相当于用户在系统设置中点击“强制停止”按钮。结果：应用的所有进程被终止，状态被彻底清理。再次启动时，应用会经历完整的冷启动过程。适用场景：测试应用冷启动性能、清理应用状态以进行下一次测试、应用无响应时。

3.2.2 强制终止：adb shell am kill与adb shell kill

这两个命令力度不同，需仔细区分。

  • adb shell am kill [包名]：杀死指定包名应用的后台进程，但不会影响其前台服务或进程。如果应用当前有Activity在前台（用户正在使用），这个命令可能不会立即生效。它主要用于系统在内存不足时清理后台。
  • adb shell kill [PID]：这是Linux层面的命令，通过进程ID直接杀死一个进程。你需要先用adb shell ps | grep <包名>或adb shell top来查找应用的进程ID。这种方式非常粗暴，可能导致应用数据丢失或状态异常，通常仅在调试或force-stop无效时作为最后手段使用。

3.2.3 停止组件：adb shell am stop

这个命令用于停止一个正在运行的服务（Service），语法是adb shell am stop-service [组件名]。它不用于停止整个应用，而是应用内的特定后台服务。

注意事项：force-stop是应用级别最彻底的停止方式，也是自动化测试中最常用的。避免在常规操作中使用kill [PID]，因为它不可控，可能杀错进程或导致系统不稳定。

3.3 重启应用（Restart an App）

adb本身没有直接的“重启应用”命令。所谓的重启，就是关闭后再启动两个动作的组合。但这里面的门道在于关闭和启动之间的衔接与状态处理。

最简单的重启序列：

adb shell am force-stop com.example.myapp adb shell am start -n com.example.myapp/.MainActivity

这一套组合拳能确保应用从一个完全干净的状态（冷启动）重新开始。

模拟热重启/界面重载：有时你只想重启前台的Activity，而不是整个应用进程（例如在开发时想快速重载界面）。可以尝试先按返回键退出Activity，再启动它。但更可靠的方法是使用adb shell input keyevent命令来模拟按键，但这需要应用本身处理返回键逻辑。对于WebView或一些特定场景，可以发送一个ACTION_CLOSE_SYSTEM_DIALOGS的广播来间接达到目的，但这并非标准重启。

在自动化测试中的重启策略：

  1. 状态隔离测试：在每条测试用例开始前，执行force-stop+start，确保应用初始状态一致。
  2. 崩溃恢复测试：可以在应用运行时，直接kill其主进程，然后观察应用是否能自动重启或恢复状态（如果有前台服务或守护进程的话）。
  3. 内存泄漏测试：反复执行重启操作（可能结合adb shell am broadcast -a android.intent.action.CLOSE_SYSTEM_DIALOGS等），并使用adb shell dumpsys meminfo [包名]监控内存增长。

踩坑记录：直接使用kill命令“重启”应用后，有时会发现再次启动失败，或出现诡异的界面错乱。这往往是因为kill没有给应用优雅退出的机会，导致一些静态变量或文件锁状态异常。因此，在自动化脚本中，优先使用am force-stop来作为“关闭”步骤，它更稳定、可预测。

4. 进阶应用与自动化脚本

当你熟练掌握了单个命令后，便可以将它们组合起来，解决更复杂的实际问题，甚至构建自动化工作流。

4.1 组合命令实现自动化测试

假设你需要自动化测试一个购物应用“添加到购物车-崩溃-恢复”的流程：

#!/bin/bash # 这是一个简单的bash脚本示例 PACKAGE_NAME="com.example.shopping" MAIN_ACTIVITY="com.example.shopping.MainActivity" echo "1. 启动应用..." adb shell am start -n $PACKAGE_NAME/$MAIN_ACTIVITY sleep 3 # 等待应用启动完成 echo "2. 执行一些操作（这里假设通过坐标或无障碍服务点击）..." # adb shell input tap x y # 模拟点击搜索框 # adb shell input text "手机" # 输入文本 # adb shell input keyevent 66 # 模拟回车键 echo "3. 模拟应用崩溃（强制停止）..." adb shell am force-stop $PACKAGE_NAME sleep 2 echo "4. 重新启动应用，检查状态恢复..." adb shell am start -n $PACKAGE_NAME/$MAIN_ACTIVITY # 之后可以连接Appium或UIAutomator进行断言验证

这个脚本清晰地展示了命令组合的威力。在实际中，你会结合adb shell input、adb shell uiautomator等命令进行更精确的交互。

4.2 使用adb shell pm进行应用管理

adb shell pm（Package Manager）命令虽然不直接启动/停止应用，但在应用生命周期管理中不可或缺。

  • 清除应用数据：在重启应用前，如果你想获得一个全新安装般的状态，可以使用：
    adb shell pm clear <包名>
    这条命令会清空应用的所有本地数据、缓存、登录状态等，比force-stop更彻底。警告：此操作不可逆，生产环境慎用。
  • 禁用/启用应用：
    adb shell pm disable-user <包名> # 禁用（对用户） adb shell pm enable <包名> # 启用
    禁用后，应用图标会消失，无法被启动。常用于冻结预装软件。

4.3 通过广播（Broadcast）干预应用行为

adb shell am broadcast命令可以发送系统或自定义广播，间接影响应用行为。

  • 发送自定义广播：如果你的应用注册了接收器，可以通过adb触发。
    adb shell am broadcast -a com.example.myapp.ACTION_REFRESH
  • 常用系统广播：
    • adb shell am broadcast -a android.intent.action.BOOT_COMPLETED：模拟开机完成（需要应用有相应权限）。
    • adb shell am broadcast -a android.intent.action.ACTION_POWER_DISCONNECTED：模拟电源断开。

这些广播可以用于触发应用的后台逻辑，配合生命周期命令进行更复杂的场景测试。

5. 常见问题排查与调试技巧

在实际操作中，你一定会遇到各种问题。下面是一些典型问题及其排查思路。

5.1 设备连接与授权问题

问题现象可能原因排查步骤
adb devices列表为空1. USB线或端口故障
2. 驱动未安装（Windows）
3. 设备未开启USB调试		1. 换线、换端口。
2. 检查设备管理器是否有未知设备，安装对应驱动。
3. 进入手机开发者选项，确认“USB调试”已开启。
设备状态为unauthorized设备未信任当前电脑1. 检查手机屏幕是否有“允许USB调试”弹窗，点击确认。
2. 可尝试adb kill-server然后adb start-server重启服务。
设备状态为offlineADB版本与设备不兼容或连接不稳定1. 升级adb到最新版。
2. 重新插拔USB线。
3. 重启手机和电脑的ADB服务。

5.2 命令执行失败问题

问题现象可能原因解决方案
error: device offline设备掉线执行adb reconnect或物理重连。
Activity not started1. 包名或Activity名错误
2. Activity未在Manifest中导出
3. 应用已被禁用或冻结		1. 用dumpsys window或logcat确认正确的组件名。
2. 对于自己开发的应用，检查AndroidManifest.xml中该Activity是否设置了android:exported="true"。
3. 用adb shell pm list packages -d查看是否被禁用。
Permission Denial权限不足1. 尝试在已Root的设备上执行。
2. 对于系统应用操作，可能需要adb root权限（仅限模拟器或已root的真机）。
3. 检查命令是否涉及需要特定权限的组件。
am force-stop后应用自启应用被其他组件（如服务、广播、其他应用）拉活1. 检查是否有后台服务设置了START_STICKY。
2. 检查是否接收到系统广播（如网络变化）后自启。
3. 使用adb shell dumpsys activity processes查看进程关联。

5.3 性能监控与命令辅助

在执行启动/关闭命令时，结合性能监控工具，可以获取更深入的洞察。

  • 测量启动时间：
    adb shell am start -W -n com.example.myapp/.MainActivity
    加上-W参数，命令会等待Activity启动完成，并输出TotalTime、WaitTime等耗时信息，对性能测试非常有用。
  • 监控内存与CPU：
    adb shell dumpsys meminfo <包名> adb shell top -n 1 | grep <包名或PID>
    在应用启动前后或多次重启后执行，观察内存泄漏迹象。
  • 抓取日志定位问题：
    adb logcat -c # 清空旧日志 adb logcat -v time | grep -E "(ActivityManager|MyAppTag)" # 启动应用
    通过过滤ActivityManager的日志，可以清晰地看到系统处理start、stop命令的整个过程。

掌握这些排查技巧，意味着你不仅能执行命令，更能理解命令背后发生了什么，从而真正驾驭adb进行高效开发和调试。从简单的开关应用到复杂的自动化与深度排查，这条命令行之路，正是Android开发者从“使用者”迈向“掌控者”的必经阶梯。