系列文章《鸿蒙开发从入门到专家》第 31 篇 · 中级
性能问题常常是用户先发现，老板先知道，开发最后才知道。
打开应用滑动列表，发现某一帧停顿了半秒。如果是 Android，多半能靠 “开发者选项里的 GPU 渲染模式” 或 “systrace” 排查；HarmonyOS 也有自己的工具链——DevEco Profiler。它把帧、CPU、内存、能耗、能耗都聚到一个窗口里，关键是很多人没把它和"代码里到底卡在哪里"对上号。
这篇文章按"看到症状 → 用工具下钻 → 在代码里解决"的顺序写，把鸿蒙性能剖析的常用打法过一遍。
一、先搞懂鸿蒙应用的"卡"是什么
鸿蒙基于 ArkUI 的渲染是 60/90/120Hz 可变的。判断是否卡顿，标准不是"我感觉一下"，而是 每一帧的渲染时间有没有超过 Vsync 周期：
只要一帧超过预算，UI 线程就会被压到下一个 Vsync，表面上就是"画面跟手慢一拍"。所以性能问题的本质往往是一帧内的某个阶段耗时超标：测量、布局、绘制、合成，或者更上游的 JS/ArkTS 解析、状态计算。
Profiler 工具能帮我们看到每一帧落在哪个阶段，这就是排查起点。
二、DevEco Profiler 全景
DevEco Profiler 在 Studio 顶部菜单 “View → Tool Windows → Profiler” 打开，或者快捷键 Alt + P。连接真机或远程模拟器（建议真机，模拟器的帧时间不准）后，它会自动开始采集。
主界面从上到下分为几条泳道：
第一次使用建议全开泳道，看一眼自己应用的整体形态。每个泳道都支持 “录制一段 → 圈出一段 → 下钻到调用栈” 这一套动作。
下面挑最常用的三个泳道展开说。
三、Frame 泳道：把"哪一帧卡了"摆到桌面上
打开 Frame 泳道后，横向时间轴上会画出每一帧：
绿色柱：正常帧，耗时在预算内。
黄色柱：警告帧，超过预算但未超时。
红色柱：丢帧（Dropped Frame），超过预算 1.5 倍以上。
把这些柱状图放大看，会发现里面嵌套着 ArkUI 内部的几个阶段：
[Measure][Layout][Draw][RenderService][Render]
拖动鼠标框出一段红色帧，下方面板会列出该帧内所有的"事件"，每条都带：
线程名（UI/Main、RenderService 等）
开始时间、持续时长
关联的代码位置（如果开了源码映射）
举个例子，我曾遇到首页下拉刷新后第二帧红了。Profiler 显示是 Layout 阶段耗 22ms，下钻发现是 Grid 组件在重测所有 item，但 item 里又嵌套了 LazyForEach，量并不大。回到代码看了一眼，发现是因为改了某个全局状态，导致整个列表重建——这是个典型的"细粒度问题被宏观错误信号掩盖"的场景。
Frame 泳道最有用的功能是 双击红帧直接跳转 Detail，里面能看到这一帧所有的事件、布局层级、组件名。这比肉眼看代码快。
四、Time 泳道：CPU 都花在哪儿了
Frame 看出"哪一帧坏了"之后，下一步要知道"这一帧内 CPU 跑啥去了"。Time 泳道会把一个时间区间内每个线程的 CPU 时间摊开：
主线程（UI/Main）：ArkTS 代码执行、状态计算、自定义组件渲染。
Worker / TaskPool 线程：异步任务跑在这里。
RenderService：原生渲染服务线程。
Top Down 视图按调用栈展开，从入口方法到叶子节点，看到 CPU 时间分布。一个健康的 UI 主线程，单帧内的 ArkTS 任务应该控制在 8ms 以内（120Hz 标准）。
实战里常见的元凶：
长任务：解析大数据 JSON、做正则匹配。一般超过 16ms 就该考虑异步化。
同步 IO：在 UI 线程读 Preferences、读文件、用同步方式发网络请求。
循环里做分配：
forEach里创建大量临时对象，触发 GC。复杂布局嵌套：嵌套太深，Measure/Layout 阶段会呈指数级耗时。
定位到方法后，下一步是在代码侧加上可观测埋点，让"偶发卡顿"也能被线上捕获。
五、用 hiTraceMeter 给方法加耗时点
Profiler 适合本地复现，但线上偶发卡顿怎么抓？答案是埋点。鸿蒙提供 hiTraceMeter，能在 trace 链里插入一段耗时区间，方便在 Profiler 或 AppGallery Connect 里回看。
import { hiTraceMeter } from '@kit.PerformanceAnalysisKit';
function loadFeedList(feedIds: string[]) {
hiTraceMeter.startTrace('loadFeedList', 1);
try {
// 业务代码
const data = buildDataStructure(feedIds);
return data;
} finally {
hiTraceMeter.finishTrace('loadFeedList', 1);
}
}
参数里的 1 是任务 ID，确保 startTrace 和 finishTrace 配对。如果你用 startAsyncTrace 配 finishAsyncTrace，还能跟踪跨 await 的耗时。
更系统的方式是把所有"业务关键路径"用 Trace 串起来，比如：
首页打开: loadConfig → loadFeedList → renderFeed
列表加载: fetchFeed → parseFeed → buildItems → onAppear
提交订单: validateForm → checkout → pay → notify
这样线上一旦某个用户反馈"打开慢"，我们能从 ACGC 上看到他那次 session 的 trace 数据，比看日志定位快几倍。
六、hiAppEvent：线上"卡顿事件"订阅
前面是采集。要让用户设备主动上报"我感觉卡了"，要用 hiAppEvent。
import { hiAppEvent, hilog } from '@kit.PerformanceAnalysisKit';
hiAppEvent.addWatcher({
watchId: 'freezeWatcher',
appEventFilters: [
{ domain: 'appfreeze', eventTypes: [hiAppEvent.EventType.CARD, hiAppEvent.EventType.TIMEOUT] },
],
onReceive: (event) => {
hilog.warn(0x0001, 'freeze', `上报: ${event.name}, params=${JSON.stringify(event.params)}`);
// 这里可以 POST 到自建服务器
},
});
鸿蒙的事件分类里有几类跟性能直接相关：
订阅后，用户每次遇到冻结都有一份带堆栈的报告落到 AppGallery Connect 后台。在 ProGuard 启用之前，先把堆栈符号化保留好——否则堆栈全是 lambda$0 之类，看不出问题。
七、heap 视角：内存剖析基础
内存这一项，专业开发者独立工具就够了（DevEco Profiler 的 Heap 泳道）。但要避免三个误区：
看顶部的曲线没用。鸿蒙的 GC 是分代式的，年轻代频繁 GC 在 60 帧以内肉眼看不到，但掉帧是从这里开始。
Leak 不一定增长。要看是否"释放后又涨回来"，所以抓两次 Heap Diff 才有用。
native heap 看不到。HSP 里 native 内存不在 Profiler 的 Heap 视图里，要用
mallinfo或dumpsys meminfo之类查看。
标准动作：
触发怀疑场景 5-10 次。
主动
gc()几次，等到 Heap 曲线平稳。录制 Heap Diff，导出 Hprof。
用 Memory Analyzer（MAT）或 Android Studio 的 Memory Profiler 打开看。
鸿蒙当前官方还没有完全对齐的 MAT 工具，但 Hprof 格式做了兼容导出，可以用开源工具做基础分析。常见的大头：
Buffer/Uint8Array长期持有（往往是大文件预览）。Image组件未复用，频繁创建纹理。闭包对象滞留（很常见于 ArkTS 的状态管理）。
八、案例：列表滑动掉帧从定位到解决
讲个真实被"自家 app 卡"折磨过的案例——某项目 Feed 流页面下滑到第 50 条左右开始掉帧，Frame 泳道密集出现红色。每条 item 包含标题、摘要、作者、3 张缩略图，乍看不算复杂。
第一步，Frame 泳道 + 下钻 Layout 阶段，发现是 Grid 子组件测量耗时；第二步用 Allocation 看到 Image 对象在主线程批量分配；第三步怀疑是图片解码慢，把列表高度固定后，问题从"频繁卡顿"变成"首屏慢"。
接下来优化：
回归测试同样一段滑动，Frame 全绿，CPU 时间下降 35%。Profiler 的好处是这一切都不靠感觉，数字说话。
九、性能优化的"元规则"
最后想说几条跨工具的元规则：
没有量化别下手。Profiler 没截图，说"应用变快了"基本是心理作用。
优化要按帧预算反推。120Hz 屏 8ms 预算，一帧里啥都不能超。
本地复现优先。线上追查是第二步，本地能复现的问题解决代价最低。
二进制都要看。JS/ArkTS、native、HSP 各自有自己的工具，别只盯一边。
性能剖析不是炫技，是基本功。下一篇我们接着聊这个系列里另一个老被忽视的事——应用包体积。
参考阅读
鸿蒙开发者文档《性能分析工具 hiTraceMeter》
鸿蒙开发者文档《HiAppEvent 上报》
DevEco Studio 帮助《Profiler 使用指南》
《Android 性能优化典型案例》虽然平台不同，思路相通