“App 很卡”不是一个足够具体的性能问题。它可能是冷启动白屏、列表滑动掉帧、点击后无响应、内存不断上涨也可能是网络慢或设备发热。不同症状需要不同工具用内存快照找不到主线程某一帧为什么超时用一次本地 Trace 也不能代表线上所有机型的体验。这篇文章不把工具当成清单背而是回答三个实际问题什么时候用、能看到什么、拿到结果后下一步做什么。Android Studio 的菜单和可用功能会随版本、系统和设备变化下面以工具能力和判断方法为主。一、先用一张表选工具现象 / 目标第一选择进一步定位最值得看的证据用户反馈启动慢Android Vitals、MacrobenchmarkPerfetto / System Trace、Baseline Profile 检查冷启动与热启动分布、主线程启动阶段耗时页面滑动掉帧、动画不顺MacrobenchmarkFrameTimingMetric、JankStatsPerfetto、Layout Inspector慢帧发生在哪个页面和哪段主线程/渲染工作点击后卡住或 ANRAndroid Vitals 的 ANR 聚合与 tracesPerfetto、StrictMode、线程栈主线程在执行、等待锁、Binder 还是 I/O内存持续上涨、返回页面后不降Memory Profiler、LeakCanaryHeap Dump、引用链分析不应存活的 Activity/View 被谁持有频繁 GC、滚动时顿一下Memory Profiler 的分配记录Perfetto、热点代码检查单位时间的对象分配量与 GC 是否撞上慢帧接口慢或流量异常Network Inspector、服务端监控OkHttp 事件/自定义埋点、Firebase PerformanceDNS、连接、请求、服务端处理、响应体各耗时电量掉得快、后台发热Android Vitals、Power Profiler/Perfettobatterystats、唤醒与任务调度记录CPU、网络、定位、WakeLock、后台任务是否持续活动某个算法或序列化函数慢MicrobenchmarkCPU Profiler单个热点函数的稳定耗时、分配量安装包太大、下载慢APK Analyzer / App Bundle 分析R8、资源和依赖分析哪些 dex、资源、native 库占空间这张表里的工具分为两类线上观察告诉你“哪些用户、哪些设备、哪些场景有问题”本地诊断与基准测试帮你复现并解释“为什么”。只看其中一边容易优化错方向。二、线上先看 Android Vitals问题有多普遍Google Play Console 的 Android Vitals 汇总真实用户设备上的稳定性和性能信号例如 ANR、崩溃、启动与渲染等指标。它适合回答问题是否集中在某个版本、机型、系统版本或国家地区修复上线后整体体验有没有变化使用场景发版后 ANR 率上升先按版本和设备切片再找代表性的 traces。用户说“某些手机启动很慢”先判断是否只在低端设备或特定系统版本出现。本地测试已改善但要确认线上指标是否真的变好。它的局限是聚合指标通常不能直接指出某一行代码。线上看见异常后仍要用相近设备和数据量复现再交给 Trace、Profiler 或基准测试定位。应用未通过 Google Play 分发时也不能假设 Play Console 会覆盖全部用户需要自己的遥测方案。Firebase Performance Monitoring 可补充启动、网络请求和自定义代码段的线上耗时分布适合跟踪业务路径它同样是“发现与验证趋势”的工具不替代逐帧 Trace。埋点时要注意采样、隐私和指标定义一致性。三、Android Studio ProfilerCPU、内存、网络各查什么1. CPU Profiler找热点不把采样结果当绝对真相适合发现主线程上长时间运行的解析、图片处理、加解密、列表计算以及后台线程的 CPU 争用。采样方式开销通常较低适合先找“时间花在哪里”更细的插桩式记录会改变运行时开销不能直接拿它的耗时当线上性能。看到某个函数占比高后先确认它是不是在用户可感知路径上。后台预计算消耗 CPU不一定造成掉帧主线程上一个仅执行十几毫秒的函数反而可能正好让关键帧超时。需要跨线程、跨系统服务观察时转用 Perfetto。2. Memory Profiler区分泄漏、抖动和高峰占用内存曲线往上走并不自动等于泄漏。先按问题类型选观察方法问题观察方式判断重点泄漏反复进入/退出页面触发 GC查看 Heap Dump已销毁对象是否仍可达引用链是谁抖动Allocation Recording 与 GC 时间线滑动、绘制或点击期间是否大量短命对象峰值过高内存类别、Heap Dump、图片缓存检查Bitmap、数组、native 内存是否超预算LeakCanary 特别适合开发和测试阶段自动发现 Activity、Fragment、ViewModel 等对象的泄漏并给出保留引用链。它告诉你“谁还持有对象”但不保证每个内存高峰都是泄漏。Heap Dump 和分配跟踪会带来开销采集时尽量减少调试器等干扰。3. Network Inspector区分“网络慢”和“界面处理慢”Network Inspector 可观察受支持网络栈的请求、响应和时间线适合查重复请求、异常大的响应体、串行接口依赖以及页面明明已退出却还在请求。它不保证覆盖所有自定义网络实现若要细分 DNS、连接、TLS、服务端处理和反序列化可结合网络库事件回调、服务端日志或自定义埋点。一条接口耗时 800 ms并不等于主线程被阻塞 800 ms也可能网络是异步的而真正卡顿出现在响应到达后的 JSON 解析和 UI 更新。要把网络时间线和主线程 Trace 对齐。四、Perfetto / System Trace定位“这一帧到底卡在哪”Perfetto 是 Android 性能排查里最值得掌握的时间线工具之一。Android Studio 的 System Trace 也基于系统级追踪能力。它可以把主线程、RenderThread、线程调度、CPU、Binder、I/O 和帧相关事件放在同一条时间轴上。适用场景列表偶发掉帧看慢帧前后主线程是否被measure/layout/draw、图片解码、GC 或锁等待占用。点击无响应看输入事件到达后主线程在运行还是被别的线程/系统调用阻塞。启动慢把 Application 初始化、首屏 Activity、首帧绘制与后台并发任务放在同一时间线上看。不要一打开 Trace 就盯着“最红的条”。先圈定用户感知的时间段再问**主线程该运行时在做什么它有没有被调度上 CPU它在等谁**如果需要让业务阶段更容易辨认可用Trace.beginSection()/Trace.endSection()对短小的同步代码段做标记并确保成对调用Trace.beginSection(feed_bind)try{bindFeedItems(items)}finally{Trace.endSection()}不要把一个可能跨线程恢复的挂起函数整体包成同一个同步 Trace 区间应分别标记各段实际执行的代码。采集本身有开销比较版本时保持配置一致。五、Macrobenchmark 与 Microbenchmark一个测体验一个测函数Macrobenchmark验证启动和滚动等用户路径Macrobenchmark在应用进程之外驱动被测 App常用于重复测量启动、滑动或导航场景。它能报告StartupTimingMetric、FrameTimingMetric等指标适合回答“这个改动让真实操作路径更快了吗”例如冷启动优化固定设备、构建类型和数据状态多次测冷启动看中位数与尾部耗时别只拿一次adb shell am start -W的结果宣布成功。冷启动、温启动、热启动必须分开比较。启动体验还可区分初始显示时间TTID与内容真正可用的时间TTFD若业务要报告完整绘制应在合适时机调用reportFullyDrawn()。滑动优化用固定数据集和自动化操作测帧时间再用 Perfetto 对慢帧定位。Benchmark 告诉你“是否改善”Trace 告诉你“为什么”。基准测试建议使用接近发布配置的可分析构建避免把 Debug 构建和调试器开销当成用户体验。Microbenchmark只测可隔离的热点代码Microbenchmark适合 JSON 解析器、排序、格式化、数据转换等可重复调用的小范围代码能控制预热并减少手写System.currentTimeMillis()的测量误差。它不适合单独证明“页面变流畅了”函数快了 30%但这个函数只占一帧的 1%用户可能毫无感知。最佳组合是先用 Profile/Trace 找到热点再用 Microbenchmark 比较实现最后回到 Macrobenchmark 验证整条用户路径。Baseline Profile 不是诊断器Baseline Profile 用来帮助 Android Runtime 提前优化重要代码路径常用于改善启动和关键交互。它是优化手段不是查慢点的工具。生成或调整后仍应在相同条件下用 Macrobenchmark 验证收益并留意首次安装、编译状态与版本差异。六、StrictMode、JankStats 和 Layout Inspector抓特定问题StrictMode开发阶段发现主线程磁盘读写、网络访问等不合适的操作以及部分资源使用问题。适合“怀疑某处无意间阻塞 UI”的早期预警并非所有 ANR 都能靠它发现也不宜直接把严厉策略原样放到生产环境。JankStats在 App 内按界面和状态记录卡顿帧适合知道“哪个页面、什么状态下更容易卡”定位具体线程调用链还得看 Trace。Layout Inspector看 View/Compose 的层级、属性和布局状态适合排查过深层级、重复布局、屏幕外仍存在的视图等结构问题。层级复杂不自动等于卡顿需与帧时间对应。命令行也有快速体检工具adb shell dumpsys meminfo com.example.app可粗看进程内存adb shell dumpsys gfxinfo com.example.app framestats可辅助观察渲染帧统计。它们适合初筛和脚本化观察但输出会因 Android 版本、设备和窗口状态变化要解释单帧原因仍需 Trace。把示例包名替换成自己的应用 ID。七、耗电与包体积不要用 CPU 一项概括全部耗电排查先明确场景前台滑动发热、后台待机耗电、定位场景耗电分别对应不同证据。Android Vitals 或应用遥测先找受影响设备与场景本地再用 Power Profiler、Perfetto 和batterystats观察 CPU 活跃时间、网络请求、WakeLock、定位与后台任务。功耗测量受屏幕亮度、网络质量、温度和设备影响很大尽量做同设备、同环境的前后对比。不要因为 CPU 曲线下降就直接宣称电池续航改善。包体积则主要用 APK Analyzer / App Bundle 分析看 dex、资源、ABI 库和第三方依赖的贡献。删除冗余资源、按需交付和正确配置 R8 可能改善下载、安装与磁盘占用但包变小不等于运行时一定更快。这是不同指标分别验证。八、三个实际排查流程场景 A首屏白屏时间变长Android Vitals 确认受影响版本/设备 → Macrobenchmark 固定冷启动场景建立基线 → Perfetto 看 Application/Activity/首帧路径 → 识别主线程 I/O、锁等待、过早初始化或资源加载 → 延后非首屏必需工作必要时评估 Baseline Profile → 再跑同一套 Benchmark并观察线上分布不要把“把初始化丢到后台”当通用修复若首屏马上要等待其结果只是把阻塞位置换了。场景 B列表滑动偶发卡顿先用 JankStats 或用户反馈确定页面与操作再用 Macrobenchmark 重复滑动以稳定复现。Perfetto 找慢帧如果主线程在绑定数据时解码图片就转移或缓存图片处理如果频繁 GC就用 Memory Profiler 看分配如果布局阶段异常长再用 Layout Inspector 检查结构。最后比较帧时间分布而不是只凭肉眼感觉。场景 C打开关闭页面多次后内存上涨用 Memory Profiler 观察 GC 后趋势再用 LeakCanary 或 Heap Dump 找已退出页面的引用链。若没有明显保留对象却在滑动期间频繁 GC应改查内存抖动若 Bitmap/native 内存峰值过高应检查资源尺寸和缓存策略。三类问题的修法不同不要一律“加大堆内存”。九、让优化结论可信的五条规则先定义指标与场景。“快一点”要落成冷启动 TTID/TTFD、慢帧比例、P95 接口耗时或内存峰值等可复测指标。**保持条件一致。**同机型、系统、构建类型、数据规模、网络和温度区分冷/热状态不混用 Debug 与 Release 结果。**多次测关注分布。**看中位数与尾部而不是挑一次最好成绩必要时在多档设备上验证。**把相关性变成因果证据。**Profiler 看到分配上升不等于它造成掉帧要让分配、GC 与慢帧时间线对齐。**修复后回到原场景。**局部函数更快、APK 更小或 Trace 更短都不代表用户路径一定改善最终回到 Benchmark 和线上指标。性能优化不是把所有工具都打开而是建立一条短链用户症状 → 线上分布 → 本地复现 → 时间线/内存/网络证据 → 定向修复 → 相同条件回归。这样才能知道改动解决了什么也知道还没解决什么。参考资料与延伸阅读Android DevelopersProfilerAndroid DevelopersAndroid VitalsPerfetto 官方文档Android DevelopersMacrobenchmarkAndroid DevelopersMicrobenchmarkAndroid DevelopersBaseline ProfilesAndroid DevelopersJankStatsAndroid DevelopersStrictModeFirebase Performance MonitoringLeakCanary 文档本项目Android Studio 调试与内存抖动分析指南