很多人刚开始碰 Android 开发和自动化测试时都会在终端里敲下adb然后回车期待一个简单的回应。结果屏幕上滚出几十行密密麻麻的命令列表看得人一头雾水。我见过不少同学卡在这一步明明叫“查看 adb 可执行命令”为什么有些命令要接设备、有些不用为什么 help 里的内容记不住也查不明白这篇内容就围绕“查看 adb 可执行命令”这件事展开把里面的门道拆开讲清楚。你会搞清楚 ADB 到底怎么组织命令、help 输出里每一段是什么意思、怎么快速定位自己需要的命令、以及怎么在实际调试中把这些命令用起来。适合刚入门 Android 开发、想搞自动化和设备管理、或者被adb命令搞到头疼的人参考。1. 先搞懂 ADB 是什么才能看懂“可执行命令”“查看可执行命令”这件事看起来是个很简单的动作但如果不知道 ADB 的底层结构看到的命令表就是一团没有关联的文字。我建议花两分钟理解一下 ADB 的工作方式再回来查命令你会发现自己瞬间就能看懂 help 输出。1.1 ADB 的三层结构ADB 的全称是 Android Debug Bridge翻译过来就是“调试桥”。它包含三个部分客户端你敲下的adb命令本身。它在电脑上运行负责接收你的输入。服务端一个后台进程每次执行 adb 命令时会被自动启动占用电脑的 5037 端口。所有命令都先发给它由它转发。守护进程运行在 Android 设备里的adbd进程。它负责接收服务端发来的指令并协调设备内部系统的执行。把这三层搞清楚后很多现象就有了解释。比如为什么adb version不接任何设备也能运行因为它的信息只来自电脑本地为什么adb install必须在连接设备之后才能用因为安装动作要交给设备上的 adbd 去落地。这套架构很像一个快递中转站。你手上有一批包裹命令不用亲自跑到收货人门口只要把包裹交给中转站服务端它按照地址设备序列号分发最后由区域快递员adbd敲门送达。只要中转站健康包裹就能正常送达。1.2 命令形态为什么这么“怪”ADB 的命令格式通常是adb [-d|-e|-s 设备] 子命令 [参数]。很多人刚看时觉得别扭为什么要在子命令前加一堆可选修饰符-d指只有一个 USB 设备时使用-e指只有一个模拟器时使用-s 设备序列号则是在多设备、多模拟器同时存在时必须使用的。这个设计本身就是为“多目标设备管理”准备的。ADB 生来承担的职责就是把电脑和无数台设备连接起来做调试如果命令设计成只能操作一台设备后面做多机并发测试时就得频繁重启服务端效率会很低。明白了这一层再看 help 的输出就不会觉得命令表是一堆乱码了你看到的每一条其实都是在“客户端-服务端-守护进程”这条链路上某一环能做的事。2. 查看可执行命令的几种途径和其中的坑2.1 最直接的入口adb help 输出逐段解读在终端输入adb help看到的输出通常分为几个段落很多教程只是把内容复制一遍但没有告诉你每一段背后的含义。以常见版本为例输出大致是Android Debug Bridge version 1.0.41 Version 30.0.5-... Global options: -a listen on all network interfaces, not just localhost -d use USB device -e use emulator -s SERIAL use device with given serial number General commands: devices list connected devices help show this help message version show version number ...这里有几个关键区分Global options全局修饰符号可以放在任何子命令前面用来指定目标设备。General commands不依赖某个具体业务场景的基础命令比如devices、help、version。Commands实际执行动作比如install、uninstall、pull、push、logcat、shell、forward、reverse、bugreport、backup等。Scripting options供脚本调用时使用的命令比如wait-for-device、start-server、kill-server。很多人有一个误区以为 help 里的命令全部都能“直接执行”。实际上start-server、kill-server、wait-for-device这类是面向脚本和调试过程的控制命令手动敲的机会并不多它们的作用是控制 ADB 服务端进程本身的生命周期。建议第一次看 help 时用笔在纸上分三栏A 栏是“管理电脑端服务”B 栏是“管理设备连接”C 栏是“具体业务操作”。把输出的命令各自归类后续再查就很有条理。2.2 子命令也有自己的“查看方式”但容易被忽略adb help只展示了一级命令。问题是 ADB 里很多功能是分层的比如adb shell本身只是“进入设备端命令环境”的入口进入之后你面对的是设备里的命令集合比如ps、top、dumpsys、pm、am、settings等这一层的功能极大但不属于宿主机上的“adb 可执行命令”。区分宿主命令和设备端命令是查命令时最容易踩的坑。举个例子adb shell ps -A这条命令里adb shell是宿主机命令ps -A是设备端命令。你在电脑上敲adb help永远查不到ps的用法因为它不在 ADB 的代码里而是 Linux 内核自带的工具。想看设备端哪些命令可用需要在adb shell里输入help或直接敲ls /system/bin查看。如果你不确定某个子命令的参数怎么写有个很实用的办法在宿主机上故意输错。比如你输入adb install它会提示usage: adb install [options] package以及options列表简单粗暴。这个技巧在处理logcat、pm、am这类参数繁多的命令时特别好用。另外adb shell本身也支持adb shell --help的写法但并不是每个子命令都统一支持--help这也是很多人骂 ADB“帮助写得烂”的原因。其实它的设计思路是“错误即文档”报错时会把用法和参数列表完整打印出来利用好这个机制比死记硬背强得多。2.3 版本信息与二进制文件本身也是“命令清单”除了adb help还有一个容易被忽略的信息源adb version。它的输出里包含版本号、构建号以及对应的内部版本信息。如果你的电脑上同时存在多个不同来源的 ADB这个命令能帮你确认当前用的是哪个。再深挖一层ADB 是二进制文件你可以用系统命令来查看它自身暴露的接口。在 Linux 或 macOS 上执行strings adb | grep usage:能看到二进制里嵌入的大量用法字符串这些是 help 之外的“隐藏命令提示”。虽然这个方法比较 geek但在某些特殊场合比如 help 输出被裁剪、开发者文档离线没法查非常好用。这里还要提一个细节adb help的输出内容并不是从“设备”里拿回来的而是宿主机 ADB 工具内置的文本。所以即使设备没连接help 也能正常显示。反过来adb shell里敲help时获取的是设备系统里/system/bin下工具的说明这两份帮助文档不能混着看。3. 把看到的命令用起来常用命令的字段拆解与场景“查看可执行命令”的最终目的不是背出来而是在需要时知道用哪条、怎么组合。我按日常使用的频率把命令分成五类拆开讲每条都附上实际操作时的逻辑。3.1 设备连接与管理类命令这类命令贯穿所有调试的起点。adb devices -l-l参数会把设备列表的详细信息展开包括型号、传输方式USB 或无线、系统版本。我建议任何时候都先用adb devices -l而不是裸敲adb devices因为多一列信息能让你快速发现问题。比如某台设备显示unauthorized多半是设备上没点“允许调试”显示offline多半是 adb 服务端或驱动异常。无线调试时ADB 的使用方式变化比较大。Android 11 及以上版本支持无线调试配对你会在开发者选项里看到一个“无线调试”入口。进入后需要两个信息IP 地址和端口号以及六位配对码。这个场景下用的命令是adb pair 192.168.x.x:port adb connect 192.168.x.x:portpair负责设备配对connect负责建立连接通道。配对完成后实际调试连接的端口和配对端口往往是不同的很多人把两个端口搞混导致连不上。建议每次开启无线调试后重新在设置页面里看一眼连接信息别凭记忆写。3.2 应用与包管理命令想查设备上装了什么、怎么卸载、怎么装指定版本靠的都是这一组命令。adb install -r -d app.apk-r表示覆盖安装保留数据-d表示允许降版本安装。这两个参数在开发和测试的日常工作里几乎是必用的你刚编译出一个新包想在旧包基础上覆盖逻辑、看看数据兼容问题时-r -d能省不少事。反过来卸载时我见过有人用第三方工具点半天其实一条命令就完事adb uninstall com.example.package注意这个包名必须是完整的包名不是应用显示名称。想查包名推荐组合命令adb shell pm list packages -f这条命令会列出所有 APK 文件路径和包名的映射。或者更精准地用adb shell pm list packages | grep 关键词“查看可执行命令”这件事的价值在这里体现得最充分你只有在看过pm的说明后才知道pm支持和list packages这种子级操作否则只能在 GUI 工具里手动翻找。3.3 文件传输与日志命令文件传输是高频操作格式非常固定adb push 本地文件路径 设备路径 adb pull 设备路径 本地目录注意设备路径一般要写/sdcard/xxx或者/data/local/tmp/xxx这种有权限的目录。如果往/system/这类分区写文件通常是 Permission denied 的报错不是文件名打错了而是权限不够。日志抓取更值得说说。很多人直接敲adb logcat结果被刷屏刷得停不下来然后又 CtrlC 结束什么都没记下来。正确的姿势是加过滤条件adb logcat -v time *:W-v time表示显示日期时间*:W表示只显示 Warning 以上级别的日志。想抓崩溃现场改一下级别adb logcat -v time *:E想抓具体进程的日志先想办法确定 pid再用--pid参数过滤。这个功能在调试多进程 App 时尤其好用不然日志里混着几十个进程的信息找起来非常痛苦。还有屏幕截图。用adb exec-out screencap -p screen.png可以把屏幕截图输出到电脑当前目录比在设备上截图再手动导出来快得多。这条命令的关键词是exec-out它把设备的字节流直接交给宿主机重定向。4. 实操从零开始查命令到第一次跑通完整流程很多人手里有设备也知道 ADB 大概能干嘛但一到具体环境就卡住命令输进去提示找不到、设备列表为空、或者连不上服务端。这里我按实际顺序走一遍所有步骤都是可直接照着做的。4.1 环境准备ADB 工具通常叫“platform-tools”从 Android 开发者官网下载压缩包即可。Windows 上解压后文件夹里能看到adb.exe、fastboot.exe、AdbWinApi.dll等文件。这里第一坑就是路径配置。很多人解压后直接双击adb.exe发现窗口一闪而过。这不是工具坏了而是你没给它参数。正确做法是把解压目录加入系统的环境变量PATH这样在任意终端里都能用。Windows 在“环境变量”里手动添加路径然后重开命令提示符。macOS 和 Linux 用户更简单解压后把路径写进 shell 配置文件即可比如export PATH$HOME/platform-tools:$PATH装完后验证环境是否正常adb version如果显示版本号工具就没问题。4.2 查命令的完整流程拿到一个陌生环境我一般按这个顺序来adb version adb help adb devices -l第一条确认工具可执行第二条确认命令列表第三条确认设备连接情况。三条跑完整个调试环境的状态就摸清了。每一条都有它的作用version帮你定位工具来源如果后续报错和版本有关这里是第一手信息help提供当前环境的命令基线devices -l检查通信链路是否通畅。接下来再用一个小场景把命令串起来查看设备上某一个应用当前安装的版本号。第一步确认设备在线adb devices -l输出里有device状态第二步找到包名如果不知道具体包名先跑adb shell pm list packages | grep 关键词第三步用dumpsys获取详细信息adb shell dumpsys package 包名 | grep versionName这里能明显看到“查看可执行命令”和“用命令”是两回事如果你只盯着 help 看不会知道dumpsys是分析系统服务的命令但只要跑过一次查命令时再看到dumpsys package这几个字就会立刻产生联想。多看多试是掌握 ADB 命令最有效的方法。4.3 用命令解决一个真实问题的现场记录假设你面前有一台电脑连着两部和一部模拟器你要给其中一部真机安装测试包。这时候如果直接敲adb install app.apk大概率会收到“more than one device/emulator”的报错。解决方法不是拔线而是用-s指定目标设备adb -s 设备序列号 install -r app.apk设备序列号去哪里看adb devices -l的第一列就是。这个例子完整展示了“查 help → 看到全局参数-s→ 配合具体命令 → 解决多设备冲突”的链路。整个过程不需要记笔记只要在报错后顺手看一眼 help把-s SERIAL的作用套进去问题就迎刃而解。5. 常见问题与排查技巧实录用 ADB 久了总能碰上一堆环境问题。我把高频问题按报错信息整理成了表格后面再挑几个重点详细说。报错信息可能原因解决思路command not found环境变量没配好检查 PATH 是否包含 platform-tools或改成绝对路径重试no devices/emulators found设备未开启调试 / USB 未授权 / 驱动异常在设备开发者选项开启 USB 调试重新插拔unauthorized设备上没点“允许 USB 调试”在设备弹窗上勾选“始终允许”点允许若没有弹窗撤销授权重来offlineadb 服务端和 daemon 版本不匹配 / 数据线问题执行adb kill-server后重新连接换线或换口more than one device/emulator宿主机连接了多台设备用adb devices -l看序列号再用-s指定cannot bind to 5037 port5037 端口被其他进程占用查端口占用程序杀掉后执行adb kill-server adb start-serverdevice unauthorized无线调试首次连接未配对先用adb pair配对再adb connect重点讲几个容易误判的地方。“no devices”不一定是驱动问题。很多新设备首次插入电脑时系统会自动安装驱动但部分设备需要先在开发者选项里开启“USB 调试”并同时开启“USB 安装”。如果你设备设置里两个开关没开全列表里就一直看不到。“unauthorized”出现时你的设备实际上已经和电脑建立了物理连接只是设备端没有授予调试权限。常见的尴尬情况是设备屏幕上弹窗一闪而过、没等你点“允许”就自动消失了。解决办法是进入设备的“开发者选项”在 USB 调试授权记录里撤销所有历史授权重新插线触发弹窗。这一步动作虽小但能解决一半以上的连不上问题。“offline”状态比 unauthorized 更隐蔽。设备显示在列表里但状态是 offline说明 adb 服务端和设备的版本协议不匹配或者服务端数据异常。这时候的通用清理步骤是adb kill-server adb start-server adb devices -l如果还是 offline把 USB 调试开关关掉再打开再不行就重启设备。多数情况下重启 adb 服务端就能把通信链路重置好。端口占用问题在 Windows 上尤其常见。如果你装了某些手机助手类的软件它们往往会自己占用 5037 端口。确定占用进程的方法是netstat -ano | findstr 5037查到 PID 后在任务管理器里结束对应进程再重启 adb 服务端。这个坑的根源在于 ADB 服务端只能有一个实例占用端口而很多所谓的“手机助手”内部也集成了一个 adb 服务端两边抢同一个端口。最后提一个和权限相关的问题很多同学在执行adb push或某些 root 相关操作时收到Operation not permitted报错。这说明设备端权限不够。调试设备或模拟器上可以尝试先执行adb root让 adbd 以 root 身份运行但普通量产机的出厂固件里这条命令通常会被拒绝这属于正常现象不是故障。写在最后也想分享点实在的体会我自己的经验是ADB 命令根本不需要背。它像一本使用频繁的手册每次遇到新的需求就去adb help里翻一翻或者故意输错命令看报错里的用法提示用着用着就记住了。真正值得花时间记的是“分类”和“组合逻辑”。知道devices负责连接列表shell负责进入设备端命令环境pm和am分别管理包和活动足够了。其余细节在需要的当下翻一下就能找到比你一次性背两百条命令效率高得多。最后分享一个小技巧把adb devices -l、adb logcat -v time *:E这一类高频命令写成一行便于记忆的 shell 脚本放在自己常用目录里需要时一条命令出来连查带抓日志都搞定。这个小习惯帮我省了很多重复敲命令的时间也让我逐渐摸清了 ADB 的命令组织逻辑。