2、性能分析工具链：HiTrace、HiProfiler、SmartPerf的使用方法、性能数据采集与分析

性能调优这件事，说白了就是「先找到问题，再解决问题」。但问题在哪？光靠猜可不行。鸿蒙系统给我们准备了三把利器——HiTrace、HiProfiler、SmartPerf。我这些年调优的经验告诉我，这三样东西用好了，性能问题基本无处遁形。

今天我就带大家把这套工具链捋一遍。嗯，咱们从最基础的开始。

2.1 HiTrace：轻量级追踪，定位代码级问题

HiTrace 是什么？你可以把它理解成「代码里的摄像头」。它能记录函数调用、任务切换、消息传递这些细粒度的事件。我习惯在开发阶段就埋好 HiTrace 点，这样线上出问题时，直接看日志就能定位。

核心能力： 轻量、低开销、支持分布式追踪。

2.1.1 基本用法

在代码里埋点，其实就三步：

  1. 包含头文件 #include "hitrace/trace.h"
  2. 开始追踪：HiTraceStartTrace(HITRACE_TAG_APP, "myTask");
  3. 结束追踪：HiTraceFinishTrace(HITRACE_TAG_APP);

举个例子，你想看看某个网络请求花了多久：

#include "hitrace/trace.h"

void fetchData() {
    HiTraceStartTrace(HITRACE_TAG_APP, "fetchData");
    // 你的网络请求代码
    doHttpRequest();
    HiTraceFinishTrace(HITRACE_TAG_APP);
}

跑完之后，用 hitrace 命令就能看到耗时数据。我个人习惯在关键路径上都埋上，比如页面加载、列表渲染、数据库读写。

小技巧： 埋点名称最好用「模块_功能」的格式，比如 "HomePage_LoadData"，这样日志一搜就能定位。

2.1.2 数据采集与分析

采集命令很简单：

hitrace --trace_begin app
# 执行你的操作
hitrace --trace_dump > trace.log
hitrace --trace_finish

拿到 trace.log 后，我一般用 grep 过滤关键标签。比如：

grep "fetchData" trace.log

你会看到类似这样的输出：

B|1234|fetchData|1234567890
E|1234|fetchData|1234567990

B 是开始，E 是结束，中间的数字是时间戳。算一下差值，就是耗时。我曾经用这个办法抓到一个第三方 SDK 的卡顿问题——它一个初始化函数跑了 800 毫秒，直接拖慢了应用启动。

2.2 HiProfiler：全场景性能剖析，抓大放小

HiTrace 适合看细节，但如果你想看全局——CPU 占用、内存分配、线程调度——那就得上 HiProfiler 了。这玩意儿是鸿蒙的性能分析大杀器。

2.2.1 使用流程

我一般这么用：

  1. 打开 DevEco Studio，连接设备
  2. 点击「Profiler」标签页
  3. 选择要监控的进程
  4. 点击「开始录制」
  5. 操作你的应用
  6. 点击「停止录制」

录制完成后，你会看到一张时间轴图。上面有 CPU 使用率、内存占用、线程状态、网络请求等。说白了，就是一张「性能心电图」。

2.2.2 关键指标解读

指标 含义 正常范围 异常信号
CPU 使用率 进程占用的 CPU 百分比 < 30% 持续 > 60% 可能有死循环
内存占用 PSS（实际物理内存） < 200MB 持续增长可能有内存泄漏
线程数 活跃线程数量 < 50 过多线程导致上下文切换频繁
GC 次数 垃圾回收频率 < 5次/分钟 频繁 GC 说明内存分配不合理

我记得有一次，一个同事说他的应用滑动卡顿。我打开 HiProfiler 一看，好家伙，CPU 使用率直接飙到 85%，而且有个线程一直在做字符串拼接。优化成 StringBuilder 后，CPU 降到了 15%。

注意： HiProfiler 本身有一定开销，录制时设备可能会发热。建议每次录制不超过 30 秒，抓关键场景就行。

2.3 SmartPerf：自动化性能测试，持续监控

HiTrace 和 HiProfiler 都是「手动挡」，适合开发阶段。但到了测试和线上阶段，你需要的是「自动挡」——SmartPerf 就是干这个的。

2.3.1 核心功能

  • 场景录制： 定义测试步骤，比如「打开应用→点击按钮→滑动列表」
  • 自动采集： 按预设规则采集 FPS、CPU、内存、温度等
  • 报告生成： 自动输出性能报告，标注异常点

2.3.2 实战操作

用 SmartPerf 做一次性能测试，大概是这样：

# 启动 SmartPerf
smartperf start

# 运行你的测试场景
# 比如用 adb 模拟点击
adb shell input tap 500 1000

# 停止并生成报告
smartperf stop --output report.html

生成的报告里，会有一张 FPS 曲线图。如果曲线掉到 30 以下，说明有卡顿。我一般会设置一个阈值：FPS 低于 45 就告警。

我的习惯： 把 SmartPerf 集成到 CI/CD 流水线里。每次提交代码后自动跑一轮性能测试，有问题直接拦截，不让它流到线上。

2.4 三把利器的配合使用

你可能会问：这三个工具到底怎么选？我个人的经验是：

  • 开发阶段： 用 HiTrace 埋点，定位具体函数的耗时
  • 调优阶段： 用 HiProfiler 看全局，找到瓶颈模块
  • 测试/线上： 用 SmartPerf 做自动化监控，防止性能回退

举个例子。有一次应用启动慢，我先用 SmartPerf 跑了一轮，发现启动阶段 CPU 占用很低——说明不是计算密集，而是在等什么。然后用 HiProfiler 看线程状态，发现主线程在等一个锁。最后用 HiTrace 定位到是某个初始化函数里做了同步 I/O。改成异步后，启动时间从 3 秒降到了 0.8 秒。

你看，三个工具各司其职，配合起来才能把问题挖干净。

2.5 避坑指南

最后分享几个我踩过的坑：

  • 埋点太多： 我曾经在一个页面里埋了 50 多个 HiTrace 点，结果追踪日志比业务日志还大。建议只埋关键路径，10 个以内就够了。
  • 忽略 HiProfiler 开销： 录制时设备温度会升高，CPU 频率可能被限制。我一般会先空跑一次「预热」，再正式录制。
  • SmartPerf 阈值设得太松： 默认阈值可能不适合你的场景。比如游戏应用 FPS 要求 60，但工具默认告警是 30。记得根据业务调整。

嗯，工具链就讲到这里。下一章咱们聊聊具体怎么分析这些数据，以及怎么制定优化策略。记住一句话：工具是死的，思路是活的。用好这三把利器，性能问题基本都能搞定。

← 上一章 📖 返回目录 下一章 →