企业官网建设流程全解析

1. 为什么要在Windows下专门整理一套ADB命令

1.1 排查、调试、自动化，ADB到底在解决什么问题

干Android开发和测试这行，Windows系统几乎是绕不开的日常环境。我身边有不少同事从Mac切到Windows之后，第一件事就是问：ADB命令在Windows下怎么用？为什么我敲同样的命令总是报错？这篇文章不是官方文档的搬运，而是把我在Windows下这些年高频使用的ADB命令完整梳理了一遍，从环境配置到应用管理、日志抓取、自动化控制，再到Windows特有的坑，一次讲清楚。适合刚入门的新人，也适合想把自己日常操作规范化的老手。

先把概念说透。ADB全称Android Debug Bridge，翻译过来就是“安卓调试桥”，它本质上是电脑和Android设备之间的一条双向通信通道。手机上跑的守护进程adbd、电脑端敲的adb客户端、中间负责转发的adb server，三者配合，才能让你在电脑上直接操作手机。很多人只用过安装APK和看日志，其实ADB能做的事情远不止这些：截屏、录屏、模拟点击、修改系统设置、批量安装卸载、抓取崩溃日志、甚至跑自动化测试脚本，都能通过命令行完成。

Windows用户和Linux/macOS用户面对的是同一套ADB，但在实际使用中会遇到不少平台特有差异。比如路径分隔符不同，cmd的转义规则不同，命令输出中文可能乱码，USB驱动需要额外安装，偶尔还会碰到设备端口被占用、文件管理器锁定APK文件这种Windows专属问题。这些坑单独看都不大，但每一条都能卡住你半小时。所以我一直建议Windows下的ADB操作要单独有一套打法，不要照搬Linux教程。

1.2 Windows和Linux/macOS的差异，真的不只是命令提示符

刚开始用Windows做Android调试的人，最容易踩的坑是拿Linux的思维来敲命令。Shell不一样了，很多管道命令没法直接用。比如在Linux上过滤adb logcat输出，你习惯写adb logcat | grep Error，Windows自带的cmd不支持grep，要用findstr替代，adb logcat | findstr Error。在PowerShell里虽然可以用Select-String，但老同事的批处理脚本基本都是基于cmd的，交接过来还得兼容。

再说路径问题。Windows的路径分隔符是反斜杠\，这在ADB命令里很容易引起混乱。比如你要把电脑上的D:\test\app.apk推到设备里，直接写adb push D:\test\app.apk /sdcard/，看起来没问题，但如果目录名或者文件名里带了空格，又需要加引号，引号加不好就经常报错；路径里如果有特殊字符，cmd还会强行尝试转义。更麻烦的是ADB本身在Windows下解析反斜杠时可能出现歧义，有时候\sdcard\也能用，有时候又必须写成/sdcard/，我自己的习惯是：设备端路径一律用正斜杠，电脑端路径尽量用引号包住，这样踩坑最少。

再有就是驱动问题。Linux和macOS对Android设备的USB访问通常开箱即用，Windows上经常出现“设备管理器里能看到手机，但adb死活不识别”的情况。这种情况多半是驱动没有正确安装，或者驱动版本太老。Google官方提供了统一的USB驱动包，也可以在设备管理器里手动更新驱动，很多国产手机品牌还有自己的助手工具，装完后会自动把ADB驱动一起装上。如果你需要在多台电脑之间切换，建议把platform-tools目录固定在一个稳定路径，并把该路径加入环境变量PATH，后面所有操作都会顺畅很多。

1.3 环境搭建：从下载到adb version一次跑通

ADB工具的安装非常简单，本质就是下载Google官方的platform-tools压缩包，解压后把目录加进环境变量。不需要安装什么重量级IDE，也不需要额外配置Java环境，Windows下这一步做完就足够了。

具体步骤是：先从Android开发者官网下载Windows版本的platform-tools，下载完是一个zip包，解压到你习惯的目录，比如D:\platform-tools。然后右键“此电脑”->“属性”->“高级系统设置”->“环境变量”，在“系统变量”里找到Path，编辑，新增一行D:\platform-tools。保存后打开一个新的cmd窗口，输入adb version，能看到版本号输出就说明环境OK了。

提示：如果你是在公司电脑上操作，可能没有修改系统环境变量的权限。这种情况可以不用改全局变量，直接在cmd里先执行cd /d D:\platform-tools切到工具目录，再运行ADB命令，效果完全一样。或者写一个bat脚本，每次自动切目录再执行命令。

下载的时候我建议认准官方渠道，不要随便在网上找“ADB一键安装包”，因为你不知道里面捆绑了什么。官方platform-tools的体积不大，每次更新也方便，直接替换整个目录就行。版本方面，老版本ADB在新手机上经常出现连不上、命令不支持的问题，尽量保持最新版本。

2. 设备连接与状态查看：所有后续操作的前置条件

2.1 adb devices的输出怎么看：三种状态和对应处理

环境配好之后，第一件事就是确认设备有没有被识别。把手机用USB线连到电脑，手机上如果弹出“允许USB调试吗”的窗口，勾选“始终允许”，点确定。然后在cmd里输入：

adb devices

正常情况会输出类似这样的内容：

List of devices attached emulator-5554 device R58M12345ABC device

第一列是设备序列号，第二列是状态。这里有个很多人忽略的点：状态不只是device一种。常见状态有device、unauthorized、offline，它们的含义和应对方式完全不同。

我见过太多同事卡在unauthorized状态半天，以为是驱动问题，来回重装驱动，实际就是手机屏幕上那个授权弹窗没注意到。现在的国产手机系统对授权弹窗提醒得比较轻，有时候弹窗藏在通知栏里。所以遇到unauthorized，第一反应应该是拿起手机看一眼，而不是在电脑上折腾。

如果设备列出来了但状态一直offline，可以试着重启adb服务：

adb kill-server adb start-server adb devices

很多时候offline是因为adb server在电脑休眠、手机锁屏或者USB控制器切换之后，连接状态“假死”了。杀掉重启再重新枚举一次，大多能恢复。

2.2 USB、Wi-Fi还是模拟器，三种连接方式的取舍

USB连接是最常用的，稳定性也最好。但如果你要在手机上长时间跑自动化脚本，或者手机放在另一个房间，USB线拖着不方便，可以考虑Wi-Fi无线连接。需要注意的是，Android 11及以上版本原生支持无线调试，可以直接用手机上的“无线调试”功能配对，不需要root。Android 10及以下的老办法是先用USB连一次，执行一下命令把端口号设置好：

adb tcpip 5555 adb connect 192.168.1.100:5555

手机IP可以通过adb shell ip addr show wlan0查，也可以在手机“设置-关于手机-状态信息”里看。连接成功后拔掉USB线，后续命令一样能执行。要注意的是，无线连接的性能受Wi-Fi环境影响，如果网络不稳定，可能会频繁掉线，对稳定性要求高的操作还是建议USB。

模拟器是测试中另一大场景。Genymotion、Android Studio自带的模拟器、以及很多第三方安卓模拟器，都默认开了ADB调试端口。你不需要把模拟器“插”到电脑上，直接用adb connect 127.0.0.1:端口号就能连上。比较常见的端口有emulator-5554这种写法，本质上就是模拟器自报的设备名。第三方模拟器各家的端口不一样，有的在设置界面里写明了，有的需要自己查，使用前先确认端口别连错设备。

注意：如果你同时连着USB真机、Wi-Fi设备和多个模拟器，adb devices会列出一大串。这时候再执行adb install或adb shell，ADB会提示“more than one device/emulator”，要求你用-s指定设备。我在5.3小节会专门讲多设备管理。

2.3 设备信息查询：getprop体系的使用

设备连接正常后，很多人想要查看手机的型号、系统版本、屏幕分辨率等信息。这些信息不需要装任何App，ADB自带一条命令就能全部查出来：

adb shell getprop

这条命令会输出一大堆系统属性，英文缩写看着比较费劲。实际工作中常用的是过滤出特定字段。Windows下配合findstr使用：

adb shell getprop | findstr ro.product.model adb shell getprop | findstr ro.build.version.release adb shell getprop | findstr ro.product.manufacturer

执行完之后分别能看到设备型号、Android版本、厂商名称。如果一次想查多个字段，可以在一条命令里用findstr指定多个关键字，比如findstr "product model"。这个命令在写自动化脚本、判断设备类型时非常有用。

除了getprop，还有几个设备信息命令我用的也很频繁：

adb shell wm size # 查看屏幕分辨率，比如 1080x2400 adb shell wm density # 查看屏幕密度，比如 440dpi adb shell getprop ro.serialno # 查看设备序列号 adb shell uptime # 查看设备已开机时长

分辨率和密度这两个参数在做UI适配测试、设置模拟点击坐标时特别重要。同样一张截图，在不同分辨率的设备上，某个按钮的坐标可能完全不同。所以我在写自动化脚本之前，第一步永远是先查这两个值，再计算相对坐标。

3. 应用安装、卸载与数据管理：日常调试的“高频区”

3.1 adb install参数与Windows路径坑

应用安装是ADB使用频率最高的操作，没有之一。最简单的安装命令：

adb install D:\test\app-debug.apk

但实际开发中，APK文件通常在一堆子目录里，路径很长，Windows的路径长度限制偶尔会跳出来咬人。如果ADB报“系统找不到指定的文件”，先检查路径是不是写错了，再检查路径里有没有空格或者中文。我有一次把APK放在D:\我的项目\debug包\v1.0\app-release.apk这种目录下，cmd里怎么敲都报错，最后把APK复制到D:\根目录，一条命令就装上了。Windows对中文路径和特殊字符的支持在命令行环境下一直比较脆弱，建议调试时干脆用英文路径。

adb install常用参数如下：

我平时最常用的是-r -t组合：adb install -r -t app-debug.apk。这是因为Android Studio构建的debug包默认带testOnly标志，不加-t参数安装时直接报INSTALL_FAILED_TEST_ONLY: installPackageLI，非常坑。另外，如果遇到报错INSTALL_FAILED_VERSION_DOWNGRADE，就是设备上已经装了更高版本，需要加-d参数降级安装。

安装完成后，如果想确认应用确实装上了，可以用adb shell pm list packages | findstr 包名来查。包名和应用名称不是一回事，包名是唯一的，应用名称只是显示名称。比如微信的包名是com.tencent.mm，抖音是com.ss.android.ugc.aweme，这些记不住很正常，可以安装后用命令查。

3.2 包名定位：从应用商店到当前前台

有些时候，你需要知道某个已经安装的应用的包名是什么。最笨的办法是去应用商店页面看，这个有太多例外；比较靠谱的办法是用ADB命令直接查。

查看设备上所有已安装的应用：

adb shell pm list packages

输出会很长，一般配合过滤使用。比如你想确认微信是否已安装：

adb shell pm list packages | findstr tencent

如果你想查当前正在前台运行的是哪个应用，可以这样：

adb shell dumpsys window | findstr mCurrentFocus

输出类似mCurrentFocus=Window{... com.tencent.mm/.ui.LauncherUI}，包名和Activity名都清清楚楚。查当前前台应用这个操作，在测试深链跳转、Activity生命周期时特别有用，你可以点开某个应用后立刻执行这条命令，确认它到底跳到了哪个页面。

还有一种情况是你要打开某个应用的指定页面，但你知道包名不知道Activity名。可以用adb shell monkey -p 包名 -c android.intent.category.LAUNCHER 1启动应用，再看当前焦点拿到了Activity名，然后后续复用。

3.3 清除数据、备份与恢复的正确姿势

开发和测试过程中，经常会需要清掉应用的数据来还原状态，比如测试“首次启动引导页”、“登录态过期”等场景。这时候用pm clear：

adb shell pm clear com.tencent.mm

这条命令会把应用的所有数据清空，效果相当于在系统设置里点“清除数据”。操作之后应用会恢复到刚安装的状态。这里要特别提醒：pm clear会把应用沙盒内所有文件一起干掉，如果要保留某些配置文件，千万先备份。

备份单个应用的APK文件是另一个常用操作。我自己遇到过一个场景：手机上下了一款旧版应用，应用商店已经下架了新版，厂商官网也没有历史版本下载，最后是借助ADB从另外一台手机上把APK拉出来：

adb shell pm path com.example.app

这条命令会输出APK在设备上的实际路径，一般长这样package:/data/app/~~~xxxx/com.example.app-xxxxx/base.apk。拿到路径后，用adb pull把APK文件拉到电脑上：

adb pull /data/app/~~~xxxx/com.example.app-xxxxx/base.apk D:\backup\app.apk

需要注意，pm path输出的是package:开头的完整字符串，直接用时要先把package:前缀去掉再传给pull。如果设备没root，/data/app目录本身不可浏览，但ADB授权后，pm path和pull还是可以正常工作的，这也是备份APK比较方便的方式。

4. 文件传输与logcat日志抓取：排查问题的两个抓手

4.1 push/pull的路径写法和常见错误

ADB的文件传输功能，本质上就是两条命令：adb push（电脑推送到设备）和adb pull（设备拉取到电脑）。看命令定义很简单，但Windows下用起来也是有小九九的。

推送文件的命令格式：

adb push D:\test\test.txt /sdcard/Download/

拉取文件的命令格式：

adb pull /sdcard/Download/test.txt D:\test\

这里有几个容易踩的坑。第一，设备端路径建议统一用正斜杠/，比如/sdcard/Download/，不要写\sdcard\Download\。Windows下的ADB版本对反斜杠解析有可能出问题。第二，电脑端路径如果带空格，需要加引号：

adb push "D:\my data\test.txt" /sdcard/

第三，push到设备时，如果目标是一个不存在的目录，命令会失败。比如/sdcard/12345/这个目录根本不存在，直接push会报错。可以先执行adb shell mkdir -p /sdcard/12345创建目录再推送。这个坑在自动化脚本里最常见，因为脚本跑在全新设备上时，很多目录都没有，需要先建目录。

拉取文件的另一个常见问题是：adb pull拉取一个目录时，如果电脑端目标目录已经存在同名文件，ADB默认会覆盖还是报错？不同版本行为略有差异，为了稳妥，我一般先看一下设备端文件是否存在、大小是多少：

adb shell ls -l /sdcard/Download/test.txt

确认无误后再执行pull，避免拉了个空文件或者不完整文件。

4.2 logcat的过滤与输出，Windows下请用findstr

抓日志是ADB的另一大高频用途。adb logcat的输出量极大，满屏滚动根本看不完。实际工作中必须学会过滤。

最基础的一条，清空旧日志再复现问题：

adb logcat -c

-c是clear的意思，清空缓冲区之后，再让同事或测试人员去复现Bug，新的日志干净地输出，不会被历史日志淹没。

过滤关键字时，Linux/Mac下用grep，Windows下用findstr：

adb logcat | findstr "AndroidRuntime" adb logcat | findstr "FATAL EXCEPTION" adb logcat | findstr "你的应用包名"

如果你只看崩溃相关的日志，可以直接过滤AndroidRuntime，因为Java层crash都会打这个标签。还有一个很有用的参数是按优先级过滤，比如只显示Error级别及以上的日志：

adb logcat *:E

参数规则是标签:优先级，优先级从低到高分别是V、D、I、W、E、F、S。如果想要“只要某个标签的错误和警告”，写成TAG:W即可。在Windows的cmd下，通配符*在有些场景会被扩展，如果你敲adb logcat *:E没反应，可能是因为cmd把*处理掉了，建议用adb logcat "*:E"，加个引号规避。

抓崩溃日志时，很多人会直接adb logcat > crash.txt把输出重定向到文件。这个操作在Windows下正常，但要注意，cmd里重定向生成的文本默认是ANSI编码，Android日志又是UTF-8，用记事本打开可能乱码。我习惯用VS Code直接打开，或者先执行chcp 65001把cmd切到UTF-8编码，再重定向。

4.3 截图、录屏与Windows乱码问题的绕行方案

截图和录屏是Bug反馈时的黄金搭档。ADB原生支持这两项能力，不需要在手机上装任何App。

截图命令：

adb exec-out screencap -p > D:\screen.png

录屏命令：

adb exec-out screenrecord --time-limit 10 /sdcard/demo.mp4

录屏的本质是先在设备上生成MP4文件，再用pull拉到电脑。默认录制时长不超过180秒，超时需要加--time-limit参数。

这里有一个Windows专用的经典坑，就是我在标题里提到的adb: createfilew 'nul' failed: 系统找不到指定的文件。这个报错经常出现在cmd窗口下执行类似adb exec-out screencap -p > nul或把screencap输出重定向给其他程序时，旧版ADB在Windows下对nul设备文件的处理有兼容性问题。解决办法很简单：

1. 不要用nul作为重定向目标，改成一个普通临时文件；
2. 把输出重定向到D:\screen_temp.png，再用其他工具处理这个文件；
3. 或者避开cmd，在PowerShell里用$null处理空输出。

我自己的习惯是：截图命令里永远指明完整的目标文件路径，不偷懒写nul。这样既绕开了报错，也不会误删文件。

提示：在Windows的cmd中，nul是一个特殊设备名，类似于Linux的/dev/null，但在某些ADB操作中，ADB会把参数里的nul当作需要打开的文件路径，又和cmd的重定向逻辑混淆，就会报createfilew 'nul' failed。遇到这个报错不要慌，改掉重定向方式基本就能解决。

5. adb shell与自动化：把Windows变成你的遥控器

5.1 Shell基础命令与查看系统资源

adb shell等于把设备上的Linux shell搬到了你的Windows命令行里。进入shell交互模式：

adb shell

进去之后，你可以执行很多Linux命令，比如ls、cd、cat、ps、top、df。如果你不想进入交互模式，也可以直接在Windows命令行中加一条命令执行，比如：

adb shell ls /sdcard/ adb shell df -h adb shell cat /proc/meminfo adb shell top -n 1

top -n 1可以查看设备实时的CPU和内存占用，df -h可以查看内部存储空间使用情况。如果你在测试应用性能，这两条命令是最快的初步判断方式。注意Android设备的shell是精简版，很多桌面Linux命令不一定存在，比如没有vim、没有grep，但常用的文件操作和进程管理命令基本都在。

操作设备上的配置文件时，sed在部分Android系统上不可用，所以我一般先cat查看，再用echo > 文件的方式写入。批量修改系统设置更推荐用settings命令：

adb shell settings put global stay_on_while_plugged_in 3 adb shell settings get global stay_on_while_plugged_in

第一个命令让设备插着电源时不熄屏，对长时间跑测试非常友好；第二个命令查看当前值。这些命令写进脚本里，比手动在设置里点来点去高效得多。

5.2 input事件模拟：自动点按、滑动和输入

如果自动化测试框架还没接入，或者你只是想临时模拟一次操作，adb shell input命令是最快的方式。它支持模拟点击、滑动、按键、输入文字。

模拟点击：

adb shell input tap 500 1000

模拟滑动：

adb shell input swipe 500 1500 500 300 500

最后那个500是滑动耗时，单位毫秒。模拟返回键：

adb shell input keyevent 4

模拟Home键：

adb shell input keyevent 3

输入文字：

adb shell input text "hello"

这里有几个坑必须说明。第一，坐标是绝对坐标，不同分辨率屏幕的同一按钮位置不一样，所以要结合wm size查到的分辨率来计算。第二，input text无法输入中文，这是Android input命令本身的能力限制，遇到中文输入，要么用剪贴板方案，要么借助支持UTF-8的自动化框架。第三，input swipe的滑动起点和终点需要落在屏幕范围内，否则命令不报错但也没有效果，很迷惑。

我平时排查问题时最常用的组合是：截图确认当前页面 ->input tap点击目标按钮 -> 再截图确认跳转结果。这几条命令配合起来，可以非常快速地走通一个页面流程。

5.3 多设备管理：-s参数加脚本化

测试工程师的工位上经常摆着好几台手机，模拟器也可能同时开好几个。这时候直接执行adb install会报“more than one device/emulator”，需要给每一条命令加上-s参数指定设备：

adb -s R58M12345ABC install app-debug.apk adb -s emulator-5554 shell input tap 500 1000

设备序列号从哪里拿？adb devices输出的第一列就是。你可以把它们看成是每台设备的身份证号。在脚本里，我更推荐先定义好设备和别名，再循环处理：

@echo off set DEVICE1=R58M12345ABC set DEVICE2=emulator-5554 adb -s %DEVICE1% install app-debug.apk adb -s %DEVICE2% install app-debug.apk

如果你要同时向10台设备推送同一个APK，手动一条条执行太慢，可以写一个批量脚本循环读取设备列表，逐个安装。这个思路也适用于批量执行pm clear、批量截图、批量抓日志。多设备并行的核心就是：先adb devices确认所有设备状态正常，再写循环逐条操作，并在关键节点输出当前设备名，否则日志混在一起根本没法看。

6. 高频报错与实用技巧速查表

6.1 十个小问题的排查方法

Windows下用ADB这些年，我遇到过不少报错，有些是环境问题，有些是命令用错了，很大一部分是Windows平台的行为差异导致的。下面这个表格，是我根据实际项目经验整理的高频问题速查，基本覆盖了日常90%的报错场景。

这里补充一下adb server version doesn't match this client这个报错的细节。它出现得非常频繁，尤其是电脑上装了多个Android工具链的时候。Android Studio自带一份ADB，某些手机助手又捆绑一份ADB，命令行里打开的是另一个目录的ADB，三份版本各不一样，server起不来。解决办法是先杀掉所有adb进程，再统一用同一个目录下的ADB启动：

adb kill-server taskkill /f /im adb.exe adb start-server

如果确实需要在多个ADB版本之间切换，可以写一个环境变量切换脚本，但更推荐的做法是：固定使用官方platform-tools，其他工具如果依赖自带的ADB，也尽量把路径统一覆盖。

6.2 我一直在用的几个ADB小技巧

最后分享几个我每天都会用的ADB技巧，都是在Windows下实践出来的“私货”，文档里通常不会写这么细。

第一个是录制logcat到文件并自动带时间戳。直接在cmd里执行：

adb logcat -v time > D:\logcat_%date:~0,4%%date:~5,2%%date:~8,2%.txt

这样文件名会自动带上日期，比如logcat_20250115.txt。日积月累不会覆盖混乱。如果你要长期跟踪某个应用的日志，可以再加一层findstr过滤包名，只保留这个应用的消息。

第二个是快速截图并自动打开。一条命令搞定：

adb exec-out screencap -p > %USERPROFILE%\Desktop\screen.png && explorer %USERPROFILE%\Desktop\screen.png

执行完截完图，Windows会自动打开图片预览。这个操作比手机上截完图再传到电脑快得多，尤其在远程给同事演示问题的时候特别方便。

第三个是查看Android设备上最耗电的应用排行。虽然手机设置里也能看，但用命令行查看更深层的数据更直接：

adb shell dumpsys batterystats | findstr "Uid"

不过batterystats的数据量很大，建议先执行adb shell dumpsys batterystats --reset清空历史数据，再正常使用一会儿手机，最后重新抓取分析。

第四个，也是我个人最推荐的小习惯：把常用ADB命令封装成bat脚本。比如install.bat专门用来安装指定APK，logs.bat专门负责抓日志，pull_data.bat专门拉取指定目录文件。这样团队内新同学上手也快，不需要记一堆命令参数，双击就能跑。封装时记得在脚本开头加上cd /d %~dp0和adb devices，确保脚本在任何目录下执行都不会因为路径问题翻车。

我自己在实际操作中还有一个体会：ADB命令本身不复杂，真正决定效率的是你是否愿意把重复操作沉淀成脚本。每次手动输入一条命令只省了几秒钟，长期积累下来，差别非常大。希望这份Windows下的ADB命令梳理，能帮你少踩一些我当年踩过的坑，把更多精力放在业务本身。