Adb全称 Android Debug Bridge是我日常排查安卓设备问题、做自动化测试时最常打开的一套命令行工具。很多人对它的印象停留在“用数据线连手机装个包”但其实 Adb 能做的事远超预期抓崩溃日志、模拟点击、查看系统状态、批量操作多台设备样样都行。这篇文章我想把 Adb 的基本概念、常用命令、实战场景和我踩过的坑全部梳理一遍给刚接触安卓调试、或者想系统学习命令行调试的朋友一份可以直接照着用的参考。我只讲实操和原理不堆没用的概念。看完之后你至少能做到一台新设备拿到手从开启调试到抓取崩溃日志、跑一轮自动化操作全程不用依赖图形界面工具。1. Adb 到底是什么一条贯穿电脑与安卓设备的“调试专用通道”1.1 名称拆解与三层工作结构Adb 的英文全称是 Android Debug Bridge翻译过来就是“安卓调试桥”。“桥”这个字非常关键它说明 Adb 不是直接在电脑和设备之间开一条裸通道而是通过一个中转机制来转发命令。整套 Adb 由三部分组成电脑端的 client也就是你在终端里敲下的adb命令本身它负责把你的意图翻译成请求。电脑端的 server一个后台守护进程默认监听本机的某个内部端口负责管理当前连接的所有设备。你会发现第一次执行adb devices时耗时较长就是在启动 server。设备端的 adbd安卓系统里内置的一个守护进程负责接收电脑端请求并在设备上真正执行。整个过程可以这么理解你client给中转站server说“帮我把这个文件送到 3 号收货点”中转站调配车辆设备端的 adbd 就是那个签收快递的工作人员签收完再回传一个执行业务的结果给你。为什么要引入 server 这一层因为实际场景里你可能会同时插着两三台手机还可能混着无线连接设备随时断开重连server 统一维护设备列表能省去很多麻烦。当你拔掉数据线再插回来、或者遇到设备状态异常的时候我第一反应经常是直接重启 server而不是重新插线。1.2 Adb 能做什么远不止“装个 App”Adb 的核心能力可以归纳为四类文件传输把电脑上的安装包、脚本、图片推到手机或者把手机里的日志、截屏拉回电脑。远程命令执行不碰手机屏幕在电脑终端里直接操作手机系统比如查看 CPU 占用、修改系统设置、模拟按键。信息采集抓取系统日志、崩溃日志、内存占用、电量状态、当前顶层 Activity 等是排查问题的第一手数据来源。自动化控制模拟点击、滑动、输入文本配合脚本可以实现简单的自动化回归测试。所以适合 Adb 的人群很广安卓开发、测试工程师、做自动化脚本的、搞系统定制的、甚至只是想把手机里的截图快速导出来的普通用户都值得了解一下。它最大的价值在于把“人盯着屏幕手动操作”这件事变成了一行行可重复执行、可记录的命令效率完全不一样。2. 从零搭建调试环境连接失败的几个典型根因与排查路径2.1 安装不需要装完整的图形开发环境很多朋友以为要用 Adb 必须装整套开发 IDE其实只需要一个platform-tools工具包就够了。把压缩包解压到你习惯的目录然后把里面的目录路径加入系统环境变量重新打开终端执行adb version能看到版本号说明安装成功。这里有个容易忽略的细节Adb 版本要尽量新但也要兼容老设备。新版 platform-tools 通常能向下兼容但如果你的测试机系统版本很老偶尔会遇到 adbd 和 host 端协议不匹配的情况表现就是设备一直 offline。遇到这种情况先把两端工具都升到最新不行再考虑降级排查。在 Windows 上连接部分设备可能还需要安装对应的 USB 驱动否则设备在系统里不会被识别。大多数现代设备使用系统自带驱动就能工作不过真遇到不识别的情况优先换 USB 口和数据线然后去设备厂商官网找驱动最后再考虑第三方驱动助手。别一上来就装各类手机助手那些工具往往自带一堆后台服务反而干扰 Adb 的正常连接。2.2 第一次 USB 连接的完整流程第一次连设备你大概率会栽在“开发者选项”上。简单说下流程打开手机“设置”找到“关于手机/平板电脑”连续点击“版本号”7 次左右直到提示“您已进入开发者模式”。回到设置主页进入“开发者选项”打开“USB 调试”开关。用数据线连接电脑手机上弹窗“允许 USB 调试吗”勾选“始终允许”点击确定。电脑终端执行adb devices出现serial_number device就是成功。如果没有弹窗先看看手机通知栏里的 USB 连接方式切到“文件传输MTP”模式往往能触发弹窗。还有两种情况我经常遇到一是数据线只有充电能力没有数据信号二是因为某些系统对弹窗授权做了一重“调试指纹”换设备后需要重新确认。2.3 设备状态怎么看用一张表盘清连接问题adb devices输出的状态有几种每种含义和处理方式完全不同状态含义处理方式device正常连接可以执行命令无offline设备连接异常无法通信重启 Adb server、重插数据线、检查线材unauthorized设备未授权电脑端被拒绝在手机上确认 USB 调试弹窗no permissions电脑端没有操作权限检查驱动、更换 USB 口、在 Linux 下检查 udev 规则无设备显示链路没通检查数据线、USB 模式、驱动注意unauthorized和offline是新手最容易搞混的。unauthorized是手机端没点“允许”此时执行命令会被拒offline代表物理链路通了但协议层握手失败。遇到unauthorized直接在手机上把弹窗点掉就行遇到offline先执行adb kill-server再执行adb start-server重插数据线如果还不行就换根线。2.4 无线调试摆脱数据线束缚有线连接虽然可靠但调试过程中手机不能长时间占用充电口很多场景下你还需要边跑自动化边观察屏幕。无线连接就能解决这个问题。基础操作流程是这样的手机通过 USB 连接电脑执行adb tcpip 5555让设备开启 5555 端口的无线调试服务。拔掉 USB 数据线。查看手机在局域网内的 IP 地址假设是192.168.1.100执行adb connect 192.168.1.100:5555。再次执行adb devices确认设备状态为device。注意事项也不少手机和电脑必须处于同一网段手机休眠可能导致连接断开IP 地址变化了要重新adb connect。无线连接不如有线稳定如果要做长时间的自动化测试我个人建议还是用有线能少很多莫名其妙的断连问题。Android 11 及以上还有更完善的无线调试配对机制可以做到完全不需要 USB但牺牲了一定的灵活性基础方案已经完全够用。3. 高频命令速查按日常场景记忆这一套就够了3.1 设备管理命令先学会和多设备打交道设备管理是 Adb 的基石所有操作都建立在正确识别设备之上。先记住这一组adb devices # 列出当前所有设备 adb devices -l # 显示更详细的信息包含型号和序列号 adb get-state # 获取单一设备状态 adb kill-server # 杀掉 Adb server adb start-server # 启动 Adb server adb -s serial shell # 指定某台设备执行命令-s参数是我在多设备调试时最依赖的选项。比如同时连着两台设备不指定设备执行命令会报错more than one device/emulator加-s精确指定序列号就行。3.2 应用安装、卸载与包管理安卓开发测试里最频繁的操作就是装包、卸包、看包。高频命令adb install app.apk # 全新安装 adb install -r app.apk # 覆盖安装保留数据 adb install -d app.apk # 允许降级安装 adb install -t app.apk # 安装测试包 adb uninstall com.example.app # 卸载应用 adb uninstall -k com.example.app # 卸载但保留数据 adb shell pm list packages -3 # 只列出第三方应用包名 adb shell pm path com.example.app # 查看应用安装路径-r这个参数特别常用。很多应用不允许覆盖安装时降版本如果老包是 debug 签名、新包是 release 签名就会报INSTALL_FAILED_UPDATE_INCOMPATIBLE加上-r再试往往能解决。装包失败时别急着全卸先看错误信息大部分是签名不一致、版本号冲突或者 SDK 版本不匹配。3.3 文件传输桥接电脑与设备文件传输是排查问题时最必要的操作之一从设备上拉日志、往设备里推测试文件全靠下面两个命令adb push 本地文件 设备路径 # 电脑文件推到设备 adb pull 设备文件 本地目录 # 设备文件拉到电脑比如我想把手机崩溃时的日志保存到电脑adb pull /sdcard/crash_log.txt ./注意路径权限问题。设备上的/sdcard/目录一般应用可写但/data/路径很多情况下普通用户无权读取需要 root 后才有权限。传输大文件时尽量用有线连接无线连接受网络环境影响较大速度不太稳定。3.4 日志查看logcat 的基本用法logcat 是 Adb 排查疑难问题最锋利的工具。基础用法adb logcat # 实时输出日志到终端 adb logcat -d # 一次性输出当前缓冲区日志然后退出 adb logcat -c # 清空日志缓冲区 adb logcat -b crash # 只看崩溃缓冲区 adb logcat -s TAG # 按标签过滤 adb logcat --pid进程ID # 只看某个进程的日志实际排查时我推荐的标准套路是先adb logcat -c清空然后手动复现问题最后adb logcat -d -b crash crash.txt一次性导出崩溃日志。直接实时滚动抓日志容易错过关键信息而且日志打印量极大窗口滚动速度快到看不清导出到文件里再分析会从容得多。3.5 截屏、录屏与模拟输入这是自动化测试最常用的三类命令直接上例子adb shell screencap -p /sdcard/screen.png # 截屏保存到设备 adb pull /sdcard/screen.png ./ # 拉到电脑 adb shell screenrecord --time-limit 10 /sdcard/demo.mp4 # 录屏10秒 adb shell input tap 500 800 # 模拟点击坐标 (500, 800) adb shell input swipe 500 1500 500 500 300 # 模拟滑动300ms完成 adb shell input text hello # 在焦点输入框输入文本 adb shell input keyevent 4 # 模拟返回键截屏还有一种方式更高效adb exec-out screencap -p screen.png直接跳过设备存储直接输出到电脑省了一步pull。不过/sdcard路径不存在或者权限异常时走设备存储再拉取更可靠。常见 keyevent 数值我也列一张表备查按键数值说明HOME3回到桌面BACK4返回POWER26电源键VOLUME_UP24音量加VOLUME_DOWN25音量减ENTER66确认MENU82菜单键4. 真机调试实战抓崩溃日志和自动化操作的完整套路4.1 场景一复现崩溃并抓取有效日志崩溃问题最难的不是修而是现场没了。以下是一套可靠的崩溃日志抓取流程# 1. 清空日志缓冲区保证接下来只记录本次复现 adb logcat -c # 2. 启动目标应用并操作让它崩一次 adb shell am start -n com.example.app/.MainActivity # 3. 复现崩溃后立刻导出崩溃缓冲区 adb logcat -d -b crash crash_20250312.txt拿到crash_20250312.txt后怎么读重点看这几部分先找FATAL EXCEPTION字样这是崩溃发生的主线程异常标记。看Process: com.example.app, PID: 12345确认是哪个进程挂了。看Caused by:后面的异常链这通常指向根本原因。再看堆栈顶部的方法调用结合代码定位崩溃点。一个小技巧如果崩溃发生在子线程FATAL EXCEPTION后面会跟线程名但-b crash缓冲区一般能完整保留崩溃现场。别只抓 main 缓冲区crash 缓冲区更可靠。崩溃发生后系统很快会清理现场所以复现成功后要立刻 dump拖得越久有效信息越少。4.2 场景二查看内存与 CPU 状态应用卡顿、闪退、OOM 问题往往需要看内存。常用命令adb shell dumpsys meminfo com.example.app adb shell top -n 1 adb shell dumpsys activity processes | head -n 50dumpsys meminfo输出里最值得关注的是 Total PSS 这一行。PSS 是实际物理内存的预估占用比单纯 RSS 更贴近真实。判断是否存在内存泄漏方法是对同一个页面反复进出多次每次回到稳定状态后记录 Total PSS如果数值不断攀升不回落就需要怀疑泄漏了。top -n 1能看实时 CPU 占用。注意有些安卓系统版本对top命令做了权限限制看不到其他进程的 CPU 占用这时可以用adb shell top -n 1 -m 10只看前十个进程或者配合dumpsys cpuinfo查看。4.3 场景三用脚本跑一轮自动化回归自动化回归是 Adb 最出彩的场景。比如我想对某测试 App 做 10 轮基础回归启动、点固定按钮、滑动列表、截屏记录。脚本长这样#!/bin/bash # 自动化回归脚本包名和坐标请按实际项目替换 PACKAGEcom.example.test ACTIVITYcom.example.test.MainActivity mkdir -p shots for i in {1..10} do echo Round $i adb shell am force-stop $PACKAGE adb shell am start -W -n $PACKAGE/$ACTIVITY sleep 2 adb shell input tap 500 900 sleep 1 adb shell input swipe 500 1500 500 500 300 sleep 3 adb shell screencap -p /sdcard/round_$i.png adb pull /sdcard/round_$i.png ./shots/ adb shell input keyevent 4 done这个脚本能用但有几个坑要提前避开坐标是硬编码的换屏幕分辨率不同设备就得改。最好先手动执行adb shell input tap试出准确坐标。am start -W会阻塞到启动流程结束并输出启动耗时自动化里既能当等待机制又能拿到性能数据。如果不需要精确同步用sleep代替am start -W也可以但脚本稳定性会差一些。4.4 场景四清理应用数据与重启测试很多问题在“残余数据”下才能复现比如登录态异常、崩溃后残留缓存。这时需要清理数据命令用途adb shell pm clear com.example.app清除应用全部数据adb shell am force-stop com.example.app强制停止应用adb reboot重启设备adb shell svc power stayon true充电时保持唤醒测试常用pm clear会把应用私有目录全部清空等于恢复到刚安装状态。如果只是想重置部分数据别用它否则测试数据全没了可能反而误事。5. 进阶能力adb shell 里藏着另一个 Linux 环境5.1 进入 shell 后的基本操作执行adb shell后你会进入设备上的 Linux 环境很多操作不需要额外工具就能完成adb shell ls /data/data ps -A | grep com.example cat /proc/cpuinfo cat /proc/meminfo df -h du -sh /sdcard/Android/data这里有个概念要搞清楚手机里的/data/data目录是应用私有数据区普通 shell 用户看不到大部分内容只有 root 后才能完全访问。所以如果你不是做深度分析把重点放在应用允许访问的目录和系统公共信息上更实用。5.2 查看系统状态与修改系统设置调试时需要确认设备型号、系统版本、电池状态、屏幕状态uname 和 getprop 是你的好朋友adb shell getprop ro.build.version.release adb shell getprop ro.product.model adb shell getprop ro.build.version.sdk adb shell dumpsys battery adb shell dumpsys power | grep -E mWakefulness|mScreenOn比如想模拟屏幕常亮场景测试耗电可以用adb shell svc power stayon true这个命令在自动化测试里非常有价值设备在长时间运行时不会因为锁屏中断脚本。5.3 端口转发让设备访问电脑上的服务如果设备上某个 App 需要访问电脑上跑着的 Web 服务而电脑和手机不在同一网段可以借助 Adb 的端口转发来完成# 把设备上的 8080 端口转发到电脑的 8080 端口 adb forward tcp:8080 tcp:8080 # 反向让设备通过 USB 直接访问电脑上监听的服务 adb reverse tcp:8081 tcp:8080adb forward是电脑端口映射到设备adb reverse是设备端口映射到电脑。开发调试 Web 页面、本地接口联调时这两个命令能省下大量配置网络环境的时间。5.4 授权管理与系统应用操作调试中偶尔需要授予应用一些运行时权限比如定位、通知adb shell pm grant com.example.app android.permission.ACCESS_FINE_LOCATION adb shell pm revoke com.example.app android.permission.ACCESS_FINE_LOCATION adb shell appops set com.example.app android:access_fine_location allow注意pm grant只能授予声明过该权限的应用而且部分受限权限即使声明也无法在 adb 里直接授予具体要看系统实现。这类命令只适合在测试机上使用目的也是为了正常调试不要把它用在规避用户授权的场合。5.5 截取系统 UI 层级UI 自动化测试经常需要知道当前界面上有哪些元素、坐标是多少虽然传统方案会借助各类 UI 自动化框架但纯 Adb 也有一个轻量办法adb shell uiautomator dump /sdcard/ui.xml adb pull /sdcard/ui.xml ./这个命令会把当前界面的控件层级和坐标信息导出成 XML。打开 XML 后能查看到每个可点击控件的 bounds 属性比如node text登录 bounds[240,960][480,1080]/中心坐标就是(360, 1020)这比盲猜坐标准确太多。我的习惯是先 dump 一次 UI再根据 XML 里的 bounds 计算点击坐标写自动化脚本的命中率会大幅提升。6. 经验与踩坑如何把 Adb 用成团队的基础设施6.1 我踩过的几个坑希望你别再踩第一坑数据线只支持充电不支持数据传输。这根线连上后adb devices永远看不到设备换一根正常的数据线立刻就好。所以团队里多备几条确认能传输数据的线能省很多排查时间。第二坑adb server版本和设备端 adbd 版本不匹配。有时台式机上的platform-tools用了两三年没更新连新设备就一直 offline或者报device unauthorized。不要把adb命令放进某个老旧的集成包里一直不动定期升级。第三坑无线调试 IP 变了连不上。手机 DHCP 分配的地址经常变每次重连前先在手机的设置里看一眼当前 IP别凭记忆连接。给测试机设置固定 IP 能彻底解决。第四坑input text只能输入英文字符和数字要输入中文需要先用剪贴板工具把中文复制到设备剪贴板再通过adb shell am broadcast模拟粘贴操作。很多初学自动化的人在这里卡住。第五坑部分系统默认关闭了“USB 调试安全设置”导致input命令模拟的点击事件被拦截。需要在开发者选项里找到“USB 调试安全设置”并授权否则自动化脚本点了没反应。6.2 把常用命令封装成脚本日常调试完全可以写进函数里。我习惯在电脑上维护一个小脚本库比如把常用操作封装成别名alias adadb devices alias aladb logcat -v time alias ashadb shell alias ashootadb exec-out screencap -p screen.png更进一步我会写一个函数自动抓取指定设备的崩溃日志function adb_crash() { adb -s $1 logcat -d -b crash crash_$(date %Y%m%d_%H%M%S).txt echo 崩溃日志已保存 }执行adb_crash serial就能快速收集一台设备上的崩溃日志多设备并行时非常省事。脚本库维护好之后新同事上手也快你不用反复口头解释“先清日志再复现再导出”直接发个脚本链接就行。6.3 安全与规范调试工具要守边界Adb 权限极大能安装应用、能拉数据、能改系统设置所以在公共环境里使用一定要克制不要随意在他人设备上执行pm clear或am force-stop会丢数据。USB 调试开关用完后建议关闭尤其是连接公共电脑时。生产设备上不要执行危险命令比如随意重置应用、禁用系统组件。自动化脚本里涉及账号密码的输入要有明确的授权和脱敏措施不要泄露。工具本身没有对错关键看怎么用。Adb 强就强在把所有操作都变成可记录、可复现的命令行这也是我推荐大家认真学它的原因。最后再分享一个我的习惯我会把每台测试机的序列号、IP、主要包名记在一个本地小清单里脚本里全部用adb -s精确指定设备。这样多设备并行跑测试时不会弄混出问题也能快速定位是哪台机器。Adb 这套工具从入门到熟练真没有太多玄学多跑几次命令行、踩过几个坑自然就顺了。希望这篇文章能帮你把第一脚踩稳。 
长河君 · 2026/10/22 6:34:10 · 阅读 1.2k ADB调试完全指南：从基础原理到自动化实战
Adb全称 Android Debug Bridge是我日常排查安卓设备问题、做自动化测试时最常打开的一套命令行工具。很多人对它的印象停留在“用数据线连手机装个包”但其实 Adb 能做的事远超预期抓崩溃日志、模拟点击、查看系统状态、批量操作多台设备样样都行。这篇文章我想把 Adb 的基本概念、常用命令、实战场景和我踩过的坑全部梳理一遍给刚接触安卓调试、或者想系统学习命令行调试的朋友一份可以直接照着用的参考。我只讲实操和原理不堆没用的概念。看完之后你至少能做到一台新设备拿到手从开启调试到抓取崩溃日志、跑一轮自动化操作全程不用依赖图形界面工具。1. Adb 到底是什么一条贯穿电脑与安卓设备的“调试专用通道”1.1 名称拆解与三层工作结构Adb 的英文全称是 Android Debug Bridge翻译过来就是“安卓调试桥”。“桥”这个字非常关键它说明 Adb 不是直接在电脑和设备之间开一条裸通道而是通过一个中转机制来转发命令。整套 Adb 由三部分组成电脑端的 client也就是你在终端里敲下的adb命令本身它负责把你的意图翻译成请求。电脑端的 server一个后台守护进程默认监听本机的某个内部端口负责管理当前连接的所有设备。你会发现第一次执行adb devices时耗时较长就是在启动 server。设备端的 adbd安卓系统里内置的一个守护进程负责接收电脑端请求并在设备上真正执行。整个过程可以这么理解你client给中转站server说“帮我把这个文件送到 3 号收货点”中转站调配车辆设备端的 adbd 就是那个签收快递的工作人员签收完再回传一个执行业务的结果给你。为什么要引入 server 这一层因为实际场景里你可能会同时插着两三台手机还可能混着无线连接设备随时断开重连server 统一维护设备列表能省去很多麻烦。当你拔掉数据线再插回来、或者遇到设备状态异常的时候我第一反应经常是直接重启 server而不是重新插线。1.2 Adb 能做什么远不止“装个 App”Adb 的核心能力可以归纳为四类文件传输把电脑上的安装包、脚本、图片推到手机或者把手机里的日志、截屏拉回电脑。远程命令执行不碰手机屏幕在电脑终端里直接操作手机系统比如查看 CPU 占用、修改系统设置、模拟按键。信息采集抓取系统日志、崩溃日志、内存占用、电量状态、当前顶层 Activity 等是排查问题的第一手数据来源。自动化控制模拟点击、滑动、输入文本配合脚本可以实现简单的自动化回归测试。所以适合 Adb 的人群很广安卓开发、测试工程师、做自动化脚本的、搞系统定制的、甚至只是想把手机里的截图快速导出来的普通用户都值得了解一下。它最大的价值在于把“人盯着屏幕手动操作”这件事变成了一行行可重复执行、可记录的命令效率完全不一样。2. 从零搭建调试环境连接失败的几个典型根因与排查路径2.1 安装不需要装完整的图形开发环境很多朋友以为要用 Adb 必须装整套开发 IDE其实只需要一个platform-tools工具包就够了。把压缩包解压到你习惯的目录然后把里面的目录路径加入系统环境变量重新打开终端执行adb version能看到版本号说明安装成功。这里有个容易忽略的细节Adb 版本要尽量新但也要兼容老设备。新版 platform-tools 通常能向下兼容但如果你的测试机系统版本很老偶尔会遇到 adbd 和 host 端协议不匹配的情况表现就是设备一直 offline。遇到这种情况先把两端工具都升到最新不行再考虑降级排查。在 Windows 上连接部分设备可能还需要安装对应的 USB 驱动否则设备在系统里不会被识别。大多数现代设备使用系统自带驱动就能工作不过真遇到不识别的情况优先换 USB 口和数据线然后去设备厂商官网找驱动最后再考虑第三方驱动助手。别一上来就装各类手机助手那些工具往往自带一堆后台服务反而干扰 Adb 的正常连接。2.2 第一次 USB 连接的完整流程第一次连设备你大概率会栽在“开发者选项”上。简单说下流程打开手机“设置”找到“关于手机/平板电脑”连续点击“版本号”7 次左右直到提示“您已进入开发者模式”。回到设置主页进入“开发者选项”打开“USB 调试”开关。用数据线连接电脑手机上弹窗“允许 USB 调试吗”勾选“始终允许”点击确定。电脑终端执行adb devices出现serial_number device就是成功。如果没有弹窗先看看手机通知栏里的 USB 连接方式切到“文件传输MTP”模式往往能触发弹窗。还有两种情况我经常遇到一是数据线只有充电能力没有数据信号二是因为某些系统对弹窗授权做了一重“调试指纹”换设备后需要重新确认。2.3 设备状态怎么看用一张表盘清连接问题adb devices输出的状态有几种每种含义和处理方式完全不同状态含义处理方式device正常连接可以执行命令无offline设备连接异常无法通信重启 Adb server、重插数据线、检查线材unauthorized设备未授权电脑端被拒绝在手机上确认 USB 调试弹窗no permissions电脑端没有操作权限检查驱动、更换 USB 口、在 Linux 下检查 udev 规则无设备显示链路没通检查数据线、USB 模式、驱动注意unauthorized和offline是新手最容易搞混的。unauthorized是手机端没点“允许”此时执行命令会被拒offline代表物理链路通了但协议层握手失败。遇到unauthorized直接在手机上把弹窗点掉就行遇到offline先执行adb kill-server再执行adb start-server重插数据线如果还不行就换根线。2.4 无线调试摆脱数据线束缚有线连接虽然可靠但调试过程中手机不能长时间占用充电口很多场景下你还需要边跑自动化边观察屏幕。无线连接就能解决这个问题。基础操作流程是这样的手机通过 USB 连接电脑执行adb tcpip 5555让设备开启 5555 端口的无线调试服务。拔掉 USB 数据线。查看手机在局域网内的 IP 地址假设是192.168.1.100执行adb connect 192.168.1.100:5555。再次执行adb devices确认设备状态为device。注意事项也不少手机和电脑必须处于同一网段手机休眠可能导致连接断开IP 地址变化了要重新adb connect。无线连接不如有线稳定如果要做长时间的自动化测试我个人建议还是用有线能少很多莫名其妙的断连问题。Android 11 及以上还有更完善的无线调试配对机制可以做到完全不需要 USB但牺牲了一定的灵活性基础方案已经完全够用。3. 高频命令速查按日常场景记忆这一套就够了3.1 设备管理命令先学会和多设备打交道设备管理是 Adb 的基石所有操作都建立在正确识别设备之上。先记住这一组adb devices # 列出当前所有设备 adb devices -l # 显示更详细的信息包含型号和序列号 adb get-state # 获取单一设备状态 adb kill-server # 杀掉 Adb server adb start-server # 启动 Adb server adb -s serial shell # 指定某台设备执行命令-s参数是我在多设备调试时最依赖的选项。比如同时连着两台设备不指定设备执行命令会报错more than one device/emulator加-s精确指定序列号就行。3.2 应用安装、卸载与包管理安卓开发测试里最频繁的操作就是装包、卸包、看包。高频命令adb install app.apk # 全新安装 adb install -r app.apk # 覆盖安装保留数据 adb install -d app.apk # 允许降级安装 adb install -t app.apk # 安装测试包 adb uninstall com.example.app # 卸载应用 adb uninstall -k com.example.app # 卸载但保留数据 adb shell pm list packages -3 # 只列出第三方应用包名 adb shell pm path com.example.app # 查看应用安装路径-r这个参数特别常用。很多应用不允许覆盖安装时降版本如果老包是 debug 签名、新包是 release 签名就会报INSTALL_FAILED_UPDATE_INCOMPATIBLE加上-r再试往往能解决。装包失败时别急着全卸先看错误信息大部分是签名不一致、版本号冲突或者 SDK 版本不匹配。3.3 文件传输桥接电脑与设备文件传输是排查问题时最必要的操作之一从设备上拉日志、往设备里推测试文件全靠下面两个命令adb push 本地文件 设备路径 # 电脑文件推到设备 adb pull 设备文件 本地目录 # 设备文件拉到电脑比如我想把手机崩溃时的日志保存到电脑adb pull /sdcard/crash_log.txt ./注意路径权限问题。设备上的/sdcard/目录一般应用可写但/data/路径很多情况下普通用户无权读取需要 root 后才有权限。传输大文件时尽量用有线连接无线连接受网络环境影响较大速度不太稳定。3.4 日志查看logcat 的基本用法logcat 是 Adb 排查疑难问题最锋利的工具。基础用法adb logcat # 实时输出日志到终端 adb logcat -d # 一次性输出当前缓冲区日志然后退出 adb logcat -c # 清空日志缓冲区 adb logcat -b crash # 只看崩溃缓冲区 adb logcat -s TAG # 按标签过滤 adb logcat --pid进程ID # 只看某个进程的日志实际排查时我推荐的标准套路是先adb logcat -c清空然后手动复现问题最后adb logcat -d -b crash crash.txt一次性导出崩溃日志。直接实时滚动抓日志容易错过关键信息而且日志打印量极大窗口滚动速度快到看不清导出到文件里再分析会从容得多。3.5 截屏、录屏与模拟输入这是自动化测试最常用的三类命令直接上例子adb shell screencap -p /sdcard/screen.png # 截屏保存到设备 adb pull /sdcard/screen.png ./ # 拉到电脑 adb shell screenrecord --time-limit 10 /sdcard/demo.mp4 # 录屏10秒 adb shell input tap 500 800 # 模拟点击坐标 (500, 800) adb shell input swipe 500 1500 500 500 300 # 模拟滑动300ms完成 adb shell input text hello # 在焦点输入框输入文本 adb shell input keyevent 4 # 模拟返回键截屏还有一种方式更高效adb exec-out screencap -p screen.png直接跳过设备存储直接输出到电脑省了一步pull。不过/sdcard路径不存在或者权限异常时走设备存储再拉取更可靠。常见 keyevent 数值我也列一张表备查按键数值说明HOME3回到桌面BACK4返回POWER26电源键VOLUME_UP24音量加VOLUME_DOWN25音量减ENTER66确认MENU82菜单键4. 真机调试实战抓崩溃日志和自动化操作的完整套路4.1 场景一复现崩溃并抓取有效日志崩溃问题最难的不是修而是现场没了。以下是一套可靠的崩溃日志抓取流程# 1. 清空日志缓冲区保证接下来只记录本次复现 adb logcat -c # 2. 启动目标应用并操作让它崩一次 adb shell am start -n com.example.app/.MainActivity # 3. 复现崩溃后立刻导出崩溃缓冲区 adb logcat -d -b crash crash_20250312.txt拿到crash_20250312.txt后怎么读重点看这几部分先找FATAL EXCEPTION字样这是崩溃发生的主线程异常标记。看Process: com.example.app, PID: 12345确认是哪个进程挂了。看Caused by:后面的异常链这通常指向根本原因。再看堆栈顶部的方法调用结合代码定位崩溃点。一个小技巧如果崩溃发生在子线程FATAL EXCEPTION后面会跟线程名但-b crash缓冲区一般能完整保留崩溃现场。别只抓 main 缓冲区crash 缓冲区更可靠。崩溃发生后系统很快会清理现场所以复现成功后要立刻 dump拖得越久有效信息越少。4.2 场景二查看内存与 CPU 状态应用卡顿、闪退、OOM 问题往往需要看内存。常用命令adb shell dumpsys meminfo com.example.app adb shell top -n 1 adb shell dumpsys activity processes | head -n 50dumpsys meminfo输出里最值得关注的是 Total PSS 这一行。PSS 是实际物理内存的预估占用比单纯 RSS 更贴近真实。判断是否存在内存泄漏方法是对同一个页面反复进出多次每次回到稳定状态后记录 Total PSS如果数值不断攀升不回落就需要怀疑泄漏了。top -n 1能看实时 CPU 占用。注意有些安卓系统版本对top命令做了权限限制看不到其他进程的 CPU 占用这时可以用adb shell top -n 1 -m 10只看前十个进程或者配合dumpsys cpuinfo查看。4.3 场景三用脚本跑一轮自动化回归自动化回归是 Adb 最出彩的场景。比如我想对某测试 App 做 10 轮基础回归启动、点固定按钮、滑动列表、截屏记录。脚本长这样#!/bin/bash # 自动化回归脚本包名和坐标请按实际项目替换 PACKAGEcom.example.test ACTIVITYcom.example.test.MainActivity mkdir -p shots for i in {1..10} do echo Round $i adb shell am force-stop $PACKAGE adb shell am start -W -n $PACKAGE/$ACTIVITY sleep 2 adb shell input tap 500 900 sleep 1 adb shell input swipe 500 1500 500 500 300 sleep 3 adb shell screencap -p /sdcard/round_$i.png adb pull /sdcard/round_$i.png ./shots/ adb shell input keyevent 4 done这个脚本能用但有几个坑要提前避开坐标是硬编码的换屏幕分辨率不同设备就得改。最好先手动执行adb shell input tap试出准确坐标。am start -W会阻塞到启动流程结束并输出启动耗时自动化里既能当等待机制又能拿到性能数据。如果不需要精确同步用sleep代替am start -W也可以但脚本稳定性会差一些。4.4 场景四清理应用数据与重启测试很多问题在“残余数据”下才能复现比如登录态异常、崩溃后残留缓存。这时需要清理数据命令用途adb shell pm clear com.example.app清除应用全部数据adb shell am force-stop com.example.app强制停止应用adb reboot重启设备adb shell svc power stayon true充电时保持唤醒测试常用pm clear会把应用私有目录全部清空等于恢复到刚安装状态。如果只是想重置部分数据别用它否则测试数据全没了可能反而误事。5. 进阶能力adb shell 里藏着另一个 Linux 环境5.1 进入 shell 后的基本操作执行adb shell后你会进入设备上的 Linux 环境很多操作不需要额外工具就能完成adb shell ls /data/data ps -A | grep com.example cat /proc/cpuinfo cat /proc/meminfo df -h du -sh /sdcard/Android/data这里有个概念要搞清楚手机里的/data/data目录是应用私有数据区普通 shell 用户看不到大部分内容只有 root 后才能完全访问。所以如果你不是做深度分析把重点放在应用允许访问的目录和系统公共信息上更实用。5.2 查看系统状态与修改系统设置调试时需要确认设备型号、系统版本、电池状态、屏幕状态uname 和 getprop 是你的好朋友adb shell getprop ro.build.version.release adb shell getprop ro.product.model adb shell getprop ro.build.version.sdk adb shell dumpsys battery adb shell dumpsys power | grep -E mWakefulness|mScreenOn比如想模拟屏幕常亮场景测试耗电可以用adb shell svc power stayon true这个命令在自动化测试里非常有价值设备在长时间运行时不会因为锁屏中断脚本。5.3 端口转发让设备访问电脑上的服务如果设备上某个 App 需要访问电脑上跑着的 Web 服务而电脑和手机不在同一网段可以借助 Adb 的端口转发来完成# 把设备上的 8080 端口转发到电脑的 8080 端口 adb forward tcp:8080 tcp:8080 # 反向让设备通过 USB 直接访问电脑上监听的服务 adb reverse tcp:8081 tcp:8080adb forward是电脑端口映射到设备adb reverse是设备端口映射到电脑。开发调试 Web 页面、本地接口联调时这两个命令能省下大量配置网络环境的时间。5.4 授权管理与系统应用操作调试中偶尔需要授予应用一些运行时权限比如定位、通知adb shell pm grant com.example.app android.permission.ACCESS_FINE_LOCATION adb shell pm revoke com.example.app android.permission.ACCESS_FINE_LOCATION adb shell appops set com.example.app android:access_fine_location allow注意pm grant只能授予声明过该权限的应用而且部分受限权限即使声明也无法在 adb 里直接授予具体要看系统实现。这类命令只适合在测试机上使用目的也是为了正常调试不要把它用在规避用户授权的场合。5.5 截取系统 UI 层级UI 自动化测试经常需要知道当前界面上有哪些元素、坐标是多少虽然传统方案会借助各类 UI 自动化框架但纯 Adb 也有一个轻量办法adb shell uiautomator dump /sdcard/ui.xml adb pull /sdcard/ui.xml ./这个命令会把当前界面的控件层级和坐标信息导出成 XML。打开 XML 后能查看到每个可点击控件的 bounds 属性比如node text登录 bounds[240,960][480,1080]/中心坐标就是(360, 1020)这比盲猜坐标准确太多。我的习惯是先 dump 一次 UI再根据 XML 里的 bounds 计算点击坐标写自动化脚本的命中率会大幅提升。6. 经验与踩坑如何把 Adb 用成团队的基础设施6.1 我踩过的几个坑希望你别再踩第一坑数据线只支持充电不支持数据传输。这根线连上后adb devices永远看不到设备换一根正常的数据线立刻就好。所以团队里多备几条确认能传输数据的线能省很多排查时间。第二坑adb server版本和设备端 adbd 版本不匹配。有时台式机上的platform-tools用了两三年没更新连新设备就一直 offline或者报device unauthorized。不要把adb命令放进某个老旧的集成包里一直不动定期升级。第三坑无线调试 IP 变了连不上。手机 DHCP 分配的地址经常变每次重连前先在手机的设置里看一眼当前 IP别凭记忆连接。给测试机设置固定 IP 能彻底解决。第四坑input text只能输入英文字符和数字要输入中文需要先用剪贴板工具把中文复制到设备剪贴板再通过adb shell am broadcast模拟粘贴操作。很多初学自动化的人在这里卡住。第五坑部分系统默认关闭了“USB 调试安全设置”导致input命令模拟的点击事件被拦截。需要在开发者选项里找到“USB 调试安全设置”并授权否则自动化脚本点了没反应。6.2 把常用命令封装成脚本日常调试完全可以写进函数里。我习惯在电脑上维护一个小脚本库比如把常用操作封装成别名alias adadb devices alias aladb logcat -v time alias ashadb shell alias ashootadb exec-out screencap -p screen.png更进一步我会写一个函数自动抓取指定设备的崩溃日志function adb_crash() { adb -s $1 logcat -d -b crash crash_$(date %Y%m%d_%H%M%S).txt echo 崩溃日志已保存 }执行adb_crash serial就能快速收集一台设备上的崩溃日志多设备并行时非常省事。脚本库维护好之后新同事上手也快你不用反复口头解释“先清日志再复现再导出”直接发个脚本链接就行。6.3 安全与规范调试工具要守边界Adb 权限极大能安装应用、能拉数据、能改系统设置所以在公共环境里使用一定要克制不要随意在他人设备上执行pm clear或am force-stop会丢数据。USB 调试开关用完后建议关闭尤其是连接公共电脑时。生产设备上不要执行危险命令比如随意重置应用、禁用系统组件。自动化脚本里涉及账号密码的输入要有明确的授权和脱敏措施不要泄露。工具本身没有对错关键看怎么用。Adb 强就强在把所有操作都变成可记录、可复现的命令行这也是我推荐大家认真学它的原因。最后再分享一个我的习惯我会把每台测试机的序列号、IP、主要包名记在一个本地小清单里脚本里全部用adb -s精确指定设备。这样多设备并行跑测试时不会弄混出问题也能快速定位是哪台机器。Adb 这套工具从入门到熟练真没有太多玄学多跑几次命令行、踩过几个坑自然就顺了。希望这篇文章能帮你把第一脚踩稳。