📖 引言

在前面的几篇文章中，我们学习了各种性能优化的方法。但你有没有想过：怎么知道哪里有性能问题？怎么证明优化真的有效？怎么定位性能瓶颈的根因？

“感觉有点卡”、“好像有点慢”——这些模糊的感受不能指导优化。性能优化需要数据支撑，需要量化分析。没有数据的优化，就像蒙着眼睛走路——你不知道往哪走，也不知道走没走对。

DevEco Profiler就是鸿蒙开发的"性能听诊器"。它能帮你看清应用运行时的内部状态：CPU用了多少、内存怎么分配的、网络请求花了多久、帧率有没有掉、电量消耗在哪里。有了这些数据，性能优化就不再是靠感觉猜，而是有科学依据的精准打击。

你可能会问：Profiler能做什么？怎么连接设备？CPU分析怎么看？内存泄漏怎么找？网络瀑布图是什么？FPS掉帧怎么定位？启动时间怎么测？这么多功能，从哪里开始学？

这些问题都是Profiler初学者的常见困惑。DevEco Profiler功能强大，但也正因为功能多，很多人不知道从何入手，打开工具后看着一堆图表不知道该看什么。

本文将从Profiler的基础概念讲起，逐一介绍各个分析模块的使用方法：CPU分析、内存分析、网络分析、帧率分析、启动分析、功耗分析。不仅教你怎么用工具，更教你怎么分析数据、怎么定位问题、怎么验证优化效果。最后，我们会用「民族图鉴」的列表卡顿问题作为实战案例，带你走一遍完整的性能调优流程。

---

🎯 学习目标

完成本文后，你将能够：

• ✅ 了解DevEco Profiler的功能和支持的性能指标
• ✅ 学会CPU分析：找到热点函数、分析调用栈
• ✅ 掌握内存分析：堆快照、内存泄漏检测、对象分配追踪
• ✅ 学会网络分析：请求耗时、流量统计、瀑布图
• ✅ 掌握帧率分析：FPS监测、掉帧定位、Jank分析
• ✅ 学会启动分析：启动时间线、各阶段耗时
• ✅ 了解功耗分析：电量消耗、唤醒次数、网络使用
• ✅ 掌握性能调优的完整流程：发现问题→定位瓶颈→优化→验证
• ✅ 了解常见的性能陷阱与调优案例
• ✅ 能够用Profiler排查「民族图鉴」的实际性能问题

---

💡 需求分析

为什么需要性能分析工具？

1. 性能问题是"看不见"的

你能看到界面卡，但看不到为什么卡。是CPU算不过来？还是内存不够用？还是网络太慢？没有工具，你只能猜。

常见的"猜"的误区：

• “卡肯定是代码写得不好” → 可能是图片太大、渲染太慢
• “慢肯定是网络的锅” → 可能是主线程阻塞了
• “内存占用高肯定是泄漏了” → 可能是缓存策略导致的正常占用

工具的作用，就是把"看不见"的内部状态可视化，让你知道到底发生了什么。

2. 优化需要数据支撑

优化前，你需要数据来定位问题；优化后，你需要数据来验证效果。

没有数据的优化：

• 改了一堆代码，不知道有没有用
• 觉得"应该快了"，但快了多少不知道
• 可能越优化越慢，自己还不知道

有数据的优化：

• 精准定位瓶颈，只改需要改的地方
• 量化优化效果，快了多少一目了然
• 建立基线，防止性能退化

3. 性能问题往往很复杂

性能问题通常不是单一原因导致的，而是多个因素交织在一起。

比如列表卡顿，可能的原因：

• 列表项太复杂，渲染耗时
• 主线程有计算任务阻塞
• 图片加载太慢
• 内存频繁GC
• 动画不流畅

你需要工具来帮你抽丝剥茧，找到真正的根因。

DevEco Profiler 能做什么？

DevEco Profiler是华为官方提供的性能分析工具，集成在DevEco Studio中。它提供了多种分析能力：

分析模块	功能	解决的问题
CPU分析	热点函数、调用栈、CPU使用率	哪里的代码耗CPU？
内存分析	堆快照、对象分配、内存泄漏	内存用在哪了？有没有泄漏？
网络分析	请求耗时、流量、瀑布图	网络请求慢不慢？哪个请求最慢？
帧率分析	FPS、Jank、掉帧分析	画面流不流畅？哪里掉帧了？
启动分析	启动时间、阶段耗时	启动慢在哪一步？
功耗分析	电量、CPU、网络、唤醒	耗不耗电？哪部分耗电？

有了这些工具，性能问题就无所遁形了。

「民族图鉴」的性能挑战

让我们结合「民族图鉴」项目，看看哪些地方可能需要用到Profiler：

1. 列表滚动性能：56个民族的网格列表，滚动时会不会掉帧？
2. 启动速度：冷启动需要多长时间？能不能更快？
3. 内存使用：图片加载会不会导致内存占用过高？
4. 网络请求：AI聊天的网络请求耗时多少？
5. 动画流畅度：启动页动画、列表点击动画够不够丝滑？
6. 功耗表现：应用运行时耗电怎么样？

在本文的实战环节，我们将以"列表滚动卡顿"为例，演示如何用Profiler一步步排查问题。

---

🔧 核心实现

一、DevEco Profiler 基础

1. 怎么打开 Profiler

在DevEco Studio中：

• 菜单栏：View → Tool Windows → Profiler
• 或者直接点击底部工具栏的Profiler标签

打开后，你会看到设备选择和进程选择的界面。

2. 连接设备

使用Profiler需要连接真实设备（模拟器也可以，但真机数据更准确）。

连接步骤：

1. 用USB连接手机和电脑
2. 手机开启开发者模式和USB调试
3. DevEco Studio中选择你的设备
4. 安装并启动要分析的应用
5. 在Profiler中选择对应的进程

注意事项：

• 要用debug或profile版本的包，release版可能看不到详细数据
• 确保设备和电脑连接正常
• 杀掉其他后台应用，减少干扰

3. Profiler 界面概览

Profiler界面主要分为几个区域：

• 顶部：设备选择、进程选择、录制控制
• 左侧：分析模块选择（CPU、内存、网络等）
• 中间：时间线和图表区域
• 右侧：详细信息面板（选中某个数据点时显示）
• 底部：状态信息和日志

4. 基本使用流程

典型的分析流程：

1. 选择设备和进程
2. 选择要分析的模块（CPU、内存等）
3. 点击录制按钮开始录制
4. 在设备上操作应用（复现问题场景）
5. 点击停止按钮结束录制
6. 分析录制数据，定位问题

二、CPU分析

CPU分析帮你找到"最耗CPU的代码"。如果应用卡顿、发热，CPU分析是第一个要看的。

1. CPU 分析能告诉你什么

• CPU使用率：应用占用了多少CPU
• 热点函数：哪些函数执行时间最长、调用次数最多
• 调用栈：函数的调用关系，谁调用了谁
• 线程状态：各个线程在做什么

2. 怎么看 CPU 分析结果

CPU使用率图表：

• 横轴是时间
• 纵轴是CPU使用率（百分比）
• 不同颜色代表不同线程
• 可以放大缩小，查看某个时间段的细节

火焰图（Flame Chart）：

• 每个横条代表一个函数
• 横条越宽，代表占用时间越长
• 上下关系代表调用关系（下面的调用上面的）
• 最宽的那些横条就是热点函数

调用栈（Call Chart）：

• 类似火焰图，但显示方式不同
• 可以看到完整的调用链
• 可以按时间排序，也可以按调用次数排序

3. 定位热点函数的方法

步骤：

1. 看CPU使用率曲线，找到高的时间段
2. 放大那个时间段
3. 看火焰图，找最宽的横条
4. 顺着调用栈往下找，找到你自己的代码
5. 分析那个函数为什么慢

注意：

• 系统函数占比高是正常的，重点看你自己的代码
• 调用次数多不一定慢，单次慢但调用少也可能是问题
• 要结合业务场景分析，看这个函数该不该花这么多时间

4. 「民族图鉴」场景：列表卡顿的CPU分析

假设「民族图鉴」的列表滚动时有点卡，我们用CPU分析来排查：

操作步骤：

1. 打开CPU分析，开始录制
2. 在设备上快速滚动列表
3. 滚动几秒后停止录制
4. 分析数据

可能的发现：

• 情况A：主线程有大量的布局计算 → 列表项太复杂
• 情况B：有很多GC调用 → 内存分配太频繁
• 情况C：某个自定义函数占比很高 → 函数效率低
• 情况D：图片解码占比高 → 图片太大或太多

根据不同的发现，采取不同的优化策略。

三、内存分析

内存分析帮你看清"内存都用在哪了"。内存泄漏、内存溢出、频繁GC，这些问题都需要内存分析来定位。

1. 内存分析能告诉你什么

• 内存使用趋势：内存占用随时间的变化
• 堆快照（Heap Dump）：某个时间点所有对象的详细信息
• 对象分配追踪：对象是在哪里创建的
• 内存泄漏检测：哪些对象本该被回收却没回收

2. 内存曲线图怎么看

内存曲线图显示的是内存使用量随时间的变化。

正常的内存曲线：

• 有升有降（锯齿状）
• 整体平稳，不会持续上涨
• GC后内存会下降

异常的内存曲线：

• 持续上涨，降不下来 → 可能有内存泄漏
• 频繁的锯齿（频繁GC） → 对象分配太频繁
• 突然的尖峰 → 瞬间分配了大量对象

3. 堆快照（Heap Dump）

堆快照是某个时间点内存中所有对象的"快照"。

能看到什么：

• 有哪些类的对象
• 每个类有多少个实例
• 每个实例占用多少内存
• 对象的引用关系（谁引用了谁）

怎么分析：

1. 拍几张堆快照（操作前、操作后、GC后）
2. 对比不同快照，看哪些对象增长了
3. 找到可疑的对象，看它们的引用链
4. 判断是不是泄漏

4. 内存泄漏的排查方法

内存泄漏的典型特征：

• 操作后内存上涨，GC后也降不下来
• 反复操作，内存持续上涨
• 某个类的实例数量异常多

排查步骤：

1. 操作前拍一张堆快照（基线）
2. 执行可疑操作（比如进入详情页再返回）
3. 手动触发GC
4. 再拍一张堆快照
5. 对比两张快照，看哪些对象只增不减
6. 查看这些对象的引用链，找到为什么没被回收

常见的泄漏原因：

• 静态变量持有Activity/Page的引用
• 监听器/回调没有注销
• 定时器没有清除
• 闭包持有外部引用
• 单例持有Context引用

5. 「民族图鉴」场景：图片内存分析

「民族图鉴」有56个民族的封面图，图片内存占用是值得关注的。

分析步骤：

1. 打开内存分析
2. 进入列表页，观察内存变化
3. 快速滚动列表，看内存波动
4. 进入详情页，看大图加载后的内存
5. 返回列表页，看内存能不能降下来

可能的问题：

• 图片太大，内存占用高 → 压缩图片、用合适的尺寸
• 图片缓存太多 → 限制缓存数量
• 图片没回收 → 检查引用，确保能被GC

四、网络分析

网络分析帮你看清"网络请求都花了多长时间"。网络慢、请求多、流量大，这些问题都可以用网络分析来定位。

1. 网络分析能告诉你什么

• 请求列表：所有的网络请求
• 请求耗时：每个请求花了多久
• 流量统计：上传下载了多少数据
• 瀑布图：请求的时间线
• 请求详情：请求头、响应头、请求体、响应体

2. 瀑布图（Waterfall Chart）

瀑布图是网络分析中最有用的视图之一。

怎么看：

• 每行是一个请求
• 横向位置表示时间
• 条的长度表示耗时
• 不同颜色表示不同阶段（DNS、连接、发送、等待、接收）

能发现什么问题：

• 请求是不是串行的（一个完了才开始下一个）
• 哪个请求最慢
• 慢在哪个阶段（DNS慢？连接慢？服务器慢？）
• 有没有不必要的请求

3. 网络性能优化的常见方向

根据瀑布图的分析结果，可以针对性地优化：

问题	优化方向
DNS慢	DNS预解析、HTTPDNS
连接慢	长连接、连接复用
服务器慢	后端优化、CDN
数据量大	压缩、分页、减少字段
请求太多	合并请求、减少不必要的请求
请求串行	并行请求

4. 「民族图鉴」场景：AI聊天网络分析

「民族图鉴」有AI聊天功能（AIChatPage.ets），我们可以分析一下：

分析内容：

• 发送一条消息后，多久能收到回复
• 请求的各个阶段耗时多少
• 请求和响应的数据量有多大
• 有没有可以优化的地方

可能的优化点：

• 如果首包时间长 → 后端优化
• 如果数据量大 → 考虑流式响应
• 如果请求太多 → 合并请求

五、帧率分析

帧率分析帮你判断"画面流不流畅"。动画卡顿、列表掉帧，这些问题都可以用帧率分析来量化。

1. 帧率基础

帧率（FPS）：每秒显示多少帧。

• 60fps：流畅
• 45-60fps：基本流畅，偶尔卡顿
• 30-45fps：明显卡顿
• 30fps以下：非常卡

Jank（卡顿帧）：渲染时间超过16.6ms的帧。

• Jank越少越好
• 连续Jank就是明显的卡顿

2. 帧率分析能告诉你什么

• 实时FPS：当前帧率是多少
• Jank统计：有多少卡顿帧
• 掉帧分布：哪些时间段掉帧
• 帧耗时：每帧花了多长时间

3. 怎么定位掉帧原因

看到掉帧只是第一步，更重要的是找到为什么掉帧。

掉帧的可能原因：

• CPU太忙（主线程阻塞）
• GPU渲染太慢
• 布局计算太复杂
• 图片解码
• 内存GC

定位方法：

1. 在帧率图上找到掉帧的时间段
2. 同时看CPU分析，那时候CPU在做什么
3. 看内存分析，那时候有没有GC
4. 结合起来判断根因

这就是为什么Profiler要同时看多个维度——掉帧是结果，原因可能在CPU、内存、GPU任何一个地方。

4. 「民族图鉴」场景：列表滚动帧率分析

列表滚动是最容易掉帧的场景之一。让我们用帧率分析来测一测「民族图鉴」的列表：

测试步骤：

1. 打开帧率分析，开始录制
2. 缓慢滚动列表10秒
3. 快速滚动列表10秒
4. 停止录制，分析数据

看什么：

• 平均FPS是多少
• 有没有Jank
• 快速滚动时掉帧严不严重
• Jank集中在什么时候

如果掉帧严重：

• 结合CPU分析，看是不是主线程太忙
• 结合内存分析，看是不是GC频繁
• 看列表项是不是太复杂

六、启动分析

启动速度是用户对应用的第一印象。启动分析帮你看清"启动时间都花在哪了"。

1. 启动的两个阶段

冷启动：应用完全没运行，从点击图标开始。

• 耗时最长，也是优化的重点

热启动：应用在后台，切换到前台。

• 通常很快，一般不需要特别优化

2. 启动分析能告诉你什么

• 总启动时间：从点击到首帧显示用了多久
• 阶段耗时：每个阶段花了多久
  • Application创建
  • Ability创建
  • 首帧渲染
• 关键路径：哪些任务在启动时执行

3. 启动优化的常见方向

阶段	优化方向
Application初始化	延迟初始化、懒加载、异步初始化
首个Ability	简化布局、减少首屏数据
首帧渲染	减少控件数量、简化布局层级
资源加载	预加载、懒加载

4. 「民族图鉴」场景：启动速度分析

「民族图鉴」有启动页（SplashPage.ets），让我们分析一下启动流程：

分析内容：

• 冷启动总耗时
• 启动页动画会不会太慢
• 首页加载花了多久
• 有没有可以延迟初始化的东西

可能的优化点：

• 非核心服务延迟初始化
• 启动页不要太长（当前2.2秒，还算合理）
• 首页数据预加载

七、功耗分析

功耗分析帮你看清"电量都耗在哪了"。后台耗电、发热，这些问题都可以用电功耗分析来排查。

1. 功耗分析能告诉你什么

• 电量消耗：应用用了多少电
• CPU使用：CPU唤醒频率、使用时长
• 网络使用：移动网络/WiFi使用时长
• 唤醒次数：唤醒锁的使用情况
• 定位使用：GPS使用时长

2. 怎么看功耗数据

功耗曲线：

• 横轴是时间
• 纵轴是功耗估计值
• 可以看到功耗随时间的变化

分模块统计：

• CPU耗电占比
• 网络耗电占比
• GPS耗电占比
• 其他模块耗电占比

3. 「民族图鉴」场景：后台功耗测试

测试「民族图鉴」在后台的功耗表现：

测试步骤：

1. 打开功耗分析，开始录制
2. 使用应用几分钟
3. 将应用切到后台
4. 后台静置10分钟
5. 停止录制，分析数据

看什么：

• 后台时CPU使用率高不高
• 后台有没有网络请求
• 定位有没有关闭
• 唤醒锁有没有释放

八、系统工具与第三方工具

DevEco Profiler是最主要的性能分析工具，但不是唯一的工具。系统也自带了一些工具，还有一些第三方工具可以辅助我们做性能分析。

1. 系统自带的工具

鸿蒙系统本身也提供了一些性能相关的工具和能力。

开发者选项：
手机设置里的「开发者选项」里有很多性能相关的开关和工具：

• GPU呈现模式分析：可以在屏幕上显示帧率条形图，直观看到掉帧情况
• GPU过度绘制：用颜色标记过度绘制的区域，帮助优化渲染
• 严格模式：检测主线程的耗时操作，发现潜在的卡顿问题
• 显示面更新：屏幕刷新时会闪烁，帮助识别不必要的重绘
• 内存使用情况：可以看到各个应用的内存使用情况

这些工具的好处：

• 不需要连接电脑，直接在手机上就能看
• 直观，一眼就能看出问题
• 适合快速定位问题

局限性：

• 只能看个大概，不够精细
• 不能深入分析调用栈、对象分配等细节
• 数据不能保存和对比

「民族图鉴」怎么用：

• 快速测试列表流畅度：开GPU呈现模式，滚动列表看条形图
• 检查过度绘制：开过度绘制开关，看页面颜色是不是太红
• 测试后台性能：切到后台看内存会不会持续上涨

2. ADB命令（适用时）

如果有对应的调试命令行工具，也可以用命令来获取一些性能数据：

常用的命令思路：

• 查看内存使用：获取应用的内存占用信息
• 查看CPU使用：获取进程的CPU占用率
• 查看帧率：获取Surface的帧率数据
• 查看启动时间：测量应用的启动耗时

💡 注意：
鸿蒙系统有自己的工具链，具体的命令和工具以官方文档为准。
这里只是提供一个思路——除了图形化的Profiler，命令行工具也是很有用的补充。

3. 第三方工具

除了官方工具，还有一些第三方工具也可以用来做性能分析。

通用工具类：

• 图片压缩工具：TinyPNG、Squoosh、ImageOptim——优化图片资源
• 包体积分析工具：分析安装包的构成，找到占空间大的资源
• 网络抓包工具：Charles、Fiddler——分析网络请求的耗时和流量

性能监控类：

• 线上性能监控平台：如果应用上线了，可以接入APM（应用性能监控）平台
• 错误监控平台：Sentry之类的——监控崩溃和性能异常
• 用户行为分析：结合用户行为数据，分析性能对用户的影响

「民族图鉴」的工具推荐：

• 开发阶段：主要用DevEco Profiler
• 图片优化：Squoosh（在线工具）或sharp（Node.js库）
• 网络调试：用系统自带的网络调试功能或抓包工具
• 包体积分析：DevEco Studio的构建报告 + 手动分析

4. 怎么选择合适的工具？

工具很多，什么时候用什么？这里给大家一个选择参考：

问题类型	首选工具	辅助工具
卡顿/掉帧	DevEco Profiler（帧率+CPU）	GPU呈现模式
内存问题	DevEco Profiler（内存）	系统内存统计
启动慢	DevEco Profiler（启动）	手动计时
网络慢	DevEco Profiler（网络）	抓包工具
耗电	DevEco Profiler（功耗）	系统电池统计
包体积大	构建报告	手动分析资源
图片太大	Squoosh/sharp	看图软件

原则：

• 先简单后复杂：先用简单工具快速定位，再用复杂工具深入分析
• 先宏观后微观：先看整体数据，再深入细节
• 交叉验证：用不同的工具验证同一个结论，确保准确

💡 工具是手段，不是目的：
工具只是帮你发现问题、定位问题的手段。
重要的是分析问题的思路和解决问题的能力。
不要沉迷于研究工具，而忘了真正要解决的问题。

---

九、性能调优的完整流程

学了这么多分析模块，该怎么把它们用起来？性能调优有一套科学的流程：

第一步：发现问题

怎么发现问题：

• 用户反馈（“卡”、“慢”、“耗电”）
• 测试发现
• 自己使用时感觉到
• 性能监控告警

关键：把模糊的感受变成具体的问题描述。

• ❌ “有点卡” → 什么场景卡？卡到什么程度？
• ✅ “列表快速滚动时明显掉帧”

第二步：复现场景

要分析问题，首先要能稳定复现。

复现要点：

• 明确操作步骤
• 明确设备环境
• 明确网络环境
• 尽量排除干扰因素

如果问题不能稳定复现，分析起来会很困难。

第三步：定位瓶颈

用Profiler分析，找到性能瓶颈。

定位思路：

1. 先用最相关的分析模块初步排查
2. 再结合其他模块交叉验证
3. 从现象到根因，层层深入

示例：列表卡顿

1. 先看帧率分析 → 确实有Jank
2. 再看CPU分析 → 主线程布局计算耗时
3. 再看内存分析 → 没有频繁GC
4. 结论：列表项布局太复杂

第四步：优化实施

根据定位结果，实施针对性的优化。

优化原则：

• 先优化收益最大的
• 一次只改一个地方
• 每改一处都测试验证

第五步：验证效果

优化后，再用Profiler测一遍，看有没有改善。

验证要点：

• 同样的测试场景
• 同样的设备环境
• 对比优化前后的数据
• 确认没有引入新问题

如果有效，就继续优化下一个点；如果无效，就回到第三步重新分析。

九、常见的性能陷阱与调优案例

陷阱1：过早优化

还没弄清楚问题在哪，就开始瞎优化。

• 结果：优化了半天，根本不是瓶颈
• 正确做法：先测量，再优化

陷阱2：过度优化

把时间花在收益很小的优化上。

• 结果：投入产出比太低
• 正确做法：先优化20%带来80%收益的部分

陷阱3：优化了A，恶化了B

比如为了省内存，每次都重新加载图片，结果更卡了。

• 结果：按下葫芦浮起瓢
• 正确做法：权衡利弊，综合考虑

陷阱4：只测高端机

高端机上很流畅，低端机上卡死。

• 结果：大量中低端用户体验差
• 正确做法：用目标用户的主流设备测试

陷阱5：只看平均值，忽略极值

平均FPS 55，看起来还不错，但中间有几帧掉到20，用户感觉很明显。

• 结果：用户觉得卡，但数据看起来还行
• 正确做法：关注最差值、百分位数（P90、P95），不能只看平均

陷阱6：优化完了不验证

改了一堆代码，觉得"应该快了"，但实际没测。

• 结果：可能越优化越慢，自己还不知道
• 正确做法：优化前后都测，用数据证明优化有效

陷阱7：把性能优化当一次性任务

上线前突击优化一波，之后就不管了。

• 结果：版本迭代几次，性能又退回去了
• 正确做法：建立性能基线，定期做回归测试，防止性能退化

十、Profiler使用技巧与小贴士

用了这么久Profiler，积累了一些实用的小技巧。分享给大家，帮你少走弯路。

技巧一：录制要有明确的目标

问题：很多人一打开Profiler就开始录，录了半天不知道要看什么。

正确做法：

• 录制前先想清楚：我要分析什么问题？
• 是卡顿？看帧率和CPU
• 是内存？看内存曲线和堆快照
• 是网络慢？看网络瀑布图
• 带着问题去录，效率才高

**示例：

❌ 错误：打开Profiler，随便点点，录10分钟，然后盯着数据发呆
✅ 正确：我要分析列表卡顿问题 → 打开帧率和CPU → 滚动列表30秒 → 停止 → 分析

技巧二：控制录制的时长

不是越长越好：

• 录得太长，数据太多，分析起来费劲
• 找问题的时候，还要从一大堆数据里找，效率低

也不是越短越好：

• 录得太短，可能漏掉关键信息
• 有些问题需要一定时间才能暴露出来

合适的时长：

• 卡顿分析：30秒-1分钟就够了
• 内存分析：3-5分钟，看趋势
• 启动分析：就录启动那几秒
• 功耗分析：至少10分钟以上

技巧：

• 开始录制后，等2秒再操作
• 操作完了，再等2秒再停止
• 这样数据比较完整

技巧三：一次只分析一个问题

问题：同时分析多个问题，数据混在一起，分不清哪个是哪个。

正确做法：

• 一次只针对一个问题
• 分析完一个，再分析下一个
• 每个问题单独录制一次

例子：
不要一边滚动列表，一边切换页面，还一边加载图片
→ 最后不知道卡顿时是哪个操作导致的

应该：

• 先录滚动列表的场景
• 再录切换页面的场景
• 再录加载图片的场景

这样每个场景的数据都是干净的，分析起来更清楚。

技巧四：做好操作记录

问题：录了一大堆数据，回头忘了当时做了什么操作。

正确做法：

• 录制时记录下操作步骤
• 什么时间点做了什么
• 这样分析的时候可以对应起来看

怎么记录：

• 简单的可以自己记个时间点
• 复杂的可以边录屏，或者用笔记下来
• 或者在代码里加日志标记（关键操作打印日志）

好处：

• 看到数据上的波峰，对应一下操作记录
• 一下子就能知道是什么操作导致的
• 大大提高分析效率

技巧五：学会用对比法

问题：看一堆数据，不知道什么是"正常"的。

正确做法：

• 正常状态录一份（基线）
• 有问题的状态录一份
• 两份对比着看

对比什么：

• 优化前 vs 优化后
• 正常操作 vs 异常操作
• 高端机 vs 低端机

好处：

• 一对比，差异就出来了
• 哪些数据异常一目了然
• 不容易漏掉问题

技巧六：善用搜索和过滤

问题：数据太多，找不到重点。

正确做法：

• 用搜索功能找你关心的函数
• 用过滤功能排除无关的
• 聚焦在关键数据上

常用的过滤：

• 只看自己应用的进程
• 只看主线程
• 只看某个时间段
• 只看某个模块的函数

好处：

• 排除干扰，聚焦问题
• 分析效率高很多

技巧七：截图和保存数据

问题：分析完了，过几天想再看，找不到当时的数据了。

正确做法：

• 重要的分析数据保存下来
• 关键的截图截一下
• 写个简单的分析记录

保存什么：

• Profiler的录制文件
• 关键图表的截图
• 分析结论和优化建议
• 优化前后的对比数据

为什么要保存：

• 以后可以回头看
• 可以和下次的对比
• 可以分享给团队其他人
• 积累经验，形成知识库

技巧八：多工具交叉验证

问题：一个工具测出来的数据，不知道准不准？

正确做法：

• 重要的结论，用不同的方法验证
• Profiler测了，再用系统工具看看
• 数据一致，结论才可靠

例子：

• Profiler说FPS是55
• 打开GPU呈现模式，看看是不是也差不多
• 两个对得上，说明没问题
• 对不上，找找原因

好处：

• 避免工具的bug误导你
• 结论更可靠
• 理解更深入

💡 Profiler使用的核心原则：
工具是死的，人是活的。
最重要的不是你有多熟悉工具，而是你有多清楚你要解决的问题。
带着问题去用工具，工具才能发挥最大的价值。

---

十一、性能分析的注意事项

用Profiler做性能分析，有一些坑需要注意。避开这些坑，分析结果才准确可靠。

1. 测试环境要稳定

为什么重要：
环境不稳定，测出来的数据就没有参考价值。这次测是50fps，下次测是55fps，你不知道是优化有效，还是环境变了。

要控制的变量：

• 设备：每次用同一台设备测试
• 系统版本：不要今天测完明天就更系统
• 网络环境：测网络相关的，要保证网络稳定
• 后台应用：测试前清理后台，减少干扰
• 电量：低电量时系统可能降频，影响性能
• 温度：手机太热也会降频，影响测试结果

最佳实践：

• 准备一台专门的测试机
• 测试前重启手机，清理后台
• 在同样的环境、同样的时间测试
• 每次测3-5次，取平均值

2. 不要在Debug版测性能

为什么：
Debug版本有很多调试信息，性能比Release版差很多。用Debug版测出来的结果，不能代表真实用户的体验。

Debug vs Release的差异：

• Debug版有调试符号，代码没优化
• Release版开启了混淆、压缩、优化
• 两者性能可能差20%-50%

正确做法：

• 性能测试用Release版（或Profile版）
• 定位问题的时候可以用Debug版（能看到更多信息）
• 最终验收一定要用Release版

💡 小技巧：
可以打一个Profile版本，既有性能数据，又能看到一些调试信息。
具体怎么打Profile包，参考DevEco Studio的文档。

3. 测试时间要足够

为什么：
只测几秒，结果可能有偶然性。刚好赶上GC了，或者刚好碰上系统后台任务，结果就不准。

测多久合适：

• 启动测试：至少测3次冷启动，取平均值
• 列表滚动：至少滚动10-30秒
• 内存测试：至少操作5分钟，看趋势
• 功耗测试：至少测30分钟以上

怎么判断够不够：

• 数据稳定了，没有大的波动
• 多测几次，结果差不多
• 能稳定复现问题

4. 不要只看平均值

为什么：
平均值会掩盖问题。比如平均FPS 55，看起来还不错，但可能中间有几帧掉到了20，用户感觉很明显。

要看哪些统计量：

• 平均值：整体水平
• 中位数：中间水平，比平均值更稳定
• 百分位：比如P90（90%的帧都高于这个值）
• 最差值：最坏情况
• 波动情况：是稳定的，还是忽高忽低

例子：

方案A：平均55fps，最低50fps，波动小 → 体验好
方案B：平均58fps，最低30fps，波动大 → 体验差

虽然方案B平均更高，但用户会觉得方案A更流畅，因为它稳定。

5. 观察者效应

什么是观察者效应：
你在观察（测性能）的时候，观察本身会影响结果。

Profiler的影响：

• 开启Profiler会增加一些开销
• 实时监控会占用一些CPU和内存
• 测出来的结果会比实际差一点

怎么应对：

• 知道有这个影响，心里有数就行
• 对比测试要在同样的条件下（都开Profiler，或者都不开）
• 关注相对值（优化了多少），而不是绝对值

6. 相关不等于因果

什么意思：
A和B同时发生，不代表A是B的原因。

例子：
你看到"内存涨了，同时FPS降了"，就以为是内存导致的卡顿。但也可能是：

• 图片加载导致了内存涨，同时图片解码导致了FPS降
• 真正的原因是图片太大，内存和卡顿都是结果

怎么避免误判：

• 不要轻易下结论
• 多做对比实验
• 控制变量，一次只改一个东西
• 用不同的方法交叉验证

7. 不要过度分析

什么是过度分析：
花了很多时间研究一个根本不重要的问题。

例子：

• 为了1ms的优化，研究了半天
• 反复测来测去，数据已经很明确了还是不放心
• 追求完美，想把所有问题都一次性解决

正确做法：

• 先解决最大的问题
• 收益递减的时候就停
• 抓住重点，不要纠结细节
• 优化完了验证一下，有效就继续下一个

💡 性能分析的哲学：
性能分析是工具，不是目的。
目的是解决问题，不是把每个数据都研究透。
能用最少的时间找到最大的问题，就是最高效的分析。

---

十一、实战：用Profiler排查「民族图鉴」列表卡顿问题

让我们通过一个完整的案例，把前面学到的知识串起来。

背景

用户反馈：「民族图鉴」的民族列表快速滚动时有点卡，尤其是网格模式。

第一步：复现问题

设备：中低端鸿蒙手机
操作：进入民族列表页，快速上下滚动
现象：滚动时偶尔掉帧，感觉不够丝滑

第二步：初步分析（帧率分析）

先打开帧率分析，看看FPS到底怎么样。

测试结果：

• 平均FPS：52fps
• Jank率：约8%
• 快速滚动时最低掉到40fps

结论：确实有性能问题，需要优化。

第三步：CPU分析

打开CPU分析，同时滚动列表，看看CPU在忙什么。

分析发现：

• 主线程占用率高，特别是布局计算
• 图片解码也占了一定比例
• 没有明显的GC

第四步：深入分析

列表项复杂度分析：

• 网格模式下，每行有4个列表项
• 每个列表项有：圆形图标（Text背景色）、民族名称、人口数
• 看起来不复杂啊？

等等，再仔细看——每个列表项都有圆角和背景色。56个列表项，每个都有圆角，会不会是圆角渲染的问题？

再看内存：

• 滚动时内存波动不大
• 没有频繁GC

再看GPU：

• 如果能看GPU渲染的话，可能会发现圆角导致的overdraw

第五步：假设与验证

假设1：圆角绘制开销大

验证：把圆角去掉，看FPS有没有提升。

• 结果：FPS提升不明显 → 不是主要原因

假设2：列表项创建太慢

验证：用LazyForEach已经是懒加载了，会不会是每次创建都做了太多事？

• 检查代码，发现列表项有语言判断逻辑
• 但这个很简单，应该不是问题

假设3：点击状态导致的全量更新

回到代码，看到pressedIndex是全局状态：

@State pressedIndex: number = -1;

// 每个列表项都依赖pressedIndex
.opacity(this.pressedIndex === index ? 0.8 : 1)

验证：把pressedIndex改成组件内状态，FPS有没有提升？

• 结果：FPS从52提升到56，Jank率下降 → 确实有改善

但还不够，继续找。

假设4：搜索面板的阴影效果

搜索面板有shadow，会不会创建了太多层？

验证：去掉shadow，用边框代替。

• 结果：FPS提升到57，更流畅了 → 有效果

第六步：综合优化

根据分析结果，实施以下优化：

1. 列表项状态本地化：将pressedIndex改为组件内状态
2. 搜索面板阴影优化：用边框模拟阴影
3. 列表项简化：进一步简化列表项结构
4. 图片缓存优化：确保封面图正确缓存（虽然列表页没用封面图）

第七步：验证效果

优化后再测：

• 平均FPS：58fps
• Jank率：2%以下
• 快速滚动时最低52fps

用户主观感受：流畅多了，基本感觉不到卡顿。

优化成功！

总结

这个案例告诉我们：

1. 性能问题往往不是单一原因，多个小问题叠加起来就会明显
2. Profiler帮我们定位方向，但具体原因还需要结合代码分析
3. 优化要循序渐进，改一个测一个
4. 有时候看起来"很小"的优化，累积起来效果也很明显

---

📋 常见性能问题快速定位指南

遇到性能问题不知道从哪下手？这里有一份快速定位指南，帮你按图索骥，快速找到问题方向。

指南一：页面卡顿/掉帧

现象：操作不跟手，滑动时一顿一顿的。

快速定位步骤：

1. 打开GPU呈现模式 / 帧率分析
   ↓
2. 确认是不是真的掉帧（FPS < 55？）
   ↓
3. 掉帧时看CPU占用
   ├─ 主线程CPU高 → 布局计算/逻辑计算太多
   │  → 看CPU分析，找热点函数
   ├─ Render线程CPU高 → 渲染太复杂
   │  → 检查布局层级、过度绘制
   └─ 都不高 → 可能是GPU问题
      → 检查图片大小、透明度、阴影等

常见原因Top5：

1. 列表项太复杂，布局层级深
2. 主线程有耗时计算
3. 图片太大，解码耗时
4. 频繁GC（内存分配太多）
5. 动画属性选择不当（用了非高性能属性）

指南二：启动慢

现象：点击图标后，要等很久才能看到内容。

快速定位步骤：

1. 测冷启动时间，记录下来
   ↓
2. 用启动分析工具，看各阶段耗时
   ├─ Application初始化慢 → 初始化的东西太多
   │  → 延迟初始化、异步初始化
   ├─ 首帧渲染慢 → 首屏布局太复杂
   │  → 简化首屏、懒加载非核心内容
   └─ 数据加载慢 → 接口请求慢
      → 预加载、缓存、骨架屏

常见原因Top5：

1. Application里初始化了太多东西
2. 首屏布局太复杂
3. 启动页动画太长
4. 首页数据同步加载
5. 没有利用好预加载

指南三：内存占用高/内存泄漏

现象：用着用着内存越来越高，或者退出页面后内存降不下来。

快速定位步骤：

1. 看内存曲线
   ├─ 持续上涨，降不下来 → 可能有泄漏
   │  ↓
   │  拍堆快照 → 对比操作前后 → 找只增不减的对象
   │  → 看引用链 → 找到泄漏点
   │
   ├─ 频繁锯齿（频繁GC） → 对象分配太频繁
   │  ↓
   │  看对象分配追踪 → 什么对象在频繁创建
   │  → 对象池、复用、减少临时对象
   │
   └─ 突然的尖峰 → 瞬间分配了大量对象
      ↓
      看尖峰时在做什么 → 是不是一次性加载了太多东西
      → 分批加载、懒加载

常见原因Top5：

1. 图片太大太多
2. 监听器/回调没有注销
3. 静态变量持有大对象引用
4. 闭包持有外部引用
5. 缓存没有上限，无限增长

指南四：网络慢

现象：加载数据慢，转圈转半天。

快速定位步骤：

1. 用网络分析，看瀑布图
   ├─ 请求排队等很久 → 并发请求太多
   │  → 控制并发数、合并请求
   ├─ 服务器响应慢 → 后端问题
   │  → 后端优化、缓存数据
   ├─ 下载慢 → 数据量太大
   │  → 压缩、分页、按需加载
   └─ 频繁请求 → 请求太频繁
      → 防抖节流、缓存、批量

常见原因Top5：

1. 请求太多太频繁
2. 返回数据量太大
3. 没有缓存，每次都重新拉
4. 串行请求（可以并行的没并行）
5. 图片太大，加载慢

指南五：耗电快

现象：用户反馈用了你的应用后，电量掉得快。

快速定位步骤：

1. 看系统电池统计，大概知道哪块耗电
   ↓
2. 用电功耗分析工具，深入分析
   ├─ CPU耗电高 → CPU占用高
   │  → 减少计算、优化算法、批量处理
   ├─ 网络耗电高 → 网络请求太频繁
   │  → 合并请求、减少轮询、缓存
   ├─ GPS耗电高 → 定位用太多
   │  → 及时关闭、降低精度、减少频率
   └─ 后台耗电高 → 后台活动太多
      → 检查后台任务、定时器、唤醒锁

常见原因Top5：

1. 定位开了忘了关
2. 后台定时器太多
3. 网络请求太频繁
4. 唤醒锁没有释放
5. 持续的CPU计算（比如动画不停）

💡 指南的使用方法：

1. 先确定问题类型（卡顿？慢？耗电？）
2. 按步骤一步步排查
3. 找到方向后，再用Profiler深入分析
4. 不要上来就瞎试，先定位再优化

---

❓ 常见问题

Q1：Profiler连接不上设备怎么办？

排查步骤：

1. 确认USB线没问题，换一根试试
2. 确认手机开启了开发者模式和USB调试
3. 确认DevEco Studio识别到了设备
4. 重启adb服务
5. 重启手机和电脑再试

注意：

• 要用原装或质量好的数据线
• 有些手机需要在弹窗中授权调试
• 鸿蒙设备可能需要开启"USB调试（安全设置）"

Q2：Profiler数据不准怎么办？

可能原因和解决方法：

1. debug版和release版差异：

   • debug版有调试信息，性能比release版差
   • 建议用profile版或release版测（但可能看不到详细函数名）

2. 其他应用干扰：

   • 后台其他应用也在占用资源
   • 测试前清理后台，尽量减少干扰

3. 测量时间太短：

   • 只测了几秒，数据可能有偶然性
   • 建议测30秒以上，取平均值

4. 设备状态不稳定：

   • 刚开机/刚亮屏时，系统可能在做后台任务
   • 等设备稳定后再测试

Q3：打开Profiler不知道该看什么？

这是初学者最常见的问题。建议从以下几个步骤开始：

第一步：明确你要解决什么问题

• 卡顿？看帧率和CPU
• 内存高？看内存分析
• 网络慢？看网络分析
• 耗电？看功耗分析

第二步：先看总览，再看细节

• 先看整体曲线，找异常的时间段
• 再放大那个时间段，看详细数据

第三步：从你认识的东西开始

• CPU分析：找你自己写的函数
• 内存分析：找你认识的类名
• 网络分析：看你知道的接口URL

第四步：多练多用

• 用多了自然就熟悉了
• 每次分析都做笔记，总结经验

Q4：CPU分析里全是系统函数，找不到自己的代码？

这很正常，系统函数本来就占大多数。

找自己代码的方法：

1. 用搜索功能，搜索你的包名/类名/函数名
2. 看火焰图最顶层（最上层通常是应用代码）
3. 按"自耗时"排序，看哪些函数自己执行时间长
4. 过滤掉系统库，只看应用代码

注意：

• 系统函数占比高不一定是问题
• 重点看"你的代码调用系统函数"的那些路径

Q5：内存分析怎么判断是不是泄漏？

内存泄漏的判断需要对比，不能只看一张快照。

判断方法：

1. 操作前后对比：

   • 操作前拍一张
   • 操作后拍一张（比如进入详情页再返回）
   • GC后再拍一张
   • 如果某个对象只增不减，可能是泄漏

2. 多次操作对比：

   • 反复操作多次
   • 如果每次操作内存都涨一点，降不下来，很可能是泄漏

3. 看引用链：

   • 找到可疑对象
   • 看谁在引用它
   • 判断这个引用是不是合理的

容易误判的情况：

• 缓存：缓存占用是正常的，不是泄漏
• 单例：单例对象一直存在是正常的
• 静态变量：静态变量本来就不会被回收

Q6：帧率多少才算合格？

这个没有绝对标准，要看场景和设备。

参考标准：

• 60fps：优秀，非常流畅
• 55-60fps：良好，基本流畅
• 50-55fps：一般，偶尔能感觉到卡
• 50fps以下：较差，明显卡顿

注意：

• 高端机应该达到60fps
• 中低端机可以适当放宽，但最好不低于50fps
• 静态页面（不动的时候）应该稳定60fps
• 列表滚动、动画等场景允许偶尔掉帧，但不能太频繁

Q7：优化到什么程度可以停？

性能优化是无止境的，但不可能无限优化下去。

停止条件：

1. 达到性能目标：

   • 比如FPS稳定55以上
   • 启动时间控制在2秒以内
   • 内存占用控制在XX MB以内

2. 收益递减：

   • 再优化下去，投入很多，收益很小
   • 这时候就可以停了

3. 没有明显瓶颈：

   • Profiler看下来，各部分都很合理
   • 找不到明显可以优化的点

记住：性能优化是为了用户体验，不是为了追求数字。用户感觉流畅，就够了。

---

📝 小结

本文全面介绍了DevEco Profiler的使用方法和性能调优的完整流程。让我们总结一下：

核心知识点

1. Profiler的作用：把看不见的性能问题可视化，让优化有数据支撑
2. CPU分析：找热点函数、分析调用栈、定位CPU瓶颈
3. 内存分析：堆快照、对象分配、内存泄漏检测
4. 网络分析：请求耗时、瀑布图、流量统计
5. 帧率分析：FPS监测、Jank分析、掉帧定位
6. 启动分析：启动时间线、各阶段耗时
7. 功耗分析：电量消耗、唤醒次数、各模块耗电
8. 调优流程：发现问题→复现场景→定位瓶颈→优化实施→验证效果

常见性能陷阱

• 过早优化：还没测量就开始优化
• 过度优化：花太多时间在小收益上
• 顾此失彼：优化了A，恶化了B
• 只测高端机：忽略了中低端用户

「民族图鉴」实战案例

通过列表卡顿的实战案例，我们演示了：

1. 用帧率分析确认问题
2. 用CPU分析定位瓶颈
3. 结合代码分析根因
4. 逐步优化验证效果

性能分析的正确姿势

1. 用数据说话：不要靠感觉，要靠测量
2. 控制变量：一次只改一个地方
3. 对比验证：优化前后对比
4. 持续关注：建立性能基线，防止退化

DevEco Profiler是一个强大的工具，但工具只是工具，关键还是使用工具的人。希望本文能帮你掌握这个工具，让「民族图鉴」的性能越来越好。

下一篇，我们将对整个性能优化篇做一个总结，回顾性能优化的知识体系，建立性能优化的方法论，并给出「民族图鉴」的性能优化Checklist。