鸿蒙 hdc 这东西说它是鸿蒙开发里的 adb 一点都不夸张但真上手会发现它并不是 adb 的简单换皮命令名换了、日志工具挪到了设备侧、端口转发还分了两个方向。我第一次在 OpenHarmony 开发板上折腾 hdc 的时候光是设备明明插着、list targets却是空的这一件事就耗掉大半个下午后面无线调试连上又断、server 版本不匹配、装了包跑不起来只能靠日志猜这些坑一个都没躲过去。这篇就把我这几年在鸿蒙应用开发和设备调试里攒下来的 hdc 使用经验整理一遍。不管你是刚装好 DevEco Studio 想跑第一个页面还是在做 Flutter、KMP、Tauri 这类跨平台框架的鸿蒙适配又或者需要在流水线上写脚本批量装包、批量抓日志命令行的 hdc 都绕不开。我会从它是谁、装在哪、怎么连、命令怎么用一路讲到报错怎么查尽量把每个参数背后的原因也讲清楚让你下次遇到问题不是靠猜。1. hdc 到底是什么先把三个进程和一条链路看明白很多人学 hdc 的方式是背命令用着用着就卡住因为不知道出错的是哪一环。命令只是表象真正决定你排错效率的是它背后的架构。这一章先把结构讲清楚后面所有的报错你都能自己对号入座。1.1 hdc 的三层进程模型client、server、设备侧守护进程hdc 全称 HarmonyOS Device Connector本质是一套主机与设备之间的通道工具。它由三个角色组成主机侧的hdc可执行文件每次执行时就是一个client进程负责解析你的命令主机上还常驻着一个server进程默认监听8710端口负责管理所有设备连接、维护端口转发表、收发数据设备侧则有一个守护进程早期叫hdcd负责真正执行 shell、读写文件、安装包。这个结构解释了几件日常怪事。第一为什么你敲完一条命令任务管理器里会短暂出现一个 hdc 进程又消失——那是 client 干活完退了server 还在。第二为什么两个终端同时操作同一台设备会互相干扰——它们共用同一个 server。第三为什么改了端口之后旧的连接全失效——server 换了个门client 还在敲老门。client 和 server 之间的通信走本地 TCP主机和设备之间走 USB 或者 TCP。USB 通道依赖系统驱动Windows 上这点尤其明显TCP 通道依赖网络可达性。记住这条分层list targets空的时候你就知道该先查哪一层。注意同一台机器上不要同时跑多个版本的 hdc。server 只有一个先启动的那个占住端口后面的 client 会去连它于是出现命令是新版的、行为是老版的这种最难查的诡异现象。1.2 和 adb 的对照表迁移成本其实很低如果你有 Android 调试经验下面这张表能让你十分钟上手。差异点集中在日志、安装包格式和端口转发方向这三块。功能hdc 命令adb 对应命令备注查看设备hdc list targetsadb deviceshdc 加-v看详情进设备 shellhdc shelladb shell都是受限 shell安装应用hdc install -r xxx.hapadb install -r xxx.apkhap 必须已签名卸载应用hdc uninstall 包名adb uninstall 包名参数是 bundleName推文件到设备hdc file send 本地 远端adb push默认只推荐写临时目录从设备取文件hdc file recv 远端 本地adb pull抓截图、抓日志常用看日志hdc shell hilogadb logcathilog 是设备侧工具端口转发hdc fport tcp:A tcp:Badb forward方向是主机到设备反向转发hdc rport tcp:A tcp:Badb reverse方向是设备到主机重启设备hdc target bootadb reboot慎用别把产线机刷了指定设备hdc -t 连接键 命令adb -s 序列号 命令多设备必备重启服务hdc kill -r/hdc start -radb kill-server排查第一步还有一个容易踩的点OpenHarmony 早期版本里这个可执行文件叫hdc_std后来才改名成hdc。网上大量老教程写的是hdc_std你在新 SDK 里照着敲会直接提示命令不存在。看到hdc_std就当hdc用参数基本一致。1.3 什么时候必须放下鼠标、打开终端DevEco Studio 已经能覆盖大部分日常操作但还是有几类场景只能靠命令行。一是自动化与流水线。构建完自动装包、自动拉起页面、自动抓一段日志、自动做一次回归验证这些在 CI 上只能写命令。二是没有 IDE 的环境比如一台只有命令行工具包的 Linux 构建机或者一台跑 OpenHarmony 的模组板你要做的就是连上去看param、拉文件、重启服务。三是交叉验证。IDE 报设备连接失败的时候先用hdc list targets敲一下就能立刻判断是 IDE 的问题还是设备/驱动的问题省掉大量无头绪的重启。四是跨平台框架适配期的排查。Flutter、KMP、Tauri 这类框架在鸿蒙上跑起来出问题时的第一现场往往是 hilog 里的一行崩溃栈IDE 的日志面板不一定能抓到全部。这时候hdc shell hilog加上过滤参数就是唯一抓手。2. 环境准备hdc 从哪来、怎么进 PATH、权限怎么给环境没配好后面每一条命令都会给你脸色看。这一章按找文件、进 PATH、给权限、做验证的顺序来照着走一遍基本能省掉后面 80% 的疑惑。2.1 三个平台上 hdc 的位置与获取方式最省事的来源是 DevEco Studio 安装包自带的 SDK但更干净的做法是用官方命令行工具包它体积小、路径短、不会被 IDE 升级牵动。平台常见位置说明WindowsDevEco Studio 安装目录下的sdk\...\toolchains\hdc.exe版本目录名随 SDK 变化建议直接搜索Windows命令行工具包解压目录sdk\default\openharmony\toolchains\hdc.exe推荐路径稳定macOS/Applications/DevEco-Studio.app/Contents/sdk/.../toolchains/hdc需要在终端里用绝对路径或加 PATHLinux命令行工具包sdk/default/openharmony/toolchains/hdc构建机上最常用源码编译编译产物中的 hdc 可执行文件版本可能与设备不匹配谨慎用在 Windows 上不要用文件管理器一层层点进去找直接在 DevEco Studio 安装目录搜索hdc.exe几秒钟的事。找到以后建议把整个toolchains目录记下来因为 hdc 运行时可能还需要同目录的其他库文件单独把 exe 拷出来放别处有概率起不来。版本这块有个经验hdc 的版本和设备的系统版本、SDK 版本最好大致对齐。版本差得太多典型症状是连上后马上掉、或者安装包时报一些看不懂的错误。用hdc -v看主机侧版本设备侧版本可以通过hdc shell param get const.ohos.apiversion之类的参数侧面确认不同版本参数名略有差异用param get试几个常见的即可。2.2 PATH 与环境变量为什么建议改掉默认端口Windows 上加 PATH 走系统属性里的环境变量面板把toolchains目录追加到用户的 Path 里重开终端生效。macOS 和 Linux 在~/.zshrc或~/.bashrc里加一行export PATH$PATH:/你的路径/toolchains然后source一下。真正值得说的是HDC_SERVER_PORT这个环境变量。它的作用是告诉 client 和 server 用哪个端口通信默认8710。为什么要改三种情况一是同机器上有多个用户或者多个工作区各跑各的 server 互不打扰二是8710被别的程序占了三是做多设备并行测试用不同端口起多个 server 实例。改端口有个铁律client 和 server 必须用同一个值。你只在一个终端里 export 了另一个终端没 export两个终端就会各自连到不同的 server表现出来就是一边能看到设备另一边看不到。另外改完端口记得hdc kill -r把旧 server 收掉否则新端口起不来。hdc 还会读取一些控制日志行为的环境变量具体名称和是否支持在不同版本之间有差异拿不准的时候直接hdc -h看当前版本的说明别照抄网上几年前的帖子。2.3 Linux 下的 USB 权限设备识别不到往往是这里Linux 上最常见的问题不是 hdc 装错了而是普通用户没权限访问 USB 设备。症状很典型lsusb能看到设备hdc list targets却一片空白用sudo跑一次就能看到——这就百分百是权限问题。处理方式是在/etc/udev/rules.d/下建一条规则把厂商 ID 对应的设备权限放开通常写成类似下面的形式# /etc/udev/rules.d/51-harmony.rules SUBSYSTEMusb, ATTR{idVendor}12d1, MODE0666写完要重载规则并触发一次然后重新插拔设备sudo udevadm control --reload-rules sudo udevadm trigger厂商 ID 可以从lsusb的输出里对照确认不同模组板的 ID 可能不一样。另一条路是把你自己的用户加进plugdev之类的设备组但组权限受发行版和桌面环境影响较大规则文件这条路更稳、更可控。注意MODE0666是让所有用户都能读写这个设备节点在个人开发机上够用如果是多人共用的构建机建议再配合用户组限制别图省事给整台机器留口子。2.4 五条命令验证环境是否正常配完之后别急着连设备先用下面这组命令给环境做个体检从内到外一层层确认。hdc -v # 看主机侧 hdc 版本确认命令能被找到 hdc -h # 看帮助确认子命令集是完整的 hdc checkserver # 确认 server 状态与端口 hdc list targets # 看设备列表此时可能为空 hdc kill -r # 重启 server清掉脏状态checkserver的输出能告诉你在哪个端口上通信这一步的输出要记住后面排查客户端连接问题时全靠它。list targets为空不代表环境有问题只代表没连设备但如果你确定设备插着、调试开关也开了那问题就落在 USB 驱动、权限或者授权弹窗上直接跳到第 3 章的分层排查表。3. 设备连接USB、无线、多设备指定这三件事连接是 hdc 使用中报错最集中的环节。把它拆成授权、通道、选择三段来看思路会清楚很多先让设备愿意让你连再让通道通最后在多设备里选对那一个。3.1 开发者模式与 USB 调试的正确打开顺序第一步是在设备上开启开发者模式进设置找到关于本机或关于手机连续点击版本号若干次系统会提示你已进入开发者模式部分机型需要输入锁屏密码确认。第二步回到设置里的系统和更新找到开发人员选项打开 USB 调试开关。顺序上有个细节值得注意先开调试开关再插线。反过来插上线再开开关有些设备不会重新走一遍枚举流程你会一直看不到设备直到拔插一次。第一次连接时设备会弹一个是否允许调试的对话框勾上始终允许再确认否则每次插线都要点一遍。如果hdc list targets显示设备的连接键但状态是Unauthorized就是授权对话框没点或者被点掉了。处理方式是拔掉数据线重插重新等待弹窗部分设备需要到开发人员选项里点一下撤销 USB 调试授权再重来。这个状态和完全看不到设备是两回事别混在一起查。3.2 无线调试tmode 与 tconn 两种玩法无线调试在需要频繁走动或者工位没法长期插线的场景里非常香但带宽和稳定性都不如 USB装几百兆的包或者刷大量日志时要有心理准备。玩法一是用 hdc 自己把设备切到 TCP 监听模式。先用 USB 连上执行hdc tmode port 8710 # 让设备在 8710 端口上监听 hdc shell ifconfig # 或者 ip addr看设备 IP hdc tconn 192.168.1.23:8710 # 主机主动连过去连上之后拔掉数据线hdc list targets里应该还能看到设备。要回到纯 USB 模式执行hdc tmode usb。不想保留这个网络连接就用hdc tconn 192.168.1.23:8710 -remove删掉。玩法二是走设备上开发者选项里的无线调试入口那里面会直接显示一对 IP 和端口用hdc tconn IP:端口连上去就行。这种方式的好处是端口由系统分配、不需要先插线缺点是每次开关无线调试端口都会变脚本里得动态解析别硬编码。两种玩法都要求主机和设备在同一个局域网里。公司网络如果做了客户端隔离两台设备互相 ping 不通无线调试就一定连不上这跟 hdc 本身没关系换热点最快。注意无线连接建立后hdc list targets里的连接键会变成 IP 加端口的形式。写脚本时用这个键配合-t指定设备不要在主机上同时保留 USB 和无线两条连接指向同一台设备否则同一个包你可能装两遍日志也会重复。3.3 多设备场景-t与list targets -v的正确读法同时连两三台设备做兼容性验证是很常见的。这时候所有命令都必须显式指定目标否则 hdc 会挑一台或者直接报错你以为是 A 机的结果其实操作在 B 机上这类事故在批量测试里出过不少。hdc list targets -v是必须会读的输出几个关键列连接键是设备的唯一标识USB 连接时通常是一串序列号网络连接时是 IP 加端口状态列告诉你设备当前是已连接、离线还是未授权后面的设备信息列会给出型号、系统版本等。看到Offline一般是通道断了但 server 里的记录还没清hdc kill -r之后重新插拔基本能解决。指定设备的标准写法是把-t放在紧挨着子命令的位置hdc -t 192.168.1.23:8710 shell param get const.product.model hdc -t ABC123456789 install -r ./entry-default-signed.hap在脚本里我习惯先做一次设备数校验比如把hdc list targets的输出行数取出来只有等于 1 才继续往下跑。这样能避免以为连着 A 机实际把包装到了 B 机这种低级但致命的错误。流水线里等设备就绪则用hdc wait比写一个死循环去轮询list targets干净得多。3.4 连不上设备的分层排查表把下面这张表存在手边连不上设备的时候从上往下走比乱试快得多。现象最可能的原因处理动作list targets完全为空线材只供电不传数据换一根确定支持数据传输的线完全为空lsusb能看到设备Linux 权限不足或 Windows 驱动异常配 udev 规则 / 装设备驱动完全为空设备也没弹窗USB 调试开关没开进开发人员选项确认开关状态状态显示Unauthorized授权弹窗没确认重插线勾始终允许再确认状态显示Offline通道断了server 记录残留hdc kill -r后重插设备无线连接报超时不在同一网段或有客户端隔离换到同一热点下重试无线连上又频繁掉线信号差或者省电策略杀进程改用 USB或让设备保持亮屏命令本身报连接 server 失败server 没起来或端口不一致用checkserver核对端口并重启4. 高频命令实战shell、文件、安装、日志连接通了以后日常真正用得多的就四类操作进设备看状态、传文件、装应用、抓日志。这一章按这四类拆开讲每条命令都说说它为什么这么写。4.1 shell 与设备内置工具集aa、bm、param、hidumper、uinputhdc shell可以直接进交互式命令行也可以一次性执行后者在脚本里更常用hdc shell # 进交互exit 退出 hdc shell ls -l /data/local/tmp # 一次性执行 hdc shell param get const.product.model # 查设备型号 hdc shell param get const.ohos.apiversion # 查 API 版本 hdc shell bm dump -a # 列出已安装应用 hdc shell aa start -a EntryAbility -b com.example.demo # 拉起指定页面 hdc shell hidumper -ls # 列出可用的系统信息通道 hdc shell snapshot_display -f /data/local/tmp/s.jpeg # 截屏这里要建立一个认知设备上的 shell 是精简过的systemctl、apt这类东西不存在能用的是ls、cat、ps、rm、mkdir这类基础命令。所以排查问题时别想着在设备上装工具思路应该是把需要的东西从主机传上去或者把要分析的文件拉下来在主机上分析。aa和bm是两个高频工具aa管 Ability 的启动和停止bm管包的信息查询和安装。hidumper则是拿系统侧信息的通用入口-ls先看看有哪些可查的通道再针对性地取。uinput用来模拟触摸和按键自动化点检时很好用hdc shell uinput -T -c 500 1000 # 在坐标 (500,1000) 点击 hdc shell uinput -T -d 500 1800 -u 500 600 # 从下往上滑具体参数随版本会有差异用之前先hdc shell uinput看一眼用法别照着老帖子的参数硬套。4.2 文件收发目录权限和路径写法是两个坑文件传输就两条命令但坑都在细节里。hdc file send ./test.hap /data/local/tmp/test.hap hdc file recv /data/local/tmp/s.jpeg ./s.jpeg hdc file recv /data/log/hilog ./device-log第一个坑是目标目录的写权限。设备上的 shell 用户能自由写的目录很少/data/local/tmp是最常用的落脚点。往/data/app、/system这类目录写会直接报权限错误这不是命令写错了是权限本来就不允许。想装应用到指定位置应该用install配合相应参数而不是手工往系统目录里塞文件。第二个坑是路径里的反斜杠和空格。Windows 下习惯写.\build\test.hap反斜杠在 shell 里可能被当转义符吃掉了。稳妥的写法是用正斜杠或者给路径加引号。路径里有中文或空格时引号是必须的否则命令会被拆成两段报出文件不存在这种让人一头雾水的错误。还有一点经验拉大量小文件的时候先想清楚是不是真的需要。设备上的日志目录动辄几万个文件直接整体recv又慢又容易中断先hdc shell里用tar打个包再拉效率差好几倍。4.3 应用安装与卸载签名匹配是第一优先级安装命令本身很简单hdc install -r ./entry-default-signed.hap hdc install -r ./build/outputs/ # 目录形式含多个 hap 时用 hdc uninstall com.example.demo hdc shell bm dump -a | grep com.example # 确认是否还在安装失败的原因排第一的永远是签名不匹配。设备上只接受用对应调试证书或发布证书签过的包随手拿一个没签名的 hap 去装一定失败。这类报错在命令行上通常只给一个错误码不告诉你是签名问题所以排查顺序应该是先确认这个包在 IDE 里能不能装、能装说明包没问题再确认命令行装的路径和 IDE 装的是同一个文件最后才去看错误码含义。排在第二位的是已存在同包名应用且版本关系不满足覆盖条件。-r表示覆盖安装但覆盖也有前提比如版本号不能低于已安装版本降级需要额外参数支持。遇到这类问题先把旧版本卸掉再装能最快定位。第三位是存储空间不足和安装到受限用户。多用户设备上装到了没有权限的用户空间表现也是失败。先hdc shell bm dump -a看清当前已装的包和版本再决定是卸载重装还是换用户。注意卸载会清掉应用数据。调试阶段无所谓但如果你正在复现一个跟本地数据有关的问题卸载等于把现场毁了。真要清数据优先用应用自己的清缓存入口实在不行再卸。4.4 hilog参数组合比背命令更重要设备侧的日志工具是 hilog不是 logcat。最朴素的用法是实时刷屏hdc shell hilog但全量日志基本没法看一秒钟能刷几百行。真正干活时的组合是这样hdc shell hilog -T MyAppTag # 按 tag 过滤 hdc shell hilog -L E # 只看 Error 及以上等级 hdc shell hilog -D 0x1234 # 按 domain 过滤 hdc shell hilog -r # 清空缓冲区从干净状态开始抓 hdc shell hilog -x # 结束流式输出几个必须知道的原理。第一日志等级是可调的调试期可以用hilog -b D把全局等级放宽到 Debug抓完记得恢复否则日志量会拖慢设备。第二release 包默认只输出 warn 以上等级你在调试包里能看到的大段 info 日志换成正式包就没了别拿正式包去查业务逻辑问题。第三hilog 本身也是设备侧的一个进程无线连接下大量日志会丢重要问题的日志一定用 USB 抓。需要长时间观察的场景可以把日志落到文件里而不是一路刷屏hdc shell hilog -w start -f /data/log/hilog/mylog -l 4M -n 10这样会按大小滚动保存若干份事后用hdc file recv把目录拉下来在主机上慢慢看。比起盯着屏幕刷这种方式更适合抓偶发崩溃——毕竟偶发的意思就是你盯着的时候它不出现。5. 端口转发fport 与 rport 的区别和实际用法端口转发是 hdc 里最容易被记混的一组命令但只要抓住谁监听、往哪转发两个方向一次就能记住不用再翻文档。5.1 fport 和 rport 到底差在哪用一句话概括fport是 forward主机当入口把主机端口上的流量送进设备rport是 reverse设备当入口把设备端口上的流量送回主机。两者都是建立一条 TCP 隧道方向正好相反。命令谁在监听数据流向典型用途hdc fport tcp:主机端口 tcp:设备端口主机主机到设备在主机上访问设备内的服务hdc rport tcp:设备端口 tcp:主机端口设备设备到主机让设备访问主机上的本地服务配套的管理命令也要记住hdc fport ls看当前所有映射hdc fport rm tcp:主机端口 tcp:设备端口删掉某一条。映射是挂在 server 上的hdc kill -r之后全部失效必须重新建立。写脚本的时候我会在建立映射之前先fport ls清一遍同名映射避免残留导致新映射建不起来。5.2 和调试链路的实际配合举三个我真实用过的场景。场景一是在主机浏览器里访问设备内的页面。设备上跑着一个只监听本机的服务用一条fport把它映射到主机的本地端口然后在主机浏览器里打开配合开发者工具就能像调普通网页一样调试。场景二是让设备访问主机上的测试服务。后端接口还没好需要在主机上起一个返回固定数据的服务设备上的应用通过rport暴露出去的地址访问它。这条链路在联调早期非常好用比等接口上线快得多。场景三是配合抓包工具分析请求。把主机上抓包工具监听的端口用rport映射给设备让设备产生的请求先经过主机的分析工具。注意这类操作要遵守所在组织对设备和数据的管理要求只在授权的测试设备和测试数据上做。另外一个容易忽略的点DevEco Studio 在调试应用时会自己建立一批端口映射如果你手工又建了一条占用同一个端口的映射会出现冲突表现是调试器连不上。遇到这种IDE 忽然调不动了先hdc fport ls看有没有自己加的多余条目删掉再重试。5.3 转发失效的四种原因转发失效的表现很统一映射看起来还在但访问不通。按下面顺序查。第一server 重启过。这是最常见的原因映射随 server 生命周期存在重启即失效。第二端口被占用。主机上还有别的程序包括另一个 hdc server占着同一个端口映射表面建立成功但流量走不到。第三设备端目标服务没起来或者换了端口。映射只是转发设备上没进程监听那个端口转发自然断。第四无线连接断开。无线模式下链路本身不稳转发会跟着断重新连上设备后需要重建映射。排查的顺手动作是先在设备上确认目标端口有进程在监听hdc shell里查一下端口占用再在主机上确认监听端口正常主机侧看端口占用最后才怀疑映射本身。6. 常见问题与排查技巧实录这一章是前面所有内容的落地。报错信息千变万化但归类之后其实就那么几族。下面这张表是我这几年最常见的一批配合后面两个小节的经验基本能覆盖日常 90% 的情况。6.1 报错速查表报错或现象归类处理思路找不到任何设备连接层按 3.4 的表逐层排查先线材后驱动再授权连接 server 失败服务层checkserver核对端口kill -r重启查端口占用提示主机与设备版本不匹配版本层换用与设备匹配的 hdc清掉旧 server 再试设备状态 Offline通道层重启 server 并重新插拔别原地反复敲命令提示未授权授权层重插线确认弹窗必要时撤销授权重来安装包失败且只给错误码签名或版本层先在 IDE 里验证包可装再查签名与版本关系写文件报权限不足权限层改写到临时目录别碰系统目录建立映射提示端口占用端口层先fport ls清残留再查主机端口占用命令执行提示需要更高权限权限层设备 shell 不是 root换用官方提供的接口无线连接超时网络层确认同网段、无客户端隔离优先换 USB日志抓不到应用的 info 级输出日志层换调试包或调高全局日志等级这张表里我最想强调两行安装包失败且只给错误码和日志抓不到 info。它们的共同点是命令行给的信息不足以定位问题必须回到 IDE 或者换方式验证。新手最容易在这里死磕错误码其实绕开一步更快。6.2 server 版本不匹配与进程残留清理版本不匹配是所有 hdc 问题里最有迷惑性的一个因为它有时候能连上、有时候连不上命令行为还前后不一致。根因基本都是一个机器上存在多个 hdc 可执行文件PATH 里指向的和实际起 server 的不是同一个。清理流程我固定这样做。先把所有客户端都关掉包括 IDE然后按平台杀掉残留进程# macOS / Linux ps -ef | grep hdc kill -9 进程号 # Windows tasklist | findstr hdc taskkill /f /im hdc.exe杀掉之后确认 PATH 里只有一份 hdcwhich hdc或where hdc如果输出多行说明有冲突再执行hdc kill -r重启 server最后hdc -v和checkserver一起确认版本和端口。注意DevEco Studio 启动时会自己拉起 hdc server。你手工换了 hdc 版本之后IDE 那边可能还在用旧的于是又变成两份。改完环境记得把 IDE 也完全退出重启一次。我自己的做法是保留一个干净的命令行工具包目录日常排查一律用绝对路径调用这个目录下的 hdc不给版本漂移留机会。这个习惯帮我省掉过很多明明改过了怎么还这样的时间。6.3 我踩过的坑和几条私房经验最后分享几条踩出来的经验都是文档里不太会写、但真能救命的东西。一是脚本里永远先校验设备数量。所有自动化脚本的第一行我都写成取hdc list targets并判断条数等于 1 才继续。多设备环境下这一行的价值相当于给整条流水线上了保险。二是 hilog 一定过一遍过滤器再进眼睛。我见过同事盯着全量日志找一个偶发问题一盯两小时眼睛花了也没找到。正确姿势是先按 tag 缩到应用自己的输出再按等级缩两分钟能定位。找不到 tag 就先抓一小段全量日志 grep 一下把 tag 名字问出来。三是别在设备上做删文件试试的操作。设备 shell 权限有限但/data下还是有不少可写位置随手删可能把某个服务的状态搞坏最后只能刷机。排查问题优先把现场拉回主机分析不动设备上的东西。四是无线调试适合看状态不适合搬数据。装包、拉日志这类大流量操作一律用 USB无线拿来快速看一下param、重启一下服务、点几个按钮就够了。混着用会让很多莫名其妙超时的问题消失。五是把常用命令做成 alias 或者小脚本。比如把抓日志、拉截图、装包三个动作各写成一个几行的 shell 脚本参数化包名和路径。命令行工具的熟练度不体现在你记得多少参数而体现在你把这些参数固化成了不用再想的东西。六是换线材比什么都快。新手遇到设备看不到一半概率是那根线只供电不传数据。桌上常备一根确认能传数据的线专门用来排除这一类问题比查半天驱动省事得多。这一路写下来hdc 本身并不复杂复杂的是它横跨主机、系统、设备三层任何一层出问题都表现为连不上或跑不起来。把三进程模型记住遇到问题先判断在哪一层再动手效率会完全不一样。