ADB命令实战指南：从基础连接到自动化测试的完整教程

1. 从“救火队员”到“效率大师”：ADB命令的实战价值

如果你是一名移动端开发者、测试工程师，或者是一名热衷于折腾手机、平板的极客，那么ADB（Android Debug Bridge）这个名字你一定不陌生。它就像一把连接电脑与Android设备的“瑞士军刀”，平时可能静静地躺在SDK的platform-tools目录里，但一旦遇到真问题——比如应用闪退抓不到日志、手机变砖需要救砖、批量安装卸载应用、甚至是自动化测试——ADB往往是那个能把你从水深火热中捞出来的“救火队员”。然而，很多朋友对ADB的认知，可能还停留在adb devices查看连接和adb install安装应用这个层面，这实在是有些大材小用了。今天，我们就来系统性地梳理一下ADB命令，目标不是罗列手册，而是结合我这些年在一线开发、测试和搞机中踩过的坑、总结出的经验，让你从“知道有这个东西”升级为“知道怎么高效用好它”，真正成为掌控Android设备的“效率大师”。

2. 连接与基础：稳定沟通是第一步

所有ADB操作的前提，是你的电脑和Android设备之间建立了一条稳定、可靠的通信通道。这一步看似简单，却埋着最多的“坑”。

2.1 多种连接方式详解与选型

ADB主要支持三种连接方式：USB连接、网络连接（Wi-Fi）和无线调试（Android 11+）。每种方式都有其最佳使用场景和注意事项。

USB连接是最经典、最稳定的方式。它不依赖网络环境，传输速率高，特别适合刷机、传输大文件、进行需要高带宽的操作。操作步骤大家可能都熟悉：在手机的“开发者选项”中开启“USB调试”，用数据线连接电脑，然后在电脑终端执行adb devices，如果看到设备序列号后面跟着device字样，就表示连接成功。这里有个关键细节：数据线质量至关重要。我遇到过无数次连接不稳定、时断时续的问题，最后排查下来，多半是用了劣质或只能充电不能传输数据的线。建议备一根原装或品牌的数据线专用于调试。

注意：首次通过USB连接一台新设备时，手机会弹出“允许USB调试吗？”的RSA密钥指纹确认对话框。务必勾选“始终允许”，并点击确定。如果没看到弹窗，可以尝试重插数据线，或检查开发者选项是否真的已开启。

网络连接（Wi-Fi ADB）让你摆脱线缆的束缚，非常方便。传统方法是先用USB线连接，执行adb tcpip 5555命令将设备监听端口切换到TCP/IP模式，然后拔掉线，执行adb connect <设备IP地址>:5555。它的优点是灵活，设备可以放在一边，远程操作。但缺点也很明显：依赖同一局域网，速度受Wi-Fi质量影响，且如果设备重启或网络环境变化，连接会断开，需要重新用USB线执行adb tcpip来初始化，颇为麻烦。

无线调试（Android 11及以上）是谷歌官方推荐的无线连接方式，解决了传统Wi-Fi ADB需要先USB初始化的问题。在开发者选项中，找到“无线调试”，启用它。你会看到一对IP地址和端口号（例如192.168.1.100:42425）。在电脑上，直接使用adb pair <IP:端口>命令，并输入手机上显示的配对码，即可完成配对。之后就可以用adb connect <IP:端口>进行连接了。这种方式更安全（需要配对码），也更方便，是未来无线调试的主流。

连接方式选型建议：

• 日常开发调试：优先使用USB连接，稳定压倒一切。
• 需要设备远离电脑或进行自动化测试：使用无线调试（Android 11+）。
• 旧设备或无无线调试选项：使用传统网络连接，但做好需要反复初始化的心理准备。

2.2 连接故障的完整排查链路

当adb devices列表为空或显示unauthorized/offline时，别慌，按照以下链路一步步排查：

1. 检查物理层：换一根已知良好的数据线，换一个USB接口（优先使用主板后置接口，供电更稳）。
2. 检查设备端：
   • 确认手机“开发者选项”已开启。（进入“关于手机”，连续点击“版本号”7次可激活）
   • 确认“USB调试”开关已打开。
   • 如果是首次连接，查看手机屏幕是否有RSA密钥确认弹窗。
   • 如果是无线连接，确认设备与电脑在同一局域网，IP地址是否正确，防火墙是否阻止了5555等端口。
3. 检查电脑端：
   • 确认ADB服务已启动。可以尝试adb kill-server然后adb start-server重启ADB守护进程。
   • 检查设备驱动（Windows下常见问题）。在“设备管理器”中查看是否有带感叹号的“Android Device”或“ADB Interface”，如有，需要安装对应的USB驱动（通常可通过安装完整的Android SDK或手机厂商提供的PC套件解决）。
   • 是否有其他程序（如第三方手机助手、模拟器）占用了ADB端口？尝试关闭它们。
4. 终极手段：重启ADB服务、重启手机、重启电脑。这个“重启三连”虽然听起来像玄学，但确实能解决很多偶发的底层通信问题。

3. 设备管理与信息获取：知己知彼，百战不殆

连接成功后，我们首先需要了解我们的设备。ADB提供了一系列命令来获取设备状态和详细信息，这对于问题诊断、环境确认和脚本编写至关重要。

3.1 核心状态与属性查询命令

• adb devices -l：比adb devices更详细，会列出设备的型号（product）和连接类型（usb或network）。
• adb get-state：获取设备当前状态，通常是device（正常）、offline（连接异常）或bootloader（引导模式）。
• adb shell getprop：这是信息宝库。它会打印出设备的所有系统属性（ro.*只读，persist.*持久化，sys.*运行时）。我们常用它来获取特定信息：
  • adb shell getprop ro.product.model：获取设备型号（如“Pixel 6”）。
  • adb shell getprop ro.build.version.release：获取Android版本号（如“13”）。
  • adb shell getprop ro.serialno：获取设备序列号（与adb devices显示的一致）。
  • adb shell getprop ro.build.type：获取构建类型，user代表用户版（权限低），userdebug或eng代表调试版（权限高，可做更多操作）。

3.2 系统状态监控与日志抓取

• adb shell dumpsys：输出所有系统服务的状态信息，内容极其庞大。通常我们会配合grep（或findstron Windows）来过滤需要的信息。
  • adb shell dumpsys meminfo <package_name>：查看指定应用的内存使用详情，是分析内存泄漏的利器。
  • adb shell dumpsys cpuinfo：查看CPU占用情况。
  • adb shell dumpsys battery：查看电池状态（电量、健康状况、充电状态）。
  • adb shell dumpsys window displays：查看屏幕显示信息，包括分辨率、密度等。
• adb logcat：抓取系统日志，这是调试应用崩溃、分析问题根源的核心工具。直接运行会持续输出滚动的日志。常用参数：
  • adb logcat -v time：在每行日志前加上时间戳，便于定位。
  • adb logcat -s TAG：只过滤显示包含特定TAG的日志，例如adb logcat -s MyApp。
  • adb logcat *:E：只显示错误（Error）及以上级别的日志，在排查崩溃时非常有用。
  • adb logcat -c：清空当前的日志缓冲区。
  • 实战技巧：当应用发生崩溃时，一个高效的流程是：先adb logcat -c清空旧日志，然后复现崩溃，紧接着执行adb logcat -v time *:E > crash.log将错误日志保存到文件，再在文件中搜索你的应用包名或“FATAL”、“CRASH”等关键字。

3.3 屏幕操作与录屏

• adb shell screencap -p /sdcard/screen.png：截取屏幕截图并保存到设备存储。然后可以用adb pull /sdcard/screen.png .拉到电脑上。
  • 一键截图到电脑：adb exec-out screencap -p > screenshot.png（注意是exec-out不是shell），这个命令直接将二进制数据流输出到电脑，效率更高。
• adb shell screenrecord /sdcard/demo.mp4：录制屏幕（默认最多180秒），支持--size、--bit-rate等参数调整画质和大小。录制时按Ctrl+C停止。
• adb shell input：模拟输入事件，是自动化测试的基石。
  • adb shell input tap <x> <y>：在坐标(x, y)处模拟点击。
  • adb shell input swipe <x1> <y1> <x2> <y2> [duration]：模拟从(x1,y1)滑动到(x2,y2)，可指定持续时间（毫秒）。
  • adb shell input text “hello”：输入文本“hello”。注意，无法输入中文和一些特殊字符。
  • adb shell input keyevent <keycode>：模拟按键，例如adb shell input keyevent 26是电源键，3是Home键，4是返回键。KEYCODE列表可以通过adb shell input keyevent不加参数查看部分，或查阅Android官方文档。

4. 应用生命周期管理：安装、卸载与数据操控

对应用进行安装、卸载、清理数据，是开发和测试中的高频操作。这里面的门道也不少。

4.1 安装与卸载的进阶参数

• adb install <path_to_apk>：基本安装命令。
  • -r：替换已存在的应用（保留数据）。这是最常用的参数之一，在迭代开发时，不需要先卸载再安装。
  • -t：允许安装测试APK（即使AndroidManifest.xml中没有android:testOnly=”true”，有些构建版本可能需要）。
  • -d：允许降级安装（版本号比已安装的低）。
  • -g：授予APK中声明的所有运行时权限。对于需要动态权限的应用，安装后无需手动点击授权，非常方便自动化。
  • 组合使用示例：adb install -r -g app-debug.apk，表示覆盖安装并自动授予所有权限。
• adb uninstall <package_name>：卸载应用。
  • -k：卸载应用但保留数据和缓存。这个参数要慎用，通常用于测试数据是否导致问题。下次安装同名应用时，会恢复这些数据。

4.2 应用数据与缓存的高级操作

有时我们不想卸载应用，只想清空它的数据（相当于在设置里点击“清除数据”），或者需要备份/恢复特定应用的数据。

• adb shell pm clear <package_name>：清除应用数据。这比卸载重装更快，能快速将应用恢复到首次安装的状态，是测试的常用操作。
• adb backup -f backup.ab -apk -shared -all：这是一个已废弃但有时仍有用的完整备份命令（需要设备确认）。它可以备份应用及其数据、共享存储等。但由于安全限制和兼容性问题，在新设备和Android版本上可能失败。
• 更实用的方案：直接操作/data/data/和/sdcard/。但这需要root权限。对于已root的设备或模拟器：
  • 备份应用私有数据：adb shell su -c “tar -czf /sdcard/data_backup.tar.gz /data/data/<package_name>”，然后adb pull /sdcard/data_backup.tar.gz .。
  • 恢复：将备份文件推送到设备，然后adb shell su -c “tar -xzf /sdcard/data_backup.tar.gz -C /”。

  • 重要提示：直接操作/data/data/风险极高，且不同应用的数据结构不同，恢复后可能导致应用崩溃。仅建议高级用户在明确知道自己在做什么的情况下，用于备份游戏存档等特定场景。

4.3 应用信息查询与进程管理

• adb shell pm list packages：列出所有已安装应用的包名。
  • -f：显示包名和对应的APK路径。
  • -s：只显示系统应用。
  • -3：只显示第三方应用。
  • -e：只显示启用的应用。
  • –user <user_id>：多用户设备上，列出指定用户的应用。Android支持多用户和工作资料。
  • 结合grep过滤：adb shell pm list packages | grep mycompany，快速找到自己开发的所有应用。
• adb shell pm path <package_name>：显示指定应用APK文件的安装路径。
• adb shell pm dump <package_name>：导出指定应用的完整信息（权限、活动、服务等），内容非常详细，可用于分析。
• adb shell ps或adb shell ps -A：查看系统进程列表。可以结合grep查找自己的应用进程，查看其PID（进程ID）和内存占用。
• adb shell am：活动管理器（Activity Manager）命令，用于启动组件、发送广播等。
  • adb shell am start -n <package_name>/<activity_full_name>：启动一个Activity。例如：adb shell am start -n com.example.myapp/.MainActivity。
  • adb shell am force-stop <package_name>：强制停止一个应用。比在最近任务里划掉更彻底。
  • adb shell am broadcast -a <action>：发送一个广播。

5. 文件传输与系统操作：深入设备腹地

ADB也是电脑和设备之间传输文件、甚至直接修改系统文件的桥梁。

5.1 文件推送与拉取

• adb push <local> <remote>：将电脑上的文件或目录推送到设备。
  • 示例：adb push ./update.zip /sdcard/。
  • 注意路径权限：通常只能推送到/sdcard/、/storage/emulated/0/等外部存储目录，或/data/local/tmp/这个临时目录（无需root）。尝试推送到系统目录如/system会因权限不足而失败。
• adb pull <remote> <local>：将设备上的文件或目录拉取到电脑。
  • 示例：adb pull /sdcard/DCIM/Camera ./photos/拉取相机照片。
  • 拉取应用私有数据需要root：adb shell su -c “cat /data/data/<package>/files/db.sqlite” > ./db.sqlite。

5.2 Shell下的文件与进程操作

进入adb shell后，你就拥有了一个设备的终端。常用的命令和Linux/Bash类似：

• ls,cd,pwd,cat,echo,rm,mkdir,cp,mv：基础文件操作。
• ps,top,kill：进程查看与管理。kill -9 <pid>可以强制结束进程。
• df：查看磁盘空间使用情况。
• chmod,chown：修改文件权限和所有者（通常需要root）。
• grep：文本搜索，在分析日志或配置文件时必不可少。例如在shell里logcat | grep “MyApp”。
• find：查找文件。例如find /sdcard -name “*.jpg”。

5.3 权限提升与系统分区操作（需要Root）

对于已root的设备，可以在adb shell命令前加上su -c来以root权限执行单条命令，或者先执行adb shell，再在shell里执行su切换到root用户。

高危操作警告：以下操作可能使设备变砖，仅供高级用户了解，操作前务必确认并备份。

• adb remount：将/system分区重新挂载为可读写。这是修改系统文件（如hosts文件、内置应用）的前提。此命令通常只在工程模式或已解锁system分区的设备上有效。
• adb shell mount -o rw,remount /system：另一种重新挂载/system为可读写的方式。
• adb shell “cat /sdcard/new_hosts > /system/etc/hosts”：替换系统的hosts文件（需要先remount）。
• adb shell pm disable-user <package_name>：禁用某个系统应用（需要root）。例如禁用厂商预装的臃肿软件。adb shell pm enable <package_name>可以重新启用。

6. 高级技巧与自动化脚本：释放ADB的真正潜力

当单个命令满足不了复杂需求时，组合使用ADB命令或者将其嵌入脚本，能实现强大的自动化。

6.1 命令组合与管道操作

ADB命令可以像Linux命令一样组合使用。

• 连续执行：使用&&连接命令，前一个成功才执行后一个。adb devices && adb logcat -c && adb logcat -v time > log.txt。
• 管道传递：在adb shell内部或与本地命令结合。例如，统计日志中某个错误出现的次数：adb logcat -d | grep -c “Fatal exception”。
• 循环与条件：可以编写Shell脚本（.sh）或批处理文件（.bat），在里面使用for循环、if条件判断来批量操作设备或应用。

  # 示例：批量安装当前目录下所有APK for apk in *.apk; do echo “Installing $apk…” adb install -r -g “$apk” done

6.2 多设备管理

当同时连接多台设备（多部手机、多个模拟器）时，需要在命令中指定目标设备。

• adb devices会列出所有设备序列号。
• 使用-s <serial_number>参数指定对哪台设备操作。例如：adb -s emulator-5554 install app.apk。
• 使用-e参数指定对唯一的模拟器操作，使用-d参数指定对唯一的USB设备操作（当连接了多个不同类型设备时）。

6.3 实战场景：自动化测试与批量操作脚本

假设一个测试场景：需要在一台设备上，反复安装测试APK，清空数据，启动应用，进行一些操作，然后抓取日志。

#!/bin/bash # auto_test.sh PACKAGE_NAME=“com.example.myapp” APK_PATH=“./app-debug.apk” LOGFILE=“test_$(date +%Y%m%d_%H%M%S).log” echo “开始自动化测试…” | tee -a $LOGFILE for i in {1..10}; do echo “第 $i 轮测试” | tee -a $LOGFILE # 1. 卸载旧版本（可选，-r覆盖安装通常更快） # adb uninstall $PACKAGE_NAME # 2. 安装应用（覆盖安装并授权） adb install -r -g $APK_PATH 2>&1 | tee -a $LOGFILE # 3. 清空应用数据，确保每次起点一致 adb shell pm clear $PACKAGE_NAME 2>&1 | tee -a $LOGFILE # 4. 启动主Activity adb shell am start -n $PACKAGE_NAME/.MainActivity 2>&1 | tee -a $LOGFILE sleep 3 # 等待应用启动 # 5. 模拟一些用户操作 adb shell input tap 500 1000 # 点击某个按钮 sleep 1 adb shell input text “test$i” sleep 1 adb shell input keyevent 4 # 按返回键 # 6. 抓取本轮日志片段 echo “=== 第 $i 轮日志开始 ===” >> $LOGFILE adb logcat -d -v time –pid=$(adb shell pidof -s $PACKAGE_NAME) >> $LOGFILE 2>&1 echo “=== 第 $i 轮日志结束 ===” >> $LOGFILE # 7. 强制停止应用 adb shell am force-stop $PACKAGE_NAME sleep 2 done echo “自动化测试完成，日志保存在 $LOGFILE”

这个脚本展示了如何将多个ADB命令组合起来，形成一个完整的自动化测试流程。你可以根据自己的测试需求，修改其中的操作步骤和等待时间。

6.4 性能监控简易脚本

除了dumpsys meminfo和cpuinfo，我们还可以写一个简单的脚本，周期性地抓取某个应用的内存和CPU占用。

#!/bin/bash # monitor.sh PACKAGE_NAME=“com.example.myapp” INTERVAL=2 # 采样间隔（秒） DURATION=60 # 监控时长（秒） echo “时间, CPU%, 内存PSS(KB)” > performance.csv end=$((SECONDS+DURATION)) while [ $SECONDS -lt $end ]; do # 获取进程PID pid=$(adb shell pidof -s $PACKAGE_NAME) if [ -z “$pid” ]; then echo “应用未运行” sleep $INTERVAL continue fi # 获取CPU和内存信息（这里简化处理，实际解析top或dumpsys meminfo输出更准确） # 示例：使用dumpsys meminfo获取PSS内存 mem_info=$(adb shell dumpsys meminfo $PACKAGE_NAME | grep “TOTAL PSS:” | awk ‘{print $3}’) # 注意：CPU占用率获取较复杂，可能需要解析top或/proc/stat，此处省略细节 echo “$(date +%H:%M:%S), N/A, $mem_info” >> performance.csv sleep $INTERVAL done echo “监控结束，数据已保存到 performance.csv”

这个脚本提供了一个思路框架，实际应用中需要更精细地解析adb shell top -n 1或adb shell dumpsys cpuinfo的输出，来获取准确的CPU百分比。

ADB的强大远不止于此，它还与fastboot（刷机模式）、bugreport（生成完整的设备诊断报告）等工具链紧密结合。掌握这些命令，意味着你掌握了与Android设备深度对话的能力。从简单的文件传输到复杂的自动化测试，从问题排查到性能调优，ADB都是你工具箱里不可或缺的利器。我个人的体会是，不要试图一次性记住所有命令，而是从实际需求出发，遇到问题知道用什么命令去解决，或者去查询，多用几次自然就熟了。最好的学习方法，就是现在就打开终端，连上你的设备，把上面提到的命令亲手敲一遍，看看它们的输出到底是什么。实践出真知，在移动开发和调试这条路上，ADB绝对是你值得花时间深挖的伙伴。