2. Profiler CPU 面板数据采集：采样模式选择、时间范围设定、录制流程
在定位卡顿之前，首先需要采集到高质量的CPU跟踪数据。错误的采集模式或时间范围可能导致关键卡顿信息丢失，从而无法进行后续的原因定位。本章将聚焦于如何正确配置CPU Profiler进行数据采集。
2.1 现象识别：何时需要采集CPU数据？
当用户或测试人员反馈以下现象时，应立即启动CPU Profiler数据采集流程：
- UI 掉帧：页面滑动、动画播放出现明显的卡顿或跳帧。
- 操作无响应：点击按钮后，界面长时间无变化，或出现ANR（Application Not Responding）对话框。
- 启动/页面切换缓慢：应用冷启动耗时过长，或页面间跳转需要数秒才能完成。
- 耗电量异常：设备发热明显，电池消耗速度加快，间接反映CPU占用过高。
判断规则： 如果界面出现肉眼可见的停顿，则应当优先采集CPU跟踪数据。如果仅存在轻微卡顿，建议先使用帧渲染分析功能结合CPU数据综合判断。
2.2 数据采集：采样模式选择
Android Studio Profiler 提供两种CPU数据采集模式：Sampled（采样） 和 Instrumented（插桩）。选择哪种模式取决于排查目标。
| 特性 | Sampled（采样） | Instrumented（插桩） |
|---|---|---|
| 原理 | 以固定时间间隔（如1ms）记录当前执行的方法栈。 | 在每个方法入口和出口处注入跟踪代码。 |
| 性能开销 | 低（对应用运行影响极小） | 高（可能显著改变应用行为，导致卡顿加剧） |
| 数据完整性 | 可能漏采持续时间短的方法（如<10ms的调用）。 | 100%捕获所有方法调用。 |
| 最佳场景 | 排查长时间卡顿、ANR、帧率下降。 | 排查高频小方法调用、冷启动中的精确耗时。 |
| 推荐值 | 默认（应用发布版、日常调试） | 仅在调试版本且需要精确统计时使用。 |
避坑提示： 在排查线上用户遇到的卡顿问题时，应始终使用Sampled（采样）模式。Instrumented模式的高开销可能使你无法复现用户的卡顿场景，甚至导致应用直接崩溃。
2.3 数据采集：时间范围设定与录制流程
正确的录制流程是获取有效数据的关键。错误的起止时间点可能导致采集到大量无用数据，而丢失关键的卡顿段。
2.3.1 录制流程
- 启动Profiler：点击Android Studio底部的“Profiler”选项卡，或通过
View > Tool Windows > Profiler打开。 - 附加进程：在Profiler窗口中，选择需要调试的设备和应用进程。
- 选择CPU面板：点击顶部的“CPU”时间线图，进入CPU监控视图。
- 配置录制参数：
- 在录制配置下拉菜单中选择“Sampled（采样）”或“Instrumented（插桩）”。
- 时间范围设定： 建议采用“手动录制”模式。在卡顿即将发生前（例如，即将进行复杂操作前）点击“Record”开始录制，卡顿结束后立即点击“Stop”结束录制。这样可以有效缩小数据范围，避免无关数据干扰。
- 执行复现操作：在录制期间，在设备上精确复现导致卡顿的用户操作路径。
- 分析跟踪文件：停止录制后，跟踪文件（.trace）会自动加载到分析器中，即可进行下一步的原因定位。
2.3.2 时间范围设定规则
| 场景 | 录制时机 | 时长建议 |
|---|---|---|
| 页面首次启动卡顿 | 点击启动图标前开始录制 | 直至首页完全加载完成 |
| 列表滑动卡顿 | 手指即将滑动屏幕前开始录制 | 持续滑动3-5秒，包含卡顿段 |
| 点击操作无响应 | 点击按钮前开始录制 | 等待操作完成或ANR弹窗出现后立即停止 |
| 后台任务累积卡顿 | 正常使用应用2分钟后开始录制 | 持续录制30-60秒，涵盖卡顿现象 |
2.4 录制配置故障排查表
如果在录制过程中遇到问题，可以对照下表快速排查：
| 现象 | 可能原因 | 修复动作 |
|---|---|---|
| 无法点击“Record”按钮 | 设备未连接或Profiler未正确附加进程 | 断开并重新连接设备，或重启Android Studio的Profiler工具窗口 |
| 录制完成后文件为空 | 录制时间过短（小于1秒）或应用未运行任何代码 | 确保在录制期间执行了有意义的操作，录制时长至少2-3秒 |
| 应用在录制时崩溃 | Instrumented模式开销过大，或跟踪缓冲区溢出 | 切换为Sampled模式；如果仍需Instrumented，在AndroidManifest中增加跟踪缓冲区大小 |
| 数据中几乎没有方法帧 | 选择了错误的进程，或采样间隔过大 | 确认Profiler中选择了正确的应用进程；Sampled模式的采样间隔默认且合理，通常无需修改 |
2.5 数据采集流程概览图
下图展示了从启动Profiler到完成录制输出的标准化决策与操作流程。通过该图可以直观理解“采样模式选择”、“时间范围设定”与“录制执行”之间的串联关系。
2.6 采样模式选择故障树
在无法确定使用哪种采样模式时，可以用以下简单的故障树快速决策：
故障树决策逻辑：
问题：需要采集CPU数据
│
├─ 是否正在排查线上问题或高负载场景？
│ ├─ 是 → 使用 Sampled（采样）模式
│ └─ 否 → 继续判断
│
├─ 是否怀疑是持续时间非常短（<10ms）的方法调用导致？
│ ├─ 是 → 使用 Instrumented（插桩）模式（仅在debug版本）
│ └─ 否 → 使用 Sampled（采样）模式
│
└─ 最终建议：98%的日常卡顿排查场景使用Sampled模式。
2.7 预防：建立标准采集规范
为防止后续排查时因数据采集不当而浪费大量时间，建议团队建立如下预防性规范：
- 录制前检查清单：每次录制前，强制确认选择了正确的进程、正确的录制模式（Sampled）、且手机电量充足。
- 命名规范：录制的跟踪文件应按照「问题名_日期_次数」的格式命名，例如
list_scroll_lag_20251020_v1.trace。 - 录制时长上限：除非必要，单次录制不超过30秒，避免文件过大导致分析器卡顿。
- 数据复现要求：确保“先录制，后复现”。先开始录制，再执行卡顿操作，以确保捕捉到完整的卡顿起始段。
最佳实践： 养成在每次卡顿修复前和修复后，都使用完全相同的参数录制一份 .trace 文件的习惯。这将在后续的“复测”阶段提供最直接的对比依据。