打开终端敲下adb help屏幕上会刷出一大片英文命令列表。第一次看到的人很容易懵密密麻麻的指令和参数说明好像每个单词都认识连在一起却不知道该怎么用。但你如果真的想在安卓开发、自动化测试或者设备调试这条路上走远一点把这个命令清单吃透是绕不过去的基本功。这篇文章想分享的就是我平时查看和理解 adb 可执行命令的一套完整方法。从最基础的adb help输出说起到怎么读、怎么记、怎么查子命令再到 Windows 和 macOS 下实际操作时需要留神的细节最后是把常见报错和排查思路一次性说清楚。不管你是刚接触安卓调试的新手还是已经被 adb 折腾过一阵子的开发者这篇文章应该都能给你一些新的收获。1. 为什么“查看 adb 可执行命令”这件事值得单独写一篇很多教程会直接扔给你一串命令比如adb devices、adb install、adb shell复制粘贴能跑通就完事。但一旦你离开教程里的固定场景自己想实现点别的功能就会卡住。问题不在于你记不住命令而在于你没有一个系统的框架来理解 adb 到底“会什么”。所以我一直觉得与其零散地背命令不如先学会怎么把 adb 的完整能力地图打开。1.1 adb 本身自带一份说明书只是很多人没认真读adb help就是那份说明书。它列出了 adb 所有核心可执行命令涵盖设备连接、文件传输、应用管理、调试日志等方方面面。如果你打开这份说明书能看懂每一行在说什么那你对 adb 的理解就已经超过大多数“只会复制粘贴”的人了。拿我自己的经历来说早期做自动化测试的时候需要在脚本里频繁判断设备状态、拉取日志、模拟按键输入。当时我对 adb 的认知仅限于adb devices和adb install其他功能全靠临时上网搜。有一次要在几十台设备上批量配置网络代理我搜了半天才找到adb shell settings put global http_proxy这种用法。后来花了一个晚上把adb help从头到尾过了一遍才发现原来这些能力在说明书里都有迹可循只是我一直没花时间去看。从那以后我的习惯就变成了拿到任何新工具第一件事先看它的帮助文档而不是急着搜具体命令。1.2 查看命令清单能帮你在紧急时刻少走弯路实际调试中很多问题都是“时间紧迫再搞不定就要延期了”。这时候你脑子里存储的命令越多试错成本就越低。比如设备没有反应你可以快速想到adb reboot应用闪退你需要的是adb logcat怀疑设备连接不稳定你会用到adb kill-server再adb start-server。这些命令不是靠死记硬背来的而是靠你反复查看adb help的输出、理解每个命令的功能归属之后慢慢形成一种“肌肉记忆”。所以我强烈建议读完这篇文章之后你自己去终端跑一遍adb help对照下面的章节逐条理解比只读文章效果要好得多。1.3 适合谁看以及你能从中得到什么这篇文章适合三类人第一类是刚接触安卓开发和调试的新手需要建立对 adb 的系统认知第二类是自动化测试、运维或者手机评测相关的从业者需要在脚本里频繁调用 adb 命令第三类是纯粹喜欢折腾设备的玩家想更全面地掌握手里的工具。不管属于哪一类读完这篇文章你至少能搞清楚三件事adb 命令清单从哪里看、每类命令大概负责什么、遇到问题怎么定位和排查。这些东西虽然不复杂但都是实打实的经验总结能省下不少自己摸索的时间。2.adb help输出的完整拆解一次看懂所有命令类型把adb help的输出当成一张地图来读是最高效的方式。这张地图按功能划分了几个区域每个区域都有一批功能相近的命令。我用过一段时间之后发现整个输出其实可以归纳为六大类设备连接管理、文件传输、应用管理、shell 交互、日志系统、服务与守护进程管理。下面逐一说清楚。2.1 设备连接管理先搞清楚你面前有几台设备这是 adb 最基础的功能模块核心命令是adb devices。它会列出当前连接到电脑的所有设备包括真机、模拟器还有无线调试连接的设备。输出通常长这样List of devices attached emulator-5554 device 1234567890abcdef device每一行代表一台设备。第一列是设备序列号第二列是设备状态。常见的状态有三种device表示设备正常运行offline表示设备掉线或者没有正确响应unauthorized表示设备没有授权电脑调试。如果是unauthorized你需要看一眼手机屏幕确认是否弹出了“允许 USB 调试吗”的对话框点击确认之后重新执行adb devices。如果有多台设备连接很多命令会报错提示“more than one device”。这时候要么用-s参数指定序列号比如adb -s emulator-5554 install app.apk要么用环境变量来控制。实战中我更推荐用-s参数因为直观且不容易误操作。2.2 文件传输在电脑和设备之间搬运数据的通道adb push和adb pull是文件传输的两大主力命令。adb push是把电脑上的文件推送到设备里adb pull是把设备里的文件拉到电脑上。注意文件的路径逻辑设备端的路径要写对否则要么找不到文件要么没有权限写入。比如我想把一个配置文件推到手机的下载目录adb push config.xml /sdcard/Download/config.xml然后在电脑上拉取一份设备里的日志文件adb pull /sdcard/Download/log.txt C:\Users\MyName\Desktop\log.txtWindows 系统路径里的反斜杠最好写成双反斜杠或者用正斜杠避免转义问题。macOS/Linux 下路径就简单多了。顺带一提/sdcard/路径在绝大多数设备上指代内部存储空间但部分设备可能路径结构不同保险起见可以用adb shell ls /sdcard/先确认一下。2.3 应用管理安装、卸载和查看应用信息应用管理这块是使用频率相当高的功能。adb install用于安装 apk它有几个常用参数值得记住-r覆盖安装保留原有数据-d允许降级安装从高版本装回低版本-g安装时直接授予所有运行权限我经常用的一条组合命令是adb install -r -d -g app.apk这条命令在测试覆盖安装场景时特别实用。卸载则是adb uninstall后面直接跟包名比如adb uninstall com.example.demo如果你不知道包名可以先执行adb shell pm list packages查看设备上安装的所有包名列表再用 grep 过滤关键词。2.4 shell 交互像操作 Linux 一样操作安卓设备adb shell是非常强大的一个入口进入到设备的 Linux shell 环境后你就可以执行 ls、cat、ps、kill 等各种指令。这也是为什么很多人说“掌握了 adb shell就等于掌握了一台微型 Linux 机器”。举个例子如果你想查看设备当前运行的进程可以先执行adb shell进入交互模式也可以直接用一条命令完成adb shell ps -A如果你只是想单独执行某一条远程指令完全没有必要进入交互模式。比如查看设备型号adb shell getprop ro.product.model或者模拟用户点击屏幕adb shell input tap 500 1000这些都是自动化测试和日常调试里的高频操作。adb shell理解起来可以把安卓设备看作一台远程服务器adb 就是你的 SSH 客户端输入的命令会由设备端执行并返回结果。2.5 日志系统排查崩溃和分析运行状态的第一工具logcat 是 adb 命令里调试价值极高的一类尤其是 Android 应用崩溃、ANR、性能分析这些场景。完整的命令是adb logcat不加任何参数时它会把设备输出的所有日志实时刷到终端上。要停止就按 CtrlC。实际工作时我更习惯加过滤条件。比如只看某个应用标签下的日志adb logcat -s MyAppTag按优先级过滤比如只看错误级以上的日志adb logcat *:E如果想保存到文件里慢慢分析可以这样adb logcat -d logcat.txt-d表示 dump 当前日志缓冲区的全部内容后自动退出不会一直挂着。这个技巧在处理大型日志文件时很有用可以先拿到完整输出再丢给文本编辑器搜索关键词。2.6 服务与守护进程管理处理连接时的疑难杂症最后这组命令很容易被忽略但关键时刻能救命。比如设备连接不稳定或者 adb 长时间运行后状态异常很多人会先重启电脑或者重启 adb。其实第一条该做的是adb kill-server adb start-server这两条命令的作用是重启 adb 后台服务。很多时候设备连不上、识别不了都是因为 adb 服务进程因为端口占用、热插拔等原因进入了异常状态重启服务通常能解决一半以上的连接问题。此外你还可以通过adb version查看 adb 版本号adb remount在某些 root 设备上重新挂载系统分区adb root以 root 权限重启 adb 服务。把它们单独列出来是希望大家在排查设备连接问题时优先想到这个“重启大法”而不是急着重启电脑。和路由器出问题先断电重启一个道理简单高效。3. 实操环节在 Windows、macOS 和 Linux 下手动查看 adb 命令理论看完之后实操才是重点。下面我会把电脑端查看 adb 可执行命令的具体操作步骤写清楚包括怎么确认 adb 安装成功、怎么打开帮助列表、以及怎么查看单个子命令的详细用法。3.1 先确认 adb 已经在你的环境里能正常运行不管是哪个系统第一步都是打开终端窗口输入adb version如果返回类似这样的信息说明 adb 已经安装好并且能被终端识别Android Debug Bridge version 1.0.41 Version 30.0.5-7784292如果提示“adb 不是内部或外部命令”或者“command not found”说明 adb 没有安装或者没有配置环境变量。常见解决方案有三个安装完整的安卓平台工具官方发布渠道是 Android 开发者网站里面有专门针对 Windows、macOS、Linux 的压缩包。如果你安装了 Android Studio可以找到 SDK 目录下的 platform-tools 文件夹把路径加到系统环境变量里。Windows 下也可以用包管理器来安装比如通过命令行工具安装“platform-tools”包。这一步没搞定之前后面的命令都没法正常执行所以值得先花几分钟确认好环境。3.2 Windows 下查看 adb 命令清单的详细步骤Windows 用户优先推荐用 PowerShell 或者 Windows Terminal。打开方式不需要额外技巧直接在开始菜单搜“PowerShell”就能找到。在终端里输入adb help如果你配置好了环境变量输出会直接显示否则你需要在 adb 所在目录下执行或者用完整路径例如C:\Users\MyName\AppData\Local\Android\Sdk\platform-tools\adb.exe help输出的内容很长建议在 PowerShell 里用adb help | more这样输出会分页显示按空格翻页不至于瞬间刷屏什么都看不清。如果想把帮助内容保存成文件之后离线查看可以执行adb help adb_help.txt生成的文件会保存在当前工作目录下用记事本或者 VS Code 打开都很方便。另外一个小技巧是在 PowerShell 里输入adb help | Select-String install这会在帮助文本里搜索包含“install”的行。当你想快速定位某类命令到底存不存在的时候比从头看一遍效率高很多。3.3 macOS 和 Linux 下的查看方法和技巧macOS 用户打开系统自带的“终端”应用即可。Linux 用户根据桌面环境不同打开终端的快捷键通常是 CtrlAltT。执行adb help如果安装在系统 PATH 里输出会直接出来否则你需要先定位 adb 的位置。可以用which adb这会告诉你 adb 可执行文件的完整路径。如果没有结果你依然可以通过 Android SDK 的路径找到它通常在$HOME/Library/Android/sdk/platform-tools/adb或者 Linux 下的~/Android/Sdk/platform-tools/adb。和 Windows 一样你也可以在帮助列表里搜索某个关键词。比如adb help | grep install在文件较多或者输出较长时我经常配合less来分页查看adb help | less按 q 退出。这个方法在 Linux 和 macOS 上都通用也是我平时最习惯的查看方式。3.4 不止 adb help逐个子命令的专属帮助也能查很多人不知道adb 的每个子命令也支持查看自己的详细参数说明。看adb help只是拿到总目录但具体到某个命令的每个参数是什么意思、有没有隐含约束光靠总目录是不够的。比如安装应用相关的完整参数可以执行adb install --help或者用adb help install效果类似。再看日志相关的参数可以执行adb logcat --help输出里会列出各个过滤选项、输出格式、缓冲区设置等信息量远大于adb help里的一行描述。这相当于你有了一份从总目录到分目录的完整索引想查什么就能查到什么。以我个人的使用经验来说如果你真想在命令行操作安卓设备时做到心中有数adb help加各子命令的--help组合拳是你最好的学习材料。没有之一。3.5 怎么从源码层面理解 adb 命令的来龙去脉如果你的兴趣已经超出了“会用”的层面想搞清楚 adb 命令到底是如何被解析和执行的可以去看安卓平台工具的源代码。adb 的源码是开放的里面有一个专门负责命令分发的文件其中定义了每个命令对应的处理函数。查源码不需要把整个项目下载下来直接在公开的安卓代码仓库里搜索“Usage: adb”这种字符串就能定位到帮助信息的定义位置。看源码的好处是你能清楚知道adb help里列出的命令树是怎么来的、每个命令缩写是如何注册的以及为什么有些参数组合被允许而有些不行。不过我也要说句实话对于绝大多数日常使用场景来说看帮助文档已经足够了。源码属于进阶中的进阶有时间有兴趣可以看看没时间完全不影响你排查问题和写脚本。4. 常见问题与定位思路我踩过的一些坑再简单的工具实际用起来总会遇到各种幺蛾子。下面把我在查看和执行 adb 命令时遇到过的典型问题整理出来每个都附上排查思路和解决方案。这些内容网上零零散散都有但我把它们汇总到一起方便你按图索骥。4.1 adb 命令找不到第一反应别急着重装前面提到过提示“adb 不是内部或外部命令”或者“command not found”属于环境变量问题。但这里有个细节很容易被忽略——你明明安装了 Android Studio终端里却还是找不到 adb。原因多半是 Android Studio 自带的 SDK 路径和你终端搜索的 PATH 路径不一致。解决方法是手动把 platform-tools 目录加到环境变量里确保路径中不包含中文或者空格否则有些终端工具在解析时会出现问题。设置完成后重新打开终端让配置生效再执行adb version验证。4.2 adb 设备列表为空但手机明明连接了电脑第二种高频问题是用adb devices查看设备时显示空白手机顶部的通知栏也显示了 USB 调试模式但就是连不上。这个问题的排查顺序建议固定下来先换根数据线试试部分劣质线材只能充电不能传输数据然后在手机开发者选项里把“USB 调试”关掉再打开接着点击“撤销 USB 调试授权”并重新确认弹窗最后再执行adb kill-server和adb start-server重启 adb 服务。如果还是不行检查一下电脑端口是否被其他程序占用。我遇到过某个手机助手软件抢占 adb 端口的情况关掉那个软件一切就正常了。4.3 adb server version mismatch 的解决思路adb server version mismatch这个报错常见原因是电脑里存在多个不同版本的 adb 可执行文件有些程序自带了老版本的 adb你终端里调用的又是新版本两者版本不一致导致服务冲突。解决的办法是先查一下电脑里到底有哪些 adb 文件在跑。Windows 下可以在命令行执行where adbmacOS/Linux 执行which adb找到所有路径之后把不需要的旧版本删除或者把新版本所在的目录在 PATH 里排到最前面让系统优先调用新版本。处理完之后重启终端再执行一次adb start-server让新版本的服务接管端口。4.4 设备状态显示 offline 应该怎么办出现 offline 状态多数情况下是 adb 服务与设备之间的通信机制出了问题。USB 连接的不稳定、adb 版本太旧、设备进入了休眠状态都可能触发这个状态。我的处理流程是这样的先重新插拔一次数据线或者关闭再打开 USB 调试如果还不行执行adb kill-server和adb start-server再不行重启设备。我处理过的大多数 offline 问题重启 adb 服务之后都能恢复真正需要重启设备的场景反而很少。4.5 需要留意权限问题设备没有 root 权限时部分 adb 命令会执行失败尤其涉及系统目录的操作。例如想修改/system分区下的文件内容普通权限是不行的。adb remount在很多设备上也会提示权限不足。此外 Windows 下偶尔会遇到进程占用导致文件无法操作的情况。比如你刚执行完adb pull拉取一个大文件马上又要覆盖它可能被报告“文件正在使用中”。处理方法是关掉正在占用这个文件的其他程序或者改个文件名保存。4.6 常见问题速查表我把上述问题做成一个速查表格方便你实际干活的时候快速对照。现象可能原因优先排查方向adb 命令无法识别未安装或环境变量未配置检查 adb 路径配置 PATHdevices 无设备驱动/线材/授权问题换线、重开 USB 调试、重启 adb 服务server version mismatch有多个 adb 版本冲突找到所有 adb 路径统一版本设备状态 offline通信异常或版本过旧重新插拔、重启 adb 服务命令执行 permission denied权限不足确认是否需要 root 权限logcat 输出太多没法看没有设置过滤条件用-s按标签过滤或按优先级过滤这份表格里的解决方案基本能覆盖我日常工作中八成以上的 adb 问题。剩下两成更复杂的场景绝大多数也都能通过查看 adb 子命令的帮助信息找到线索。5. 进阶用法把“查看命令”变成你的日常习惯最后聊聊我自己的使用心得。很多人觉得查看帮助文档是新手才干的事情老手应该把命令背得滚瓜烂熟。但我的经验恰恰相反资深开发者比新手更常看帮助文档因为他们知道自己不可能记清所有参数细节。5.1 给常用命令做一个专属备忘清单我不会尝试把所有 adb 命令都背下来但我会把高频使用的命令整理成一个 markdown 文件放在本地。每次要查的时候直接打开搜索比翻终端里刷过去的帮助输出方便得多。我的备忘清单结构很简单按功能分类记录命令、参数、用途、注意事项。比如安装覆盖 adb install -r -d -g app.apk 拉取日志 adb logcat -d logcat.txt 模拟点击 adb shell input tap x y 获取当前应用包名 adb shell dumpsys window | grep mCurrentFocus这样的清单可以根据自己的使用习惯不断增量更新。重点不是一次性写完而是每当你解决了一个新问题就把关键命令记进去。时间长了这就是一份完全个人化的 adb 速查手册。5.2 把 adb 命令“外包”给脚本释放记忆力第二个建议是学会把 adb 命令封装成脚本。比如我会在电脑上放几个小脚本一个是批量查看多台设备状态的一个是自动拉取所有设备日志的。这样做的好处是用的时候输入一条简单指令即可不需要临时敲一长串 adb 命令。举个例子批量查看设备状态的脚本本质上就是在adb devices的基础上加了格式化输出的能力。用 Python 来写的话代码也不复杂核心逻辑就是用subprocess调用 adb 命令然后把输出解析成整洁的表格。写脚本不是必须的但它可以让你从记忆负担中解放出来把精力放到真正需要思考的问题上。如果你平时只在终端里偶尔用一两次 adb那完全没有必要上脚本但如果你跟我一样经常和成群设备打交道这个习惯会省下很多时间。5.3 持续关注 adb 的更新内容adb 工具本身也在持续演进。新版本会带来新命令、新参数也会修正一些旧问题。关注更新内容最简单的方法就是定期运行adb version对比版本号是否和下载页面的最新版本一致。如果落后比较多去官方平台工具页面下载最新包解压替换即可。无需特别频繁但一个新版本发布后花几分钟看看更新日志还是值得的。5.4 实际体会把命令查看变成技能体系的一部分搭建高效的调试工作流重点不在于记住所有命令而在于形成一套不断增长的技能体系。遇到问题去查命令、理解了参数含义、用到了实际场景、顺手记进自己的清单——这个过程本身就是经验积累。我见过不少人刚接触 adb 时觉得帮助文档太难读其实只要按照“先总览、再分组、后深挖”的顺序走很快就能上手。如果你觉得自己对 adb 的认知还停留在复制粘贴的阶段我建议你今晚就做一件事打开终端输入adb help把输出从头到尾过一遍把所有自己不认识的命令标注出来。然后挨个搜索它们的作用动手试一次。这比你花一晚上背十个教程里的命令要扎实得多。最后分享一个我自己的小习惯遇到新设备或者新的模拟器环境我的第一件事永远是跑一次adb devices然后紧接着看一眼adb get-state。这两条命令一条确认设备在不在一条确认设备状态正不正常。等到设备彻底就绪再去搞安装、调试、日志这些后续工作。每次这样操作几乎不会遇到“做到一半才发现设备没连上”的尴尬局面。