TG咨询线上卡顿往往不是单一原因：列表滚动可能被主线程计算拖慢，页面打开也可能在等待网络或磁盘读写。监控Android应用运行时资源监控指标，重点不是收集越多数据越好，而是让卡顿能够关联到具体版本、设备、页面和操作。
先明确三个问题：用户在哪个动作遇到问题？问题集中在哪些设备或系统版本？同一时间段内，帧时间、CPU、内存和请求耗时是否一起异常？带着这些问题采集，数据才有排查价值。
先监控能解释卡顿的指标
帧时间与卡顿比例
帧时间表示一帧从开始处理到完成所需的时间。60Hz屏幕的单帧预算约为16.7毫秒，120Hz屏幕约为8.3毫秒；这是刷新节奏对应的参考值，不代表所有设备和场景都应套用同一告警线。记录页面帧时间分布、慢帧比例及页面切换时的长帧，比只看平均值更容易发现尖峰。
CPU、PSS内存与ANR
CPU占用可帮助识别密集计算、频繁布局或后台任务竞争，但要同时记录采样窗口和设备核心数，不能简单比较不同机型上的百分比。内存可观察进程的PSS内存及其变化趋势；PSS会按共享内存比例分摊，适合观察进程总体占用，不能直接当作应用独占的物理内存。另需统计崩溃和ANR发生率，并关联系统版本、应用版本和页面。
网络与页面耗时
把请求总耗时拆成连接、服务端响应和数据传输等阶段，并记录失败率与超时情况。若页面卡住时帧时间正常、请求耗时升高，排查方向更可能在网络或服务端；若请求正常但慢帧明显，则优先检查主线程工作、布局和绘制。
线上采集：从动作到可比较的数据
- 给关键操作命名。例如冷启动、打开详情、提交表单、滚动长列表。用一致的页面与操作标识串起一次体验，避免把不同流程混在一个指标里。
- 按版本和设备分组。至少保留应用版本、Android系统版本、设备型号、页面及时间段等维度。采集前确认不上传账号、输入内容等不必要的个人信息。
- 选择采集工具。线上性能监控可用Firebase Performance Monitoring观察应用启动和网络请求；Google Play Console中的Android vitals可辅助查看崩溃与ANR趋势。需要深入分析时，再用Perfetto跟踪线程、调度和系统事件；它更适合复现或针对性采样，不是替代线上汇总指标的仪表盘。
- 设置基线与告警。先按设备档位、页面和版本比较稳定时段的分布，再关注慢帧比例、ANR、内存增长或请求耗时是否持续偏离自身基线。不要把单台设备的一次尖峰直接视为全量故障。
- 复核问题时间点。从告警对应的版本和操作入手，对照帧时间、CPU、PSS内存与网络耗时；若线上数据只能定位到页面，再用Perfetto或本地性能分析复现细节。
怎样判断先查哪里
| 现象 | 优先检查 | 判断要点 |
|---|---|---|
| 慢帧升高，CPU也持续偏高 | 主线程计算、布局和绘制 | 按页面及操作比较，确认异常是否集中在特定版本 |
| 卡顿伴随PSS持续增长 | 对象生命周期、图片与缓存 | 观察重复进入退出页面后的趋势，区分短时峰值与持续增长 |
| 页面等待明显，帧时间没有同步恶化 | 网络请求及服务端响应 | 按请求阶段拆分耗时，检查超时和失败是否同时增加 |
| 出现ANR或崩溃 | 对应系统日志、线程状态与堆栈 | 按系统版本和设备分组，确认是否存在集中发生的条件 |
在线监控负责发现范围与时间，跟踪工具负责解释线程和系统层面的原因。将Android应用运行时资源监控指标与版本、设备和用户操作关联，通常比单独盯一个CPU或内存数值更有效。
常见问题
只看平均帧率够吗？
不够。平均值可能掩盖少量严重卡顿，应同时观察帧时间分布、慢帧比例和具体页面。
内存超过某个数就一定是问题吗？
不一定。设备内存、系统版本和页面内容都会影响数值，应关注同类设备上的变化趋势、持续增长及是否伴随崩溃。
线上需要一直采集完整系统跟踪吗？
通常不需要。先用低开销汇总指标定位范围，再对可复现问题或特定人群做有控制的深入采样，并评估耗电、性能和隐私影响。
卡顿告警该设统一阈值吗？
可用帧预算等技术标准作参考，但不同刷新率、机型和页面差异明显。先建立分组基线，再结合持续时间和影响范围设告警，更不容易误报。
排查线上卡顿时，先用Android应用运行时资源监控指标锁定异常页面、版本和设备，再依据帧时间、CPU、内存、ANR或网络耗时选择验证手段，才能把发现问题与定位原因连接起来。