【鸿蒙心迹】DevEco Studio 调试三件套实战：Log 定位、hdc 排障与 Profiler 看性能

前言

系列前几篇把环境搭建、踩坑复盘、状态管理这些"开发主路"上的事讲完了。真实项目里还有另一半时间花在排查问题上：列表不刷新是逻辑错了还是状态没通知？滑动掉帧是布局太深还是主线程被占？这篇把工具链补齐——DevEco Studio 的调试三件套：Log 窗口、hdc 命令行、Profiler。三件套各管一段：Log 回答"刚才发生了什么"，hdc 回答"设备现在什么状态"，Profiler 回答"时间花在了哪里"。

一、Log 窗口：让系统替你说话

HarmonyOS 的日志体系叫 HiLog，系统级、分域、分级别。应用里打日志用 hilog 模块：

import { hilog } from '@kit.PerformanceAnalysisKit';

hilog.info(0x0000, 'todo', '加载列表: number=%d', this.todos.length);
hilog.error(0x0000, 'todo', '保存失败: %{public}s', (e as BusinessError).message);

三个细节值得记住：

• domain 和 tag 要自己规划。domain 用一个固定的十六进制数，tag 按模块命名，Log 窗口里按 tag 过滤才有的放矢。全项目都打默认值，等于没打。
• 格式串是 printf 风格，不是模板字符串。%d %s 占位，参数跟在后面；隐私字符串要用 %{public}s 显式声明，否则默认按隐私打码，输出一堆 <private>——这是新人最常见的"日志怎么全是 private"的原因。
• 别依赖 console.log。它走 JS 通道，能用，但级别和 tag 都不可控，真机上混在系统日志里很难过滤，正式代码统一用 hilog。

DevEco 的 Log 窗口支持按设备、进程、级别、文本四层过滤。排查页面不刷新这类问题时，我的习惯是先把级别收到 Error 只看异常，再放宽到 Info 加上自己的 tag 复核调用路径，两层夹出问题区间。

二、hdc：绕开界面的直达通道

hdc（OpenHarmony Device Connector）类比 Android 的 adb，装了 DevEco 就有，很多事它比图形界面快：

hdc list targets                          # 列出已连接设备（真机+模拟器）
hdc shell aa start -b com.example.todo -a EntryAbility   # 冷启动到指定 Ability
hdc shell hilog | grep todo               # 命令行直接跟日志
hdc file recv /data/log/... ./fault.log   # 把设备上的文件拉到本地
hdc install ./entry-default-signed.hap    # 命令行装机
hdc shell param get const.product.model   # 查设备参数

实测里最常用的三个场景：

1. 应用崩了拉故障日志。问题复现后先 hdc shell 进去翻 /data/log/faultlog/，CPP 崩溃、JS 异常的调用栈都在里面，hdc file recv 拉出来慢慢看，比在 Log 窗口里抢滚动快得多。
2. 多设备并存。模拟器和真机同时连着时，操作前先 hdc list targets 看序列号，命令加 -t 序列号 指定目标，避免装错设备。
3. hdc 自身抽风。端口被占、server 版本混乱时，hdc kill 然后 hdc start -r 重启 server，九成问题到此为止。

三、Profiler：性能账要拿数据说话

前两件套管"对不对"，Profiler 管"快不快"。DevEco 的 Profiler 提供时间线模板，常用的三条轨道：

• Frame：帧率轨道，每一帧的耗时和是否超时一目了然。滑动卡顿先看这里，超时帧出现的位置就是要抓的点。
• CPU：按线程展开的调用栈采样，能定位超时帧期间主线程在执行哪个函数。
• Memory：内存快照，反复进出页面后抓两次快照做对比，持续上涨的对象就是泄漏嫌疑。

实操一条真实的路径：长列表滑动掉帧。Frame 轨道确认每滑一屏出现两三个超时帧 → CPU 采样看到超时帧期间主线程在 build() 里做排序 → 把排序挪到数据变更时一次算完（配合上一篇状态管理里 @Computed 的思路，派生数据别在 UI 里现算）→ 复测超时帧消失。全程十分钟，没有 Profiler 的话这就是一天的"我感觉是这里"。

两个前提别忽略：性能数据必须连真机采，模拟器的渲染路径和真机差异太大；调试包开着运行时检查，数据天然偏悲观，结论看趋势，绝对值别当真。

四、三件套怎么配合

单件好用，组合才是完整排查路径。我的固定套路：

1. Log 先扫一遍：Error 级别过滤，确认没有异常在刷屏。有异常，先修异常。
2. hdc 拉现场：崩溃找 faultlog，行为诡异先 param get 核对设备环境，把"设备差异"这个变量排除掉。
3. Profiler 定位：性能问题走 Frame → CPU → 代码，内存问题走快照对比。
4. 修完复测：同一条路径再采一遍，用数据确认修好了，而不是"感觉顺了"。

小结

调试三件套补上之后，鸿蒙开发的工具链就齐了：hilog 让系统替你说话，hdc 让你绕开界面直达设备，Profiler 让性能从玄学变成数据。下一篇写 Ability 生命周期与页面跳转——把"应用是怎么活着的"这件事讲清楚。

*本文环境：DevEco Studio 5.x / HarmonyOS NEXT（API 14+）。hdc 与 hilog 的参数细节以官方《调试指南》为准。系列上一篇：《【鸿蒙心迹】从 00306003 到模拟器启动：码上清单的构建与验收记录》。*