做安卓开发或者性能测试的同学，一定遇到过这种尴尬：用户天天报障说App卡成PPT、手机烫得能煎蛋，可你在工位上拿着Android Studio的Profiler反复试，界面永远显示一切正常。我自己的习惯是，这种时候干脆别纠结复现了，掏出数据线连上设备，敲一条 adb shell top 直接看整机实时状态。作为系统内置的进程监控工具，它能实时列出所有进程的CPU占用、内存占用和运行状态，不需要root、不需要额外装包、不要求debug版App，一条adb连接就够。这篇文章我会把 adb shell top 的每个参数、每一行输出、每一个实战姿势和坑都拆开讲透，适合刚入门的安卓开发，也适合需要系统化做性能排查的测试和性能优化工程师。
下面这些内容不是我对着man page抄的，是我在真机上一个个敲过去、踩过坑之后总结出来的。不同品牌、不同安卓版本的设备，top命令的表现会有差异，所以我会先把通用原理讲明白，再说哪些地方需要你在自己的设备上确认。
1. adb shell top到底是什么，性能排查为什么绕不开它
1.1 一条命令照出所有进程的CPU与内存
很多新手第一次敲 adb shell top，会以为它跟Windows的任务管理器一样，打开看一眼就关。其实它可以做得更多：实时刷新、动态排序、指定采样次数和间隔，甚至输出成文本文件丢给脚本做趋势分析。它底层读取的是 /proc 目录下的进程信息，每次刷新都会重新计算，所以能真实反映当前系统的运行状态。
平时排查问题，我最常干的动作就是执行adb shell top -n 1，一行命令下来，当前设备上几百个进程的CPU占用、内存占用、运行状态直接排好队。普通App开发可能觉得这没什么，但做性能优化的人都知道，很多线上问题就藏在这些数字里：某个进程CPU一直30%以上，某个进程RES持续上涨，某个线程在后台空转。top把这些线索全部摆在明面上。
1.2 什么场景非它不可，什么场景别硬用
先说适合用top的场景：
- App切到后台后CPU占用依然很高，导致耗电、发热
- 怀疑某个第三方SDK在后台做轮询或重试，证据不明确
- 自动化压测或Monkey测试时，需要持续记录进程的CPU和内存变化
- 多进程架构App排查资源竞争，需要同时观察多个进程的状态
- 线上反馈卡顿，需要快速判断是CPU瓶颈还是别的问题
再说别硬用top的场景。如果你要定位函数级别的性能热点，比如某个方法执行太慢，top帮不了你，这得用simpleperf或者systrace。如果你要搞清楚App内存的具体构成，比如Java堆占多少、Native堆占多少、图形缓冲区占多少，top只给你一个RES总量，远远不够，这个时候应该转向dumpsys meminfo。top的定位是"第一道筛查"，是让你快速建立整体认知的工具，而不是一个深入细节的重型分析器。
1.3 和Android Studio Profiler比，它赢在哪输在哪
Android Studio自带的Profiler确实很强大，能看到CPU、内存、网络、能耗的详细曲线，甚至能下钻到具体方法。但它有个现实问题：调试过程中，它需要attach到应用进程，这本身会引入性能开销，而且很多时候它要求你跑debug包。一旦面对线上真机、release包、或者根本不是你自己的工程，Profiler往往派不上用场。
adb shell top的优势正好是它的反面：零侵入、无开销、随时随地可用。只要有ADB连接，不管是开发机、测试机还是用户反馈的某台特定机型，都能跑起来。而且它天然适合脚本化，你完全可以用一个shell循环持续采集几十次，结果存成文本慢慢分析。这在自动化测试里特别实用。Profiler更适合开发自测阶段，top更适合排查阶段和线上问题复现阶段，两者是互补关系，不是替代关系。
我记得有一次帮同事排查问题，对方把工程跑在Android Studio里，怎么调都正常。后来我用adb连上他那台设备，直接top -n 1一看，确实有个系统进程在疯狂吃CPU，跟App本身一点关系都没有。如果当时只依赖Profiler，方向就直接跑偏了。
2. 参数详解：先把这几个常用参数吃透
2.1 -n与-d：采样次数与刷新间隔
最基础也是最重要的两个参数。
-n指定top执行的次数。adb shell top -n 1表示只输出一次后自动退出，这是最常用的快速查看方式。-d指定刷新间隔，单位是秒。比如adb shell top -d 2 -n 10表示每2秒刷新一次，一共输出10次，总时长20秒。
为什么我强调一定要加-n？因为如果不加，top会一直在那里动态刷新，在adb shell里你很难受地看它刷屏，Ctrl+C才能退出，而且这种行为在脚本里会导致命令永远不结束，直接卡死自动化流程。所以我的习惯是：手动快速看一眼用top -n 1，做持续观察用top -d 2 -n 50这种组合。
采样间隔也不宜设得太短。有人为了拿到更多数据点把-d设成0.1秒，结果top本身的CPU开销反而影响了采样结果，数字看起来跳来跳去，失去了参考意义。一般取1到3秒比较合理，既能覆盖瞬时波动，又不会给系统增加负担。
2.2 -s与-m：排序和行数控制
-s用来指定排序字段。最常见的用法是-s cpu按CPU占用排序，以及-s res按内存占用排序。默认情况下top一般已经按CPU降序排列，但如果进程特别多，CPU靠前的进程往往集中在前面几行，你想看内存占用最高的进程，就得换排序字段。
-m用来限制显示的行数。比如adb shell top -n 1 -m 30只显示前30行，对于屏幕有限、或者只需要关心Top N的场景非常有用。
这两个参数组合起来，就是一条非常实用的命令：
# 查看内存占用最高的30个进程 adb shell top -n 1 -m 30 -s res需要注意的是，-s后面到底支持哪些字段名，不同设备不一样。有的设备写-s cpu，有的写-s %cpu，有的还支持-s pid、-s time。最靠谱的办法是先在设备上执行adb shell top -h，看一下帮助文档里明确支持的选项，再对应去用。
2.3 -b与-H：脚本化输出与线程视角
-b是批处理模式。普通模式下top输出为了适合终端展示，会做一些清屏和格式处理；加了-b之后，它会像一个普通命令一样把结果连续打印出来，适合重定向到文件或者管道给其他命令处理。
# 持续采样30次，每次间隔2秒，结果保存到文件 adb shell top -b -d 2 -n 30 > top_trace.txt后面分析的时候，直接用grep、awk就能从文件里抽取你关心的进程行，非常方便。这条命令我在自动化测试和长时间稳定性测试里用得极其频繁。
-H则是线程视角。默认top显示的是进程级信息，加上-H之后，同一个进程下面的所有线程会逐个列出来，每个线程有自己的PID（在top里通常叫TID）和CPU占用。这用来定位"哪个进程在吃CPU"之后的下一步"哪个线程在吃CPU"特别有用，后面实战部分我会细讲。
不过要提醒一句：-H不是所有设备都支持。老一些的安卓版本、某些定制ROM的top实现里可能没有这个选项。如果不支持，备选方案是用adb shell ps -T -p 进程PID查看线程列表。
2.4 版本差异：不同安卓设备的top不完全一样
安卓的top命令有好几代"血统"。早期Android用的是toolbox里的top，参数非常有限，很多高级选项都没有。后来系统逐步换成了toybox，参数才丰富起来。再加上三星、小米、华为这些厂商偶尔会改自己的工具集，所以你在不同设备上执行top -h，看到的帮助内容很可能是不同的。
我自己就遇到过一台设备支持-s time按CPU累计时间排序，另一台设备同样写法直接报错。所以别背参数，要背思路：看看当前设备支持什么选项，然后灵活组合。这也是我把adb shell top -h当作第一条、也是最重要的命令推荐给你的原因。
3. 输出信息逐行拆解，每一列都是线索
3.1 前几行系统状态：Tasks、Mem、CPU
拿一次真实的top输出来举例（我简化过字段名，实际设备可能略有出入）：
Tasks: 512 total, 1 running, 388 sleeping, 0 stopped, 0 zombie Mem: 5820612k total, 3944160k used, 1876452k free, 110432k buffers Swap: 2097148k total, 118808k used, 1978340k free, 2755192k cached 800%cpu 42%user 11%nice 308%sys 439%idle 0%iow 0%irq 0%sirq 0%host第一行Tasks告诉我们当前系统的进程总数，以及处于running、sleeping、stopped、zombie状态的数量。安卓和Linux桌面系统一样，绝大多数进程平时都是sleeping，running数量一般很少。如果你看到running长期有好几个，说明系统负载很高，CPU调度不过来。
第二行Mem是物理内存情况：total总内存、used已用内存、free空闲内存、buffers缓冲。注意这里还有一个cached的概念，在有的top版本里，cached会出现在Swap行的末尾，它表示文件缓存占用的内存，这部分在系统内存紧张时可以被回收，所以"used"大不代表真的不够用。
第三行Swap是交换分区。很多手机默认没有swap，这行total会是0。如果你看到swap的used一直在涨，说明系统内存压力很大，已经开始把内存页换到交换区了，这种情况在手机上通常意味着内存严重不足。
第四行是CPU状态，这里有个常见误区。看到800%cpu别慌，这不是系统出问题了，而是这台设备有8个CPU核心，所以总CPU百分比上限是800%。后面的user、nice、sys、idle等数值加起来也大致等于这个上限。sys占比高，说明内核态消耗了大量的CPU，可能跟驱动、系统调用频繁有关；user占比高，一般是应用层计算密集。如果长期idle很低，系统基本处于满载状态。
3.2 进程列表字段：RES、VIRT、SHR和CPU%，这些值怎么看
前几行下面是进程列表，典型的一行长这样：
PID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME+ ARGS 2103 u0_a321 10 -10 3.1G 180M 96M S 27.6 3.1 0:41.23 com.example.appPID：进程ID，唯一标识。USER：运行进程的用户。安卓App的用户一般是u0_a开头，后面的数字和App安装顺序有关。同一个App有多个进程时，它们通常都在同一个USER下面。PR和NI：进程优先级和nice值。nice值越低，优先级越高。VIRT：虚拟内存大小，是进程申请过的虚拟地址空间总量，注意它并不代表真实占用的物理内存，很多地址空间可能只是映射但没有实际使用。RES：常驻物理内存，也就是这个进程当前真正占用的物理内存总量，一般以K、M为单位。这个值比VIRT直观得多，是内存判断的重要依据。SHR：共享内存大小，指与其他进程共享的那部分物理内存。S[%CPU]：前面那个S是进程状态，常见的有S（sleeping睡眠）、R（running运行）、D（不可中断的IO等待）等；后面的[%CPU]是这个进程当前的CPU占用百分比。%MEM：RES占系统总内存的百分比。TIME+：进程从启动到现在累计消耗的CPU时间，格式是分:秒。这个值不会因为进程休眠而减少，适合判断一个进程长期占用CPU的情况。ARGS：进程名或者完整命令行，一般显示包名或进程名。
看内存的时候，我一般是先看RES，再看%MEM。看CPU的时候，光看当前[%CPU]不够，还要结合TIME+。如果一个进程当前的CPU%并不高，但TIME+一直在快速增长，说明它在不断消耗CPU时间，只是恰好在你采样的这一刻处于空闲或等待状态。
3.3 一个常见误区：RES不等于App真正占用的内存
很多刚接触top的同学，看到自己App的RES是180M，就以为App内存占用就是180M，这个理解有偏差。RES包含了进程独占的物理内存，也包含了它和别的进程共享的库所占用的物理内存。多个App可能共享同一个系统库，这部分内存每个进程的RES里都算了一份，加起来会重复计算。
安卓官方在做内存统计时，更常使用的指标是PSS（Proportional Set Size），也就是按共享比例分摊之后的物理内存。比如一个共享库占10M，有5个进程在使用，那每个进程的PSS里只计入2M。top的输出里没有直接的PSS值，所以如果你要跟系统设置里的应用内存数据进行对比，或者要估算App的真实内存成本，应该用adb shell dumpsys meminfo <包名>去看PSS。
不过这不代表top没用。top的价值在于快速发现趋势：同一进程的RES从100M一路涨到180M、200M、300M，这本身就是内存泄漏的强烈信号。粗筛用top，精细确认用dumpsys，两者配合才是正确的姿势。
4. 实战：三步定位一个CPU异常飙升的案例
4.1 现场采样：确认异常进程
说个真实场景。有次测试反馈，某App退到后台之后手机特别烫，一摸后盖能明显感觉到发热。我拿到设备后先做了一件事：把它静置五分钟，然后执行adb shell top -n 1。
输出里很快看到一个可疑进程，进程名是com.example.pushsdk，CPU占用一直徘徊在25%到35%之间。你可能觉得这个数字不高，但一台8核设备，整机idle有百分之六七十，一个后台推送进程能持续占30%的CPU，绝对异常。正常情况这种进程应该躺在sleeping列表里，CPU占用趋近于0。
为了让结论更扎实，我做了持续采样：
adb shell top -b -d 2 -n 30 > top_trace.txt等了60秒，然后把文件里那个进程相关的行抓出来：
grep com.example.pushsdk top_trace.txt结果很清楚：30次采样里，每一次CPU占用都稳定在25%以上，不是偶发，而是持续性的后台消耗。这就已经基本可以判定问题了。
4.2 缩小范围：从进程到线程
进程层面确认有问题，接下来就要揪出进程内部到底是哪个线程在搞鬼。这一步通常有两种做法。
第一种，设备支持-H参数：
adb shell top -H -n 1 -p 进程PID不过很多安卓设备的top并不支持-p参数级联筛选，如果报错，我一般改用管道加grep：
adb shell top -H -n 1 | grep com.example.pushsdk这样会把该进程下面所有线程的CPU情况全部列出来。
第二种，用ps命令找线程：
adb shell ps -T -p 进程PIDps -T的输出里，每一行就是一个线程，PID那一列显示的是线程ID（TID）。通过这两条命令的组合，我锁定了那个后台上消耗CPU的线程，名字叫PoolThread-7，一看就是某个线程池里的工作线程。
到这里基本可以确认：这个PushSDK里有一个线程池，在后台不断执行某种轮询或重试任务。接下来顺着这个线程名去查代码或者反编译确认，就是开发同学的事了。
4.3 组合拳：top + logcat + dumpsys meminfo
CPU问题往往不是孤立存在的。定位到异常线程之后，我通常还会做一轮"组合拳"，把周边信息一起拉出来，避免漏掉关联问题。
先拉日志看这个进程在反复干什么：
adb logcat -d --pid=进程PID | tail -100日志里往往能看到它每隔几秒就发一次网络请求、或者打印一条错误重试信息，这就解释了CPU为什么下不去。
再检查内存情况：
adb shell dumpsys meminfo com.example.pushsdk这一步是为了确认这个进程除了CPU异常，内存上有没有附加问题。那次排查的结果是：内存PSS正常，问题纯粹集中在CPU上，属于典型的后台死循环式重试。后续在代码里给重试逻辑加了最大次数限制和退避策略，问题就消失了。
另外，如果你想看整机CPU分布的快速快照，可以直接用adb shell dumpsys cpuinfo，这个命令比top更简明，它会把每个进程的CPU占用时间百分比直接列出来，不用像top那样一行行去瞄。两条命令结合，一个是实时视野，一个是累计视野，配合起来效率很高。
5. 常见问题与避坑指南
5.1 高频问题速查表
平时帮同事看问题，遇到最多的几个坑我整理成了表格，遇到相同情况直接照着排查：
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| adb devices看不到设备 | USB驱动没装好、USB调试没开、数据线损坏 | 检查驱动，确认开发者选项里的USB调试已开启，换数据线试 |
| 提示adb unauthorized | 手机上的USB调试授权弹窗没有点允许 | 拔掉重插，在手机上点允许，或撤销之前的调试授权重新授权 |
| top: not found | 部分精简系统移除了top工具 | 先用ps -A代替，或者检查系统完整性 |
| CPU占用显示超过100% | 多核设备总CPU百分比是核心数乘以100 | 比如8核上限800%，结合核心数判断才是真实占用 |
| 进程名显示不全 | 终端宽度不够，ARGS列被截断 | 用-b模式，或把终端窗口拉宽 |
| 单次采样波动很大 | 进程调度本身有瞬时变化 | 多次采样取平均值，或者用-d 1 -n 30持续观察 |
5.2 几个容易踩的坑
第一个坑：把RES当成App内存的全部。前面已经说过，RES里包含共享内存，准确的物理内存占用要看PSS。判断内存泄漏时，与其纠结单次RES数值，不如多采样几次看趋势，趋势比绝对值更可靠。
第二个坑：排序字段不通用。在设备A上-s cpu能用，在设备B上直接报错，这种情况我碰到过不止一次。所以到了新设备，第一件事永远是top -h，把当前设备支持的字段名查清楚。
第三个坑：在自动化脚本里忘了超时控制。adb shell top如果不带-n或者参数配错，会一直运行不退出，整个脚本卡死。我在脚本里都会加类似timeout的命令，或者强行在adb命令后面加-n 1保证它执行一次就退出。
第四个坑：怀疑App之前，先排除系统基线。很多设备刚开机时，系统自带的索引、云同步、相册扫描等任务会把整机CPU拉得很高。我一般会先静置设备几分钟，再采样一轮作为基线，然后才去对比App进程的数据。没有基线，直接把锅扣在某个进程头上很容易误判。
5.3 top解决不了的事，用什么补齐
top是性能排查的起点，但它有能力的边界。方法级的热点分析，用simpleperf，它能告诉你某个native函数或Java方法占了多少CPU。更宏观的整机性能追踪，用Perfetto或者systrace，能看到CPU频率、调度、功耗等维度。内存更细的拆解，用dumpsys meminfo和Java Heap Dump。GPU和渲染层面的问题，用dumpsys gfxinfo或gfxinfo frame stats。
我的建议是：不要指望一条命令解决所有问题，但一定要把top吃透。因为大多数性能问题，最开始的方向判断就是靠它。它告诉你该往哪个方向深挖，后面再用什么工具、抓什么信息，都是基于这个方向去展开的。
我在实际排查中的惯例是，拿到一台问题设备，先跑一轮top采样存成文件，打开看趋势，而不是盯着实时输出发呆。第一眼看到异常数字也不用急着下结论，多采几轮、排除系统基线之后再定位App问题，会少走很多弯路。等你把top用熟了，再上手systrace、Perfetto这些重型工具时，脑子里就会有一张清晰的排查地图，因为你已经知道自己在找什么了。
