1. 车机无线调试到底解决了什么痛点
做车载测试这行的朋友都清楚，车机调试最烦人的一件事就是接线。早期做车机测试，基本上人手一根USB线，从工位拉到车机端口，线短了够不着，线长了绊脚，稍微碰一下接触不良就掉线。更别提整车环境下的测试，车机装在仪表台里面，你根本不可能趴到副驾脚垫上去插线。所以当adb无线调试这个能力在车机端逐步开放之后，整个测试效率的提升是肉眼可见的。
adb无线调试的核心原理其实不复杂。adb本身是Android Debug Bridge的缩写，是Android系统提供的一套调试桥接工具。它默认走USB通道，但同时也支持通过TCP/IP协议进行网络通信。只要车机和你的电脑处在同一个局域网内，就可以把adb的连接方式从USB切换到网络，从而实现无线调试。这个能力对车载测试来说意义很大，因为车机本质上就是一个定制化的Android设备，只要它能开放adb调试权限，你就能用同一套工具链去操作它。
但问题在于，车机不是手机。车机的系统定制程度远高于普通手机，不同车机厂商对adb的开放程度、网络配置方式、端口策略都不一样。有些车机默认关闭了adb网络调试功能，有些车机虽然能连上但过一会儿就断，还有些车机在无线调试模式下权限会被降级。这些坑我在实际项目中都踩过，所以这篇文章不只是告诉你几个命令怎么敲，更重要的是把每个命令背后的逻辑、适用场景、以及可能遇到的问题讲清楚。
这篇文章适合谁看？如果你是刚入行车载测试的新人，正在被各种线缆和连接问题折磨，那这5个命令能帮你快速建立无线调试的工作流。如果你是有一定经验的测试工程师，但一直用USB线做调试，想切换到无线方式提高效率，那文中的避坑指南能帮你少走弯路。如果你做的是车机自动化测试，需要批量管理多台车机设备，那无线调试更是绕不开的基础能力。
下面我会围绕5个核心adb命令展开，每个命令都会讲清楚它解决什么问题、怎么用、参数怎么配、以及我在实际使用中遇到的坑和应对方法。命令本身不难，难的是知道什么时候用哪个命令、参数怎么调、出了问题怎么排查。
2. 无线调试前的环境准备与连接建立
2.1 车机端和PC端的网络前提
在敲任何adb命令之前，你得先确保两件事：车机和电脑在同一个网络里，以及车机的adb调试权限已经打开。这两件事听起来简单，但实际操作中经常卡住。
先说网络。车机联网的方式通常有两种：一种是车机自带4G/5G模块，通过移动网络上网；另一种是通过WiFi连接局域网。做无线调试必须用第二种，因为adb的TCP连接需要车机和电脑在同一个局域网内，能互相ping通。车机用移动网络上网时，你的电脑是没法直接访问到它的。
具体操作上，你需要让车机连接到一个和电脑相同的WiFi热点。如果测试环境里没有现成的WiFi，可以用电脑开一个移动热点，让车机连上来。Windows系统在“设置 -> 网络和Internet -> 移动热点”里可以开启热点功能，把网络共享给车机。Mac系统在“系统偏好设置 -> 共享 -> 互联网共享”里也能做类似的事。这样车机和电脑就在同一个子网里了。
连上之后，你需要在车机上查到它的IP地址。不同车机的查看方式不一样，常见的有几种：在车机的“设置 -> 关于 -> 状态信息”里找IP地址；或者在车机的开发者选项里查看；如果车机支持终端应用，也可以直接在里面输入ifconfig或ip addr来查看。拿到IP地址后，先在电脑上ping一下，确认网络是通的。
注意：有些车机的WiFi模块在连接后会进入省电模式，导致网络不稳定。如果发现ping延迟很高或者丢包，可以在车机的开发者选项里关闭WiFi省电优化，或者让车机保持充电状态。
2.2 车机端adb调试开关的开启
车机的adb开关和手机不太一样。手机通常在“开发者选项”里有一个“USB调试”开关，打开就行。但车机的adb开关位置五花八门，有的在开发者选项里叫“ADB调试”，有的叫“网络调试”，还有的藏在工程模式里。
常见的开启方式有这么几种。第一种是在车机设置里连续点击“版本号”或“系统版本”7次，激活开发者选项，然后在开发者选项里找到adb相关开关。第二种是在车机的拨号界面输入特定的工程代码，进入工程模式后开启adb。第三种是通过车机上的特定应用（比如某些车机自带的“调试助手”）来开启。具体用哪种方式，取决于你的车机型号和系统版本。
这里有个经验：如果你拿到的车机是已经量产版本的，adb开关很可能被厂商锁定了。这种情况下，你需要联系车机的系统供应商或者通过特定的工程账号来解锁。有些车机在出厂时会把adb端口设成非标准端口，比如5555之外的端口号，这个也需要提前确认。
开启adb调试后，建议在车机的开发者选项里同时打开“保持唤醒状态”和“允许模拟位置”这两个选项。前者防止车机在调试过程中休眠断连，后者在某些需要模拟GPS信号的测试场景下会用到。
2.3 第一次连接：从USB到无线的切换
环境准备好之后，第一次连接建议还是先用USB线连一次。原因很简单：你需要通过USB连接来授权电脑的adb密钥，并且把车机的adb服务切换到TCP模式。
具体步骤是这样的。先用USB线把车机连到电脑上，在电脑终端里输入adb devices，确认设备列表里出现了车机设备。如果显示的是unauthorized，说明车机上还没有授权这台电脑，你需要在车机屏幕上点击“允许USB调试”的弹窗。如果车机上没有弹窗，可能是车机的adb授权界面被定制掉了，这种情况需要手动把电脑的adb公钥推送到车机的/data/misc/adb/adb_keys文件里。
授权成功后，输入adb tcpip 5555，这个命令的作用是把车机的adb服务从USB模式切换到TCP模式，监听5555端口。执行成功后，你就可以拔掉USB线了。然后在电脑上输入adb connect 车机IP:5555，如果一切正常，会显示connected to 车机IP:5555。再输入adb devices，应该能看到两个设备条目，一个是USB的，一个是网络连接的。
提示：
adb tcpip命令设置的端口号默认是5555，但有些车机可能占用了这个端口，或者厂商指定了其他端口。如果5555连不上，可以试试adb tcpip 5556或其他端口，然后adb connect时用对应的端口号。
这里有个容易忽略的细节：adb tcpip命令在车机重启后会失效，车机会恢复到USB模式。所以每次车机重启后，你都需要重新用USB线连一次，再执行adb tcpip 5555。如果车机支持在开发者选项里直接开启“网络adb调试”，那就可以跳过USB这一步，直接在车机上开启网络调试，然后电脑上adb connect就行。但很多车机没有这个选项，所以USB切换法还是最通用的方式。
3. 五个核心adb命令的实战用法
3.1 adb connect与adb devices：连接管理与设备识别
adb connect和adb devices是无线调试的入口命令，看起来简单，但实际使用中有不少细节。
adb connect的基本用法是adb connect <IP>:<端口>。连接成功后，adb会把设备信息保存在本地的设备列表里。但这里有个问题：adb的连接状态不是实时的。有时候车机已经断网了，但adb devices里还显示设备在线，这时候你执行任何adb命令都会卡住或者报错。所以我的习惯是，在执行关键操作前，先用adb devices -l看一下设备的详细状态，确认设备是真的在线。
adb devices的输出格式是这样的：
List of devices attached 192.168.1.100:5555 device如果显示的是offline，说明连接建立了但设备没有响应，通常是车机端的adb服务挂了，需要重启车机的adb服务或者重新连接。如果显示的是unauthorized，说明授权没通过，需要重新授权。
在实际项目中，我经常需要同时连接多台车机做对比测试。这时候adb devices会列出多个设备，你需要在每条adb命令后面加-s <设备序列号>来指定操作哪台设备。比如adb -s 192.168.1.100:5555 shell。设备序列号就是adb devices里显示的那一列。
还有一个实用技巧：如果你经常需要连接同一台车机，可以在电脑上写一个批处理脚本或者shell脚本，把adb connect和adb devices封装进去，一键完成连接和状态检查。这样每次调试前跑一下脚本就行，不用手动敲命令。
注意：adb的默认连接超时时间是5秒，如果车机响应慢，可能会连接超时。可以通过设置环境变量
ADB_CONNECT_TIMEOUT来延长超时时间，比如设为10000毫秒。
3.2 adb shell：车机内部操作的万能入口
adb shell是使用频率最高的命令，没有之一。它的作用是让你在电脑上直接执行车机内部的shell命令，相当于远程登录到车机的Linux终端。
基本用法是adb shell <命令>。比如adb shell ls /sdcard/可以查看车机内部存储的文件列表，adb shell pm list packages可以列出车机上安装的所有应用包名，adb shell dumpsys battery可以查看电池状态。这些命令在车载测试中非常常用。
但adb shell在车机上有几个特殊的坑。第一个坑是权限问题。车机的adb shell默认权限通常是shell用户，不是root。有些目录和文件是shell用户无权访问的，比如/data/data/下的应用私有数据。如果你需要访问这些数据，要么车机已经root了，要么你需要用run-as命令以应用的身份来访问。比如adb shell run-as com.example.app ls /data/data/com.example.app/。
第二个坑是命令兼容性。车机的Android版本和桌面Linux发行版不一样，很多常用的Linux命令在车机上可能不存在或者参数不同。比如grep命令在有些车机上不支持-P参数，find命令的用法也可能有差异。遇到这种情况，可以先adb shell进去，然后用which命令确认某个命令是否存在，再用<命令> --help查看支持的参数。
第三个坑是中文乱码。车机上的shell环境可能没有配置UTF-8编码，导致中文文件名或者中文输出显示为乱码。解决办法是在adb shell命令前加上LANG=en_US.UTF-8，或者直接在电脑端用adb exec-out代替adb shell来获取二进制输出。
在实际测试中，我经常用adb shell做这几件事：查看车机的系统属性（getprop）、检查网络状态（ifconfig或ip addr）、查看当前运行的进程（ps -A）、以及执行车机上的特定测试脚本。这些操作在USB模式下和无线模式下完全一样，但无线模式下你可以坐在工位上操作，不用趴在车里。
3.3 adb logcat：日志抓取与问题定位
adb logcat是车载测试中排查问题的核心工具。车机上的应用崩溃、系统异常、性能问题，基本上都要靠logcat来定位。
基本用法是adb logcat，它会实时输出车机的系统日志。但直接输出所有日志信息量太大，通常需要加过滤条件。常用的过滤方式有几种：按标签过滤（adb logcat -s TAG）、按优先级过滤（adb logcat *:E只显示Error及以上级别）、按进程ID过滤（adb logcat --pid=<PID>）。
在车载测试中，我常用的logcat命令组合是这样的：
adb logcat -v time -b main -b system -b crash > logcat_$(date +%Y%m%d_%H%M%S).txt这个命令的作用是把main、system、crash三个缓冲区的日志都抓下来，带上时间戳，保存到文件里。-v time表示日志格式包含时间信息，-b指定要抓取的缓冲区。车机上的日志缓冲区通常比手机多，除了标准的main、system、crash之外，还有radio、events等。具体有哪些缓冲区，可以用adb logcat -b all -v brief来查看。
抓取日志时有个很重要的技巧：先清空旧日志再抓。用adb logcat -c清空所有缓冲区，然后复现问题，再抓取日志。这样日志文件里只有问题复现过程中的记录，排查起来效率高很多。如果不先清空，日志文件里会混入大量无关的历史记录，找问题就像大海捞针。
还有一个坑是日志丢失。车机的日志缓冲区大小有限，如果日志产生速度太快，旧的日志会被覆盖。对于需要长时间抓取日志的场景，建议用adb logcat -r 1024 -n 10这样的参数，让logcat自动轮转日志文件，每个文件1024KB，最多保留10个。这样即使抓取时间很长，也不会因为缓冲区溢出而丢失关键日志。
提示：如果车机上的logcat命令被厂商定制过，参数可能不完全一样。可以先
adb shell logcat --help看一下支持哪些参数。另外，有些车机会把日志写到特定的文件里，比如/data/log/或/sdcard/logs/，这些文件也可以用adb pull拉取下来分析。
3.4 adb pull与adb push：文件传输的双向通道
adb pull和adb push是文件传输命令，在车载测试中用途很广。adb pull是把车机上的文件拉到电脑上，adb push是把电脑上的文件推到车机上。
基本用法是adb pull <车机路径> <电脑路径>和adb push <电脑路径> <车机路径>。比如adb pull /sdcard/logs/ ./logs/可以把车机上的日志目录拉到电脑当前目录下。
在车载测试中，这两个命令的典型使用场景包括：拉取车机上的日志文件、推送测试APK到车机安装、推送配置文件到车机、以及拉取车机上的截图和录屏文件。
这里有几个实操中总结出来的经验。第一，路径中的空格和特殊字符要处理好。车机上的文件路径可能包含中文或空格，这时候需要用引号把路径括起来，比如adb pull "/sdcard/我的文件/" ./。第二，大文件传输时建议加上-p参数显示进度，不然你不知道传输是卡住了还是在正常进行。第三，如果传输过程中断，可以重新执行命令，adb会覆盖已存在的文件，但不会断点续传。对于特别大的文件，建议先压缩再传输。
还有一个容易踩的坑：车机上有些目录是只读的，adb push会失败。比如/system/目录在非root状态下是不可写的。如果你需要往这些目录推送文件，要么车机已经root，要么用adb remount重新挂载分区为可写。但adb remount在车机上不一定可用，很多车机的系统分区是锁定的。
在实际项目中，我经常用adb pull来拉取车机的ANR日志和tombstone文件。这些文件通常在/data/anr/和/data/tombstones/目录下，是分析应用崩溃和系统异常的关键资料。但这两个目录通常需要root权限才能访问，如果车机没有root，可以通过adb bugreport命令来生成一个完整的系统报告，里面会包含这些信息。
3.5 adb install与adb uninstall：应用管理利器
adb install和adb uninstall是应用安装和卸载命令，在车载测试中用于部署测试版本和清理环境。
adb install的基本用法是adb install <APK路径>。常用的参数有：-r表示覆盖安装并保留数据，-d表示允许降级安装，-g表示授予所有运行时权限，-t表示允许安装测试包。在车载测试中，-r和-d用得最多，因为测试过程中经常需要反复安装不同版本的APK。
adb install -r -d -g ./test_app_v2.3.apk这个命令会覆盖安装test_app_v2.3.apk，允许版本降级，并自动授予所有运行时权限。对于车机上的系统应用，adb install可能会失败，因为系统应用的签名和普通应用不一样。这种情况下需要用adb push把APK推到/system/app/或/system/priv-app/目录下，然后重启车机。
adb uninstall的基本用法是adb uninstall <包名>。加-k参数可以保留应用数据和缓存。在测试中，有时候需要彻底清理应用环境，就用adb uninstall <包名>不加-k，这样应用和数据都会被删除。
这里有个坑：车机上有些预装应用是无法卸载的，adb uninstall会返回Failure。对于这些应用，可以尝试用adb shell pm disable-user <包名>来禁用它们，效果类似于卸载，但系统更新后可能会恢复。如果要彻底移除，需要root权限后删除对应的APK文件。
还有一个实用技巧：批量安装多个APK时，可以写一个循环脚本。比如：
for apk in ./apks/*.apk; do adb install -r -d -g "$apk" done这样可以一次性安装一个目录下的所有APK，省去手动一个个安装的麻烦。在搭建测试环境时特别有用。
4. 无线调试中那些让人抓狂的坑
4.1 连接不稳定与频繁掉线的排查思路
无线调试最大的问题就是连接不稳定。USB线虽然麻烦，但至少连接是可靠的。无线连接受网络环境影响很大，车机WiFi模块的性能、路由器的负载、甚至周围的其他无线设备都可能影响连接质量。
我遇到过的掉线情况大概有这么几种。第一种是车机WiFi休眠导致的掉线。车机为了省电，在屏幕关闭后可能会让WiFi模块进入低功耗模式，导致adb连接断开。解决办法是在车机的开发者选项里关闭WiFi省电优化，或者用adb shell svc wifi disable和adb shell svc wifi enable来重启WiFi。但更根本的办法是让车机保持充电状态，因为很多车机只有在充电时才会禁用WiFi省电策略。
第二种是IP地址变化导致的掉线。如果车机是通过DHCP获取IP的，网络重启后IP可能会变，原来的adb连接就失效了。解决办法是在路由器上给车机设置静态IP绑定，或者在车机上手动配置静态IP。如果车机不支持静态IP，那就每次连接前先确认车机的当前IP。
第三种是adb服务端的问题。电脑上的adb服务端有时候会卡死，导致所有adb命令无响应。这时候需要重启adb服务：adb kill-server然后adb start-server。重启后再重新adb connect。这个操作我基本上每天都要做好几次，已经成了肌肉记忆。
排查连接问题的基本流程是这样的：先ping车机IP确认网络通不通，然后adb devices看设备状态，如果设备不在列表里就重新adb connect，如果设备显示offline就adb kill-server后重连，如果还是不行就检查车机的adb开关是否还开着。这个流程能解决90%以上的连接问题。
4.2 adb unauthorized的根因与修复
adb unauthorized是无线调试中最常见也最让人头疼的问题之一。它的意思是车机没有授权这台电脑的adb连接。
根本原因在于adb的授权机制。每台电脑第一次连接车机时，车机会弹出一个授权对话框，询问是否允许这台电脑进行调试。如果你点了“允许”，电脑的公钥就会被保存到车机的/data/misc/adb/adb_keys文件里，以后连接就不需要再授权了。但如果这个对话框没有弹出来，或者你点了“拒绝”，就会显示unauthorized。
在车机上，这个授权对话框经常不弹。原因可能是车机的系统UI被定制过，去掉了这个弹窗；也可能是车机的adb授权界面被隐藏了。遇到这种情况，有几种解决办法。
第一种办法是手动把电脑的公钥推送到车机。电脑的adb公钥通常在~/.android/adbkey.pub（Linux/Mac）或%USERPROFILE%\.android\adbkey.pub（Windows）。你可以把这个文件的内容追加到车机的/data/misc/adb/adb_keys文件里。但问题是，/data/misc/adb/目录通常需要root权限才能写入。如果车机没有root，这个办法就行不通。
第二种办法是在车机上找到授权设置。有些车机在开发者选项里有一个“撤销USB调试授权”的选项，点击后会清除所有已授权的电脑，然后重新连接时会弹出授权对话框。如果车机上有这个选项，可以试试。
第三种办法是重启车机的adbd服务。用adb shell stop adbd和adb shell start adbd来重启adb守护进程，有时候能触发授权对话框重新弹出。但这个命令需要车机已经授权才能执行，所以只适用于之前授权过但后来失效的情况。
第四种办法是检查车机的时间。adb授权机制依赖时间戳，如果车机的时间和电脑的时间相差太大，授权可能会失败。确保车机和电脑的时间同步，可以避免这个问题。
注意：如果车机是工程样机或者开发板，通常不会有授权限制。但如果是量产车机，厂商可能会锁定adb授权，这种情况下需要联系车机供应商获取解锁方式。
4.3 车机重启后无线调试失效的应对
车机重启后无线调试失效，这是adb无线调试的机制决定的，不是bug。前面说过，adb tcpip 5555命令设置的是临时的TCP模式，车机重启后会恢复到默认的USB模式。所以每次车机重启后，你都需要重新用USB线连一次，再执行adb tcpip 5555。
这个限制在测试中很麻烦，尤其是做自动化测试的时候，车机重启是常见操作，每次重启都要插线太影响效率了。有没有办法让车机重启后自动进入TCP模式呢？
有几种思路。第一种是在车机的启动脚本里加入setprop service.adb.tcp.port 5555和stop adbd; start adbd。这样车机每次启动时都会自动把adb切换到TCP模式。但这个操作需要修改车机的系统文件，需要root权限，而且不同车机的启动脚本位置不一样，通用性不强。
第二种思路是用车机上的自动化工具（比如Tasker或车机自带的自动化应用）来监听启动事件，然后执行切换命令。但这个方案依赖车机上有相应的自动化工具，而且执行adb命令本身也需要权限。
第三种思路是在电脑端做文章。写一个脚本，检测到车机USB连接后自动执行adb tcpip 5555和adb connect。这样虽然还是需要插USB线，但至少不用手动敲命令了。对于固定工位的测试环境，可以一直插着USB线，脚本定时检查并维持TCP连接。
在实际项目中，我通常采用第三种方案。在测试工位上固定一根USB线连着车机，电脑上跑一个后台脚本，每隔30秒检查一次adb连接状态，如果发现TCP连接断了就自动重连。这样即使车机重启，最多30秒后无线调试就自动恢复了。
4.4 多设备同时调试时的设备指定问题
当同时连接多台车机时，adb命令必须指定目标设备，否则会报错more than one device/emulator。指定设备的方式是adb -s <序列号> <命令>。
设备序列号在adb devices的输出里可以看到。对于无线连接的设备，序列号通常是IP:端口的格式，比如192.168.1.100:5555。对于USB连接的设备，序列号是一串字母数字组合。
在多设备环境下，有几个实用技巧。第一，用环境变量ANDROID_SERIAL来指定默认设备。设置export ANDROID_SERIAL=192.168.1.100:5555后，后续的adb命令如果不加-s参数，就会默认操作这台设备。这个技巧在脚本里特别有用。
第二，用adb -s <序列号> <命令>时，序列号可以用Tab键自动补全。在bash或zsh里，输入adb -s然后按Tab，会自动列出当前连接的所有设备序列号。
第三，批量操作多台设备时，可以用循环：
for device in $(adb devices | grep -v "List" | awk '{print $1}'); do echo "Processing $device" adb -s $device shell getprop ro.build.version.release done这个脚本会遍历所有已连接设备，分别执行命令。在做多车机对比测试时非常实用。
提示：如果设备列表里出现了你不认识的设备，可能是之前连接过的设备残留。用
adb disconnect <IP>:<端口>可以断开指定设备，用adb disconnect可以断开所有无线设备。
5. 把无线调试嵌入日常测试工作流
5.1 常用命令的脚本化封装
前面讲的5个命令，如果每次都手动敲，效率还是不够高。我的做法是把常用的操作封装成脚本，放在电脑的PATH路径下，随时调用。
比如我写了一个caradb脚本，封装了连接、断开、状态检查这几个操作：
#!/bin/bash # caradb - 车机无线调试助手 CAR_IP="192.168.1.100" CAR_PORT="5555" case "$1" in connect) adb connect $CAR_IP:$CAR_PORT adb devices ;; disconnect) adb disconnect $CAR_IP:$CAR_PORT ;; status) adb devices -l | grep $CAR_IP ;; shell) shift adb -s $CAR_IP:$CAR_PORT shell "$@" ;; logcat) shift adb -s $CAR_IP:$CAR_PORT logcat "$@" ;; *) echo "Usage: caradb {connect|disconnect|status|shell|logcat}" ;; esac这样我只需要输入caradb connect就能连接车机，输入caradb shell ls /sdcard/就能在车机上执行命令，不用每次都敲完整的adb命令和IP地址。
对于日志抓取，我也写了一个脚本，自动清空日志、抓取指定时长、然后保存到带时间戳的文件里：
#!/bin/bash # carlog - 车机日志抓取 DURATION=${1:-60} CAR_IP="192.168.1.100" CAR_PORT="5555" TIMESTAMP=$(date +%Y%m%d_%H%M%S) OUTPUT="logcat_${TIMESTAMP}.txt" adb -s $CAR_IP:$CAR_PORT logcat -c echo "Cleared logcat buffer, capturing for ${DURATION}s..." timeout $DURATION adb -s $CAR_IP:$CAR_PORT logcat -v time > $OUTPUT echo "Log saved to $OUTPUT"这个脚本接受一个参数指定抓取时长，默认60秒。执行后会自动清空日志缓冲区，抓取指定时长的日志，保存到文件里。在做问题复现时特别方便。
5.2 无线调试在自动化测试中的角色
无线调试在自动化测试中的价值比手动测试更大。因为自动化测试通常需要长时间运行，USB线连接在长时间测试中容易因为接触不良或线缆松动导致中断，而无线连接没有这个问题。
在自动化测试框架中，adb无线调试通常用于这几个环节：测试前的环境准备（安装APK、推送配置文件、设置系统属性）、测试中的状态监控（抓取日志、截图、检查应用状态）、测试后的环境清理（卸载APK、拉取测试报告、恢复系统设置）。
以Appium为例，Appium连接车机的方式就是通过adb。在Appium的配置里，deviceName填车机的IP和端口，udid也填同样的值，Appium就会通过adb无线连接到车机。这样测试脚本运行时，车机可以放在任何有网络的地方，不受线缆长度限制。
在做车机的UI自动化测试时，我经常用adb shell uiautomator dump来获取当前界面的UI层级信息。这个命令会把当前界面的控件树导出到/sdcard/window_dump.xml，然后用adb pull拉取下来分析。在无线调试模式下，这个操作可以远程完成，不需要人工干预。
还有一个自动化场景是性能测试。用adb shell dumpsys系列命令可以获取车机的CPU、内存、电量等信息。比如adb shell dumpsys meminfo <包名>可以查看指定应用的内存占用，adb shell dumpsys cpuinfo可以查看CPU使用率。这些数据可以定时采集，形成性能趋势图。
5.3 从无线调试延伸到车载以太网测试
无线调试解决的是adb层面的连接问题，但在车载测试中，还有另一个重要的网络层面：车载以太网。现在越来越多的车机支持车载以太网，测试时需要验证车机的以太网通信功能。
adb无线调试和车载以太网测试有什么关系？关系在于，很多车机的adb网络调试就是走以太网通道的。当你用adb connect连接车机时，如果车机是通过以太网连接到测试网络，那adb的TCP流量就是走以太网传输的。所以无线调试的稳定性，在一定程度上也反映了车机以太网通道的稳定性。
在做车载以太网测试时，我通常会用adb来辅助验证。比如用adb shell ifconfig查看车机的网络接口状态，用adb shell netstat查看网络连接，用adb shell ping测试网络连通性。这些命令可以帮助快速定位是以太网物理层的问题还是上层协议的问题。
如果车机支持VLAN或者特定的以太网协议，还可以通过adb shell来配置和验证。比如用adb shell ip link查看网络接口，用adb shell vconfig配置VLAN。这些操作在无线调试模式下都可以远程完成，不需要直接接触车机硬件。
5.4 无线调试的安全边界与注意事项
最后说一下无线调试的安全问题。adb无线调试本质上是在网络上开放了一个调试通道，如果网络环境不安全，可能会被未授权的设备连接。
在测试环境中，建议把车机和测试电脑放在一个独立的VLAN或者独立的WiFi网络里，不要和办公网络混在一起。如果测试环境里有其他人在同一个网络里，他们的adb也可能连接到你的车机，导致设备列表混乱。
另外，测试完成后记得关闭车机的adb调试开关。虽然车机重启后adb会恢复到USB模式，但在不重启的情况下，adb端口一直是开放的。如果车机要移交给其他人或者进入下一道工序，关闭adb调试是一个好习惯。
还有一点：adb无线调试的通信是没有加密的。虽然adb协议本身有一些基本的认证机制，但网络上的其他设备仍然可以嗅探到adb的通信内容。所以不要在无线调试模式下传输敏感数据，比如账号密码或者个人隐私信息。
在实际项目中，我遇到过因为adb端口开放导致的安全扫描告警。安全团队扫描到测试网络里有设备开放了5555端口，以为是安全漏洞。后来解释清楚是测试用的adb调试端口，才解除了告警。所以如果你的测试环境有安全监控，最好提前报备一下adb端口的使用。
我个人在实际操作中的体会是，无线调试虽然方便，但不能完全替代USB调试。在车机系统崩溃、adb服务无法启动、或者需要进入fastboot/recovery模式时，USB连接仍然是唯一的选择。所以我的工位上永远备着一根USB线，无线调试是日常，USB调试是保底。两者配合使用，才能覆盖车载测试中的各种场景。
