企业官网建设流程全解析

1. 性能优化入门：Android Studio Profiler 的定位与使用价值

做 Android 开发，但凡产品到了用户手里出现卡顿、发热、掉电快这些问题，后台反馈过来的第一句话基本都是：“你们这个 App 是不是有问题？” 这时候你空口解释没有用，掏出 Profiler 把数据一摆，哪个线程卡了、哪个方法吃了几十毫秒、哪块内存一直涨，一目了然。

Android Studio Profiler 是 Android Studio 自带的性能分析工具，从 3.0 版本开始替代了老的 Android Monitor，它在 CPU、内存、网络、能耗四个方面提供了实时的数据采集和分析能力。用大白话说，它就是一台汽车仪表盘，能看转速、看水温、看油耗、看电压，有了这些数据你才知道车是哪出的毛病。我这些年做应用优化，不管是线上反馈的卡顿、OOM、流量异常还是耗电问题，基本都是先开 Profiler 拉数据，再根据数据去定位代码，十次里面有七八次都能直接找到根因。

这篇文章不打算写成官方文档的翻译，我会按照自己的使用习惯，从思路到实操，再到常见问题的排查，把 Profiler 怎么用、什么时候用什么探针、数据怎么看、坑在哪里这些内容整个过一遍。无论你是刚接触系列工具的新手，还是已经用了一段时间但总觉得“不太顺手”的开发者，这篇文章都值得你花十几分钟读完。开 Profiler 不难，难的是拿到数据以后知道下一步该干什么，这也是我今天想重点讲的。

2. 核心设计思路：四大探针分别解决什么问题

2.1 为什么用 Profiler 而不是自己写日志打点

很多人定位性能问题习惯用 log，比如在方法入口出口各打一行，然后看时间差。这种做法不是不行，但有三个明显缺陷：第一，你只能分析你打了点的路径，没打点的代码出问题完全看不见；第二，日志本身会干扰性能，尤其是主线程打日志，反而会掩盖真实的问题；第三，很多底层问题发生在系统框架层、渲染管线里，应用层日志根本看不到。

Profiler 的思路完全不同，它是在系统层面采集数据。比如 CPU Profiler 用的是 ART 虚拟机提供的采样能力，能拿到所有线程的调用栈，不需要你改代码；Memory Profiler 能直接向虚拟机发起堆转储请求，把 Java 堆里的对象分布全部导出来。这种“旁观者视角”让分析结果更接近真实运行状态，也不会因为埋点改变行为习惯。

我们团队定了一个不成文的规矩：凡是用户反馈卡顿、闪退、耗电，一律不允许“猜”，必须用 Profiler 先拉现场数据再讨论。为什么定这个规矩？因为性能问题的表象和根因往往隔着一层。举个例子，用户说“列表滑动卡”，你以为真是列表的问题，结果一抓 CPU 才发现是后台线程在做 Bitmap 压缩抢占了 CPU 时间片，列表本身反而是受害者。这种跨模块的因果关系，不打点根本发现不了。

2.2 四大探针的适用场景对照

Profiler 的界面看起来复杂，其实核心就是四个独立的数据采集器，我在下面把它们的定位理一下：

这个表格看着简单，但每个探针背后都有自己的使用技巧和限制条件。比如 CPU 探针里“System Trace”和“Java Method Trace”采集的内容完全不同，前者侧重系统调用与渲染线程，后者侧重应用自身的方法执行，选错录制模式会让整个分析失去方向。后面我会专门用一节讲各种模式怎么选。

2.3 性能分析的基本流程：先复现、再采集、后定位

我自己的分析流程基本固定成三步：复现路径、数据采集、下钻定位。

第一步复现路径非常关键。你不能让用户说“卡了一下”就完了，要知道是什么操作卡的。可以看后台的崩溃日志、操作日志，或者直接问用户“点哪个页面的时候卡的”。拿到固定路径后，在开发机上把操作走一遍，如果必须用线上包，那就得看是不是可以在 Debug 包上复现。很多性能问题只在特定机型上出现，所以我一般会准备几台不同档位的测试机，低端机最容易暴露性能瓶颈。

第二步数据采集。操作路径复现得差不多，就开 Profiler 开始录制。这里有个经验：录制时间宁可长一点也不要短了。比如你要分析启动流程，那就从点击图标一直录到首页完全展示稳定；要分析滑动流畅度，那至少录 30 秒以上的连续滑动。录制窗口太短，数据往往抓不到关键帧，回头还得重来。

第三步下钻定位。拿到数据以后，先在概览面板看整体趋势，再切换到对应探针仔细看。比如 CPU 数据，先看是不是主线程长时间处于 Runnable 状态，再看是哪些方法占用了时间；内存数据先看 Heap 是不是只涨不跌，是不是有明显的“锯齿”结构。定位到可疑代码后，直接点击跳转到源码，再分析具体原因，整个过程不需要反复去猜。

3. CPU 探针实操：抓线程卡顿与方法耗时

3.1 两种录制方式的选择与开销分析

CPU Profiler 刚打开时是一个实时图表，显示所有核心的 CPU 使用情况。要拿到方法级数据，得点左上角的“Record”开始录制。录制模式一共有四种，但最常用的就两种：Java/Kotlin Method Sample（采样）和 Java/Kotlin Method Trace（插桩）。

采样方式的工作原理是，虚拟机会周期性唤起来记录当前调用栈，默认间隔是 1 毫秒左右。这种方式对应用性能影响极小，后台线程的方法调用也能被记录。但缺点是短耗时的方法可能被漏掉，比如某个方法执行只要 0.2 毫秒，采样间隔是 1 毫秒，那这个方法就很有可能在这次录制中“消失”。

插桩方式则是修改应用的字节码，在方法进入和退出时插入记录指令。这样能拿到每个方法的真实执行时间和调用次数，精确度比采样高出几个量级。但相应的，插桩会带来明显的性能损耗，特别是高频调用的方法，插桩开销可能让运行时间增加好几倍。所以这个方法适合分析调用次数少、单次耗时长的方法，比如点击事件处理、页面切换这类场景。

我的选择逻辑很简单：排查启动慢、点击无响应这类“宏观”问题，用采样模式；确认某个具体流程里哪个函数拖了后腿，用插桩模式。记住一点，采集方式和分析目标必须匹配，不然数据会给你错误的指引。

3.2 火焰图、Top Down 与 Bottom Up 怎么读

录制结束后，CPU Profiler 会提供三种分析视图：Flame Chart（火焰图）、Top Down（自顶向下）和 Bottom Up（自底向上）。第一次接触这些视图的人容易懵，我用人话来解释一下。

火焰图是水平展示的调用关系，横轴是执行时间，纵轴是调用深度。一个方法的柱子越长，说明它及其子调用占用的时间越多。看火焰图有一个口诀：找“平顶山”和“粗柱子”。如果一个方法顶上顶着一条又宽又平的横线，基本可以判定这个方法在循环里做了不少事；如果你发现某个自己写的方法柱子的宽度出乎意料，点进去看实现，十有八九能找出性能问题。

Top Down 视图是从入口方法开始往下展开的树，每一层显示当前方法对子方法的调用耗时。这个视图适合回答“这个方法为什么慢”，因为它能明确显示时间都消耗在了哪些子调用上。Bottom Up 视图反过来，从叶子方法开始往上聚合，把相同方法在不同调用路径里的耗时合并起来。这个视图适合回答“这个慢方法都被谁调用了”，非常适用于分析系统方法被反复调用的问题。

我读这三个视图的经验是，先看火焰图找嫌疑区域，再用 Top Down 深入路径，最后用 Bottom Up 查类似方法的其他调用位置。三步走完，问题代码基本就锁定了。

3.3 主线程卡顿的实际排查案例

我拿一个真实的例子来说流程。有个项目用户反馈说在聊天列表页面长按消息会出现 1 到 2 秒的卡顿，Developer 那边看了半天代码也没发现问题。我打开 Profiler，先用采样模式录制了 15 秒，重复了几次长按消息的操作。

数据分析时，我注意到主线程的调用栈里出现了一个很奇怪的方法路径：某个下拉框的初始化被反复调用。点进去看，发现长按手势触发了 PopupWindow 的创建，而创建逻辑里嵌套了一个遍历消息列表的循环，循环里还会对每条消息做表情解析和图片尺寸计算。

当时我就判断，问题不在列表本身，而在这个长按触发的额外开销上。后来用插桩模式单独录制了一次长按操作，数据证实了这个方法的耗时超过了 800 毫秒，这在主线程上是不可接受的。最后把表情解析改成了懒加载，把图片尺寸计算移到了子线程，卡顿瞬间消失。如果不是 Profiler 明确指出是长按路径的问题，单靠阅读代码，这种跨模块的调用开销很难被发现。

3.4 CPU 探针的使用禁忌与注意点

使用 CPU 探针时有几个坑我得单独提醒。不要在发布包上直接录制插桩模式的数据，因为插桩本身会大幅拖慢执行速度，导致采集到的数据和用户真实体验差距很大。如果想分析线上问题，优先用采样模式，或者用代码里显式调用 Debug.startMethodTracing() 这种方式，然后选择性地开启和关闭记录。

另外，录制时间不要拉太长。采样模式录制 10 分钟会生成很大的文件，分析的时候 UI 会明显变卡。一般情况 30 秒到 1 分钟的数据量已经足够分析大部分问题。如果确实需要长时间分析，我一般会采用分段录制的方式，每段只关注一个操作场景，这样数据噪音更少，结果也更好解释。

4. Memory 探针实操：从分配追踪到内存泄漏排查

4.1 实时堆内存图表的读法

Memory Profiler 打开后最上面是一个实时变化的图表，显示当前应用占用的内存大小。图表里有几个关键颜色，蓝色通常代表 Java 对象，绿色代表图片资源，红色代表代码分配但尚未释放的临时对象，以前建议关注的颜色区分还会根据 Android 版本变化。

我读这张图只有一个核心关注点：看内存是否呈现出“锯齿状”。锯齿状是指内存快速上升又快速下降，反复循环，这说明应用内存在大量临时对象，它们的分配和释放非常频繁。

出现这种锯齿并不是坏消息，因为最终内存还是释放了，但它提示你存在不必要的对象分配。如果锯齿的波谷位置一次比一次高，最后甚至平台期不再下降，那就要高度警惕了，这是内存泄漏的典型信号。比如从一个页面返回上一个页面，正常情况内存应回到进入前的水平；如果回不去，说明离开页面时有些对象没有被正确回收。

4.2 抓取 Java Heap 堆转储与对象分析

点击“Dump Java heap”按钮，Profiler 会强制触发一次堆转储，然后展示所有存活对象的列表。这个操作会暂停应用几秒钟，对体验有影响，适合在开发和测试阶段用，不适合线上直接执行。

堆转储后进入对象分析页面，重点看两个指标：Shallow Size 和 Retained Size。Shallow Size 是对象本身占用的内存，不算它引用的其他对象；Retained Size 是对象自身加上它持有的所有引用可达对象的合计大小，这才是真正能释放的内存数量。分析时按 Retained Size 从大到小排序，大对象排在前面，优先处理它们。

如果发现某个自定义 View 的 Retained Size 特别大，但它明明已经不在页面上了，那基本可以断定这个 View 被某个静态变量或者单例持有，导致无法回收。顺着引用链一层层展开，就能找到持有它的根。

我在实践里还会特别关注 Bitmap 对象。Android 应用内存里有大量 Bitmap 是很常见的事，但它们的相关对象必须被回收。如果 Bitmap 一直占据着几十兆内存且无法释掉，十有八九是图片缓存库的配置有问题，或者某些页面持有图片引用没有清理。

4.3 Record Allocations 与泄漏的关联分析

除了堆转储，Memory Profiler 还支持录制 Java/Kotlin 对象分配。点“Record Java/Kotlin allocations”开始录制后，所有新分配的对象都会被记录，录制结束后你能看到对象列表、分配数量，甚至还能点开看是哪些方法分配出来的对象。

这些功能用起来感觉得心应手。比如查大列表卡顿问题时，我可以录制滑动的过程，结束后按“Allocation sizing”排序，看看哪些对象被创建了上万个，然后定位到代码，尝试复用对象或替换成更轻量的数据结构。

有一类典型问题非常适合用这个功能分析：频繁的字符串拼接和自动装箱。如果录制结果显示 Integer、String 这些对象在短时间内被大量创建，那代码里大概率存在循环内拼接或者频繁用 + 连接字符串的问题。把它们逐个改成 StringBuilder 或基本类型后，内存分配量会肉眼可见地下降。

需要强调的是，Record Allocations 和 Dump Java heap 是两回事。前者只能看录制时间段内“新分配”的对象，录不到录制开始前就存在的对象；后者看的是某一刻全部存活的对象。所以问题不同，选用的方法也不同：查临时对象分配用录制分配，查泄漏持有用堆转储。

4.4 内存分析时常见误判与修正

我踩过一次印象很深的坑：当时看到一个页面退出后内存没回落，怀疑是泄漏。但后来用 LeakCanary 监测了一段时间，又反复在 Android Studio 里 dump，结果怎么查都找不到明确的持有链。最后才反应过来，是系统一些缓存机制让部分 Bitmap 保留在内存高区，并不是应用自身的错误。

从那以后我给自己立了规矩：不要只看一次 dump 就下结论，至少做两组对比。第一组是同一个页面进入前和退出后各 dump 一次，看内存是否回到原来水平；第二组是连续多次进入退出页面，看内存峰值是否一直在涨。如果多次进入退出后，内存峰值相对稳定在一个水平，那即便有少量对象滞留，影响也不大；如果每次进入退出都让内存峰值往上抬一块，那就要拿这个数据去找代码了。

还有一个细节：堆转储和录制分配时，最好把系统进程的数据排除掉。Android Studio 默认能选择查看进程，但有时候会把系统的 GPU 内存之类的算进来，导致分析数据含混不清。手机端操作时尽量切到后台或保持同样的操作路径，减少噪声。

5. Network 与 Energy 探针：请求耗时和耗电问题的分析

5.1 Network Profiler 的请求时间线与 Body 体积拆解

很多时候遇到“加载慢”的问题，第一反应是服务端响应慢，但实际上可能是请求排队、数据包过大、解析时间长等多重因素。Network Profiler 的价值就在于可以按时间线看应用的网络请求：什么时候发起、多久拿到响应头、多久拿到响应体，每段耗时都有对应显示。

打开 Network Profiler 后，时间线上每一个圆点代表一个请求，点开之后能看到详细信息，包括请求头、响应头、响应体、数据大小和耗时时间。我拿到列表后的习惯是，先按传输总大小从大到小排序，看看哪几个请求消耗的流量最多；然后再看有没有请求的时间特别长，重点分析长尾请求。

曾经遇到一个问题：图片列表在弱网环境下加载非常慢。用 Network Profiler 查了一遍，发现有几张图片被重复请求了十几次，缓存根本没有生效。查代码后发现是图片加载库的缓存 key 拼接逻辑里漏了一个版本号参数，导致同样的图片在不同页面被当成不同的 URL 拉取。这个用日志很难抓，但 Profiler 的请求列表一眼就能看到同样的 URL 反复出现。

实际分析时还有一个隐藏功能，点击请求详情还能看到上下游数据的传输与解析。有的请求看起来耗时很大，但时间不是花在网络上，而是花在客户端对 JSON 的解析逻辑里。这种情况下响应体还没到，耗时就已经很多了，定位到代码里改成流式解析，效果立刻不一样。

5.2 网络层分析的限制与补充手段

Network Profiler 有个不友好的地方：它不是每个设备都能显示完整的请求体内容。部分 Android 版本对 HTTP 流量能直接捕获，但很多基于 OkHttp 的网络栈默认开启了透明压缩或 TLS 加密，导致 Profiler 无法展示明文请求体。在这种情况下列表只显示传输时间和大小，不显示报文内容，分析效果打了不少折扣。

我的替代方案是，需要看请求细节时，直接在代码里给 OkHttp 添加一个日志拦截器，把请求和响应的内容打出来。这样和 Profiler 的时间线配合使用，既能看整体请求结构，又能看具体报文内容，效率会高很多。

另外要提醒一句，Network Profiler 采集的是应用进程的网络活动，但并非能覆盖所有网络库。比如有些音视频 SDK 自己做了 UDP 传输，数据不会通过标准 API 走，那这个探针就看不到。遇到这类第三方 SDK 的请求分析，最好返回去查看 SDK 自己提供的日志和统计接口。

5.3 Energy Profiler 的能耗事件与唤醒锁排查

能耗分析是 Profiler 里大家用最少的一个探针，但它解决“发热”、“费电”这类问题时确实很管用。Energy Profiler 会按时间轴展示应用的能耗事件，睡眠状态、系统唤醒、网络活动、传感器使用等都有记录。

重点看两个指标：WakeLock 使用和网络活动。WakeLock 是 Android 里防止 CPU 休眠的机制，如果某个服务或播放器长期持有 WakeLock 不释放，CPU 就不会睡觉，电量和发热可想而知。在 Energy Profiler 里，如果发现时间线上有异常持有唤醒锁的区间，再配合 CPU 使用率，基本就能锁定罪魁祸首。

网络活动则要看后台是否频繁发请求。有些应用切到后台后会开启轮询，定时去拉取服务器数据，每次请求虽然不大，但累加起来，整个晚上耗电会非常明显。如果在 Energy Profiler 里看到夜间仍有规律性的网络事件，那就要检查后台任务的执行逻辑了。

Energy Profiler 在 Android 8.0 以上的 Pixel 设备和模拟器上数据最准，其他机型的数据有时并不完整。分析时我一般会把手机插上 USB 连着 Android Studio 跑，这样既能实时采集数据，又能保证电量变化不受充电干扰导致误读。

5.4 结合系统电量统计做交叉验证

Proc 探针只能覆盖应用进程自身，但是如果电量消耗其实来自其他原因，比如 CPU 频率被系统强制拉高，或者屏幕亮度过高，这部分就难以胜任。想获得更全的图景，建议切换出 Android Studio，到系统的“设置 - 电池 - 耗电排行”里看应用耗电占比，跟 Energy Profiler 的记录做交叉验证。

我做过一个低端机发热优化，当时 Profiler 里显示的能耗事件不多，应用自身 CPU 使用也正常，但用户还是反馈发热。结果一查系统耗电排行，发现占比高的其实是定位服务，是我们的地图 SDK 在后台频繁请求定位，而它没有被完全统计到应用进程的能耗数据里。后来修改了定位策略，改成应用在前台时才接收位置变更，问题得到了解决。

这类问题单靠 Profiler 一个工具是不够的，必须和环境数据配合起来看。我的建议是，遇到玄学级别的耗电问题，把 Profiler 的 Energy 数据和系统的电量管理页面同时打开，两边对比着分析，定位概率会高很多。

6. 常见问题与排查技巧实录

6.1 Profiler 无数据显示或数据缺失的排查

用 profiler 最尴尬的场景，莫过于连上手机点了半天的“Record”，结果数据面板一片空白。我碰到过几种情况，总结一下给你参考。

第一，设备没有正确启用开发者模式和应用调试权限，这种情况下 Profiler 无法附加到进程。解决办法是到“设置 - 系统 - 开发者选项”里确认 USB 调试和“仅充电模式下允许 ADB 调试”的选项都打开了。

第二，应用本身在 Release 包且关闭了可调试属性。Android 9 及以上版本，只有 debuggable 的应用才能被 Profiler 正常附加。如果是在线上包上做采样分析，要么用 Profileable 配置一个特殊属性，要么就用 adb shell am profile 配合模拟器手段来绕过限制。最省事的办法还是用 Debug 包测试。

第三，某些定制 ROM 对 Profiler 有兼容性问题。特别是国产手机的系统权限管理比较严格，可能拦截基于系统的监控进程。我遇到这种情况的习惯是换不同品牌的设备试试，或者直接用模拟器采集数据。

如果 CPU 探针数据录制后一直是空白的，先别急着怀疑工具坏了，看看是不是录制方式选错了。有时候因为设备过旧，采样模式无法正常工作，这时候切成插桩模式试试，说不定就能看到方法列表了。

6.2 录制时应用明显变卡，数据不可用怎么办

有一个现象经常出现：点开 Record 录制后，原本还算流畅的应用立刻变得很卡，操作手感严重下降。这种情况下的数据其实已经不可用了，因为 Profiler 自身引入的性能开销掩盖了真实问题。

插桩模式最容易出现这个问题。简单估算一下，一次插桩观察一个高频调用的方法，如果原来执行是 1 毫秒，插桩后可能膨胀到 3 到 5 毫秒，系统的调度行为和内存分配模式随之改变。分析这种数据得出的结论，可能是真的性能瓶颈，也可能只是插桩带来的附加影响。

碰到这种情况，我的做法是放弃插桩模式，改用采样模式，并把采样频率调到相对宽泛的水平。这样做会牺牲部分方法级细节，但至少数据能反映基本运行状态。另一个做法是缩小录制范围，比如消除循环里高频方法后，只录制具体触发区域，用 Debug.startMethodTracing 代码方式控制录制时间段，这样能最大程度减少无关注入。

还需要注意，在使用采样的过程中不要让测试机器开启省电模式或限制后台进程，否则系统 CPU 频率会被锁定，录到的数据会全线偏高，误导后续分析判断。

6.3 分析时看不到某个库的内部函数

这个点经常有人问：为什么我在 CPU Profiler 里只能看到自己的方法，第三方的 SDK 方法全是灰的，点了也看不到内部实现？

道理很简单，Profiler 的调用栈信息依赖字节码里的调试信息。如果你的工程把第三方库作为 Release 依赖引入，ProGuard 压缩混淆之后，类名和方法名都被改变了，调试信息也很可能被删掉了。这时候 Profiler 能显示的是混淆后的名称，比如 a.b.c.d，没法映射回原始方法名。

要看到库的内部调用栈，有两个思路。一是在 Debug 构建中引入这个库的未混淆版本，某些大库会提供 debug 权限的依赖配置；二是用 Profiler 自带的 Deobfuscate 功能导入 mapping 文件，让混淆后的方法名还原成真实名称。如果这两种方式都不好办，那就退一步，只分析这个库的入口点和整体耗时，观察它在流程中占用的份额已经足够辅助决策了。

6.4 模拟器和真机数据差异的坑

很多初学者喜欢在模拟器上分析性能数据，结论带出来的优化方案到了真机上却不顶用，原因在于模拟器与真机的硬件架构、CPU 调度策略差异很大。模拟器上的 CPU 是宿主机虚拟化出来的，真实硬件能力往往比手机高不少，App 在模拟器上很少会出现卡顿掉帧，正好掩盖了性能问题。

反过来，模拟器上的内存分配模式也和真机不同，模拟器可能会用宿主机的内存管理策略，导致 GC 行为与实际 Android 设备有较大偏差。所以我自己的习惯是：快速验证问题路径用模拟器，最终性能判断和优化效果验证一定上真机，最好覆盖高中低三档机器。

真机测试的时候还建议把 USB 连接改为无线调试，尤其是在录制长时间数据时，USB 线材的干扰会导致偶发掉线，直接中断录制。无线调试虽然偶有波动，但长期稳定性往往更好。具体操作很简单，开发者选项里启动“无线调试”功能，用 Android Studio 扫码配对即可，网上也能找到完整的连接图文。

6.5 一个真实但孔子难见的数据盲区：GPU 渲染分析

Profiler 的 CPU、Memory、Network、Energy 四个探针基本覆盖了日常性能问题的栈，但 UI 掉帧还有一个重要原因是 GPU 渲染超负荷。比如过渡绘制严重、动画里频繁触发布局、部分硬件渲染效果开销过大，这些单看 CPU 数据可能发现不了。

Android Studio 里另外一个工具可以补充这个盲区，就是“GPU 渲染模式分析”，开发者选项里可以开启“Profile GPU rendering”功能，显示条状图能直观看出每帧渲染时间是否超过了 16 毫秒。再加上 Profiler 自带的 System Trace 模式，能看到 Surface Flinger 的合成耗时和主线程的 Choreographer 调度信息。

实际用的过程中，我会先看 CPU Profiler 有没有占用过高的任务，再开 GPU 渲染条确认掉帧是否来自渲染层。两者结合起来，分析链才算完整。比如一个常见问题：某个 View 在滑动时不断触发 invalidate，CPU 使用率并不高，但 GPU 渲染负载在每帧都超时，此时排查 View 的属性动画是否在持续执行，往往能一击致命。

7. 性能分析之外的一些心得

我把 Profiler 当作发现问题的手段，而不是“性能优化的全部”。拿到数据只是第一步，真正有价值的在于你能否把无关信息剥离掉，找到那个“决定性变量”。有时候数据摆在那里，答案已经呼之欲出。

自己在实操中最深刻的体会是：工具越强大，越要克制分析范围。以前刚开始学 Profiler 的时候，每遇到一个问题就习惯把所有探针全开，结果录完的数据量巨大，分析一个小时也没找到重点。后来变成每个问题最多开两个探针，先看整体趋势再聚焦细节，效率和准确率反而提升了不少。

给刚入门的读者一个建议：找一台旧手机，随便写个小 Demo，在里面做一个耗时的 for 循环和内存泄漏的模拟场景，然后自己在 Profiler 里走一遍分析流程。这个过程比读十篇文档都管用，因为你的眼睛会逐渐习惯“健康的数据长什么样”，下次见到异常就能一眼揪出来。