1. 从一次性能排查说起为什么需要关注CPU核那天下午测试同事抱着一台测试机过来眉头紧锁“这个App在后台跑着跑着手机就烫得不行前台操作也卡顿你看看是不是哪里死循环了” 我接过来手机后盖确实温热划动屏幕有明显的掉帧感。这种问题十有八九和CPU使用率脱不开干系。作为一个Android开发者遇到性能问题尤其是发热和卡顿第一反应就是去抓取CPU的使用情况。在桌面端我们有任务管理器、top、htop这些直观的工具。但在Android设备上尤其是面对用户现场反馈的问题我们往往无法直接安装图形化工具。这时adb shell就成了我们连接设备、洞察其内部状态的“瑞士军刀”。而CPU作为计算的核心其每个核心的负载、频率、在线状态都是诊断性能瓶颈、分析功耗问题的关键指标。很多人知道用adb shell top看个总的CPU占用率但这远远不够。现代的智能手机SoC都是多核异构设计比如“134”的三丛集架构包含高性能核心、平衡核心和能效核心。一个App的线程可能被调度到不同核心上运行其功耗和性能表现天差地别。如果某个耗电大户线程一直被调度在小核上可能只是慢但如果它长时间“霸占”大核那发热和耗电就会非常明显。因此仅仅知道“CPU总占用率80%”是苍白的我们需要知道是哪个进程它的哪些线程跑在哪个CPU核心上那个核心的频率现在是多少这就是掌握adb shell中关于CPU核的命令的意义。它让你能从系统调度器的视角看清计算资源是如何被分配的从而精准定位“谁在何时何地干了重活”。无论是做性能优化、功耗分析还是解决一些深层次的系统稳定性问题这些命令都是不可或缺的基础工具。接下来我就结合实际的排查场景带你深入这些命令的细节和实战用法。2. 基础认知理解Android设备的CPU拓扑在敲命令之前我们必须对我们正在探查的对象——Android设备的CPU——有一个基本的了解。这能帮助你看懂命令输出的数字和信息的含义。2.1 核心、簇与异构架构如今的手机处理器早已不是单核或同质多核。以高通骁龙8系列或联发科天玑系列为例普遍采用“大小核”或“三丛集”设计。例如一个8核处理器可能由以下组成1个 Cortex-X系列超大核最高性能负责瞬时高负载任务频率高功耗也高。3个 Cortex-A系列大核平衡性能与功耗处理中度负载。4个 Cortex-A系列小核高能效处理后台任务和轻度负载维持低功耗。在Linux内核Android基于Linux的视角下每个CPU核心都有一个唯一的编号通常是cpu0,cpu1,cpu2...。但这些编号的排列顺序是有讲究的它反映了物理核心的布局和所属的“簇”。同一个簇内的核心通常具有相同的微架构和电源域。如何查看这个拓扑信息呢最直接的方法是查看内核提供的sysfs文件系统。adb shell cat /sys/devices/system/cpu/possible这条命令会输出系统可能存在的CPU核心编号范围例如0-7表示系统识别到8个CPU核心cpu0到cpu7。adb shell cat /sys/devices/system/cpu/present这条命令输出当前实际上线online的CPU核心范围。在有些场景下系统可能会为了省电关闭部分核心present的范围可能小于或等于possible的范围。要查看每个核心的详细信息可以进入每个CPU的目录。不过更直观地了解核心属于哪个簇性能分组可以查看cpufreq相关的信息因为通常同一个簇的核心共享频率策略。一个实用的方法是adb shell ls -d /sys/devices/system/cpu/cpu*/cpufreq/related_cpus查看每个cpu目录下related_cpus文件它会告诉你和这个cpu共享频率策略的其他cpu核心编号。输出相同内容的核心通常就属于同一个簇。注意不同厂商、不同内核版本sysfs的路径和内容可能略有差异。但/sys/devices/system/cpu/这个基础路径是标准的。探索这个目录下的文件是了解你手中设备CPU详情的最佳方式。2.2 核心状态Online与Offline为了动态节能Linux内核和Android系统的调度器可以动态地将CPU核心“下线”offline或“上线”online。当一个核心被offline时它将被移出调度队列不再执行任何任务进入低功耗状态。你可以通过以下命令查看所有核心的当前在线状态adb shell cat /sys/devices/system/cpu/online或者分别查看每个核心的状态for i in 0 1 2 3 4 5 6 7; do echo -n cpu$i: ; adb shell cat /sys/devices/system/cpu/cpu$i/online; done输出为1表示在线0表示离线。在系统负载极低时如锁屏待机你可能会看到只有cpu0通常是第一个小核在线其他核心全部离线。手动控制核心在线状态需root权限 虽然日常调试不常用但在某些深度性能测试场景你可能需要强制关闭或开启某个核心以测试应用在不同核心配置下的表现。# 将 cpu4 下线 adb shell echo 0 /sys/devices/system/cpu/cpu4/online # 将 cpu4 上线 adb shell echo 1 /sys/devices/system/cpu/cpu4/online重要警告随意操作核心在线状态可能导致系统不稳定、死锁或性能异常尤其是在关闭所有小核或最后一个在线核心时。请仅在具备root权限的测试设备上并明确知晓后果的情况下进行此类操作。3. 核心监控命令详解从宏观到微观掌握了CPU的基本布局后我们开始使用各种命令来监控它的实时状态。3.1 top进程级的CPU占用概览top命令是最经典的实时系统监控工具它能提供系统概况和进程列表。adb shell top默认输出包含很多信息我们重点关注以下几行User 10%, System 5%, IOW 0%, IRQ 0% User 234 Nice 0 Sys 125 Idle 1650 IOW 0 IRQ 0 SIRQ 0 2009 PID USER PR NI VIRT RES SHR S[%CPU] %MEM TIME ARGS 12345 u0_a123 20 0 3.2G 180M 120M S 45.3 4.5 1:23.45 com.example.myapp第一行CPU占用百分比User用户空间、System内核空间、IOW等待IO、IRQ硬中断的CPU时间占比。这给出了CPU时间花费在哪个层面的宏观视图。如果System或IOW异常高可能意味着内核驱动有问题或存储IO瓶颈。第二行CPU时间片统计以jiffies时钟滴答为单位统计各类状态的时间。Idle值很大是正常的表示CPU空闲。进程列表%CPU列显示了该进程在所有CPU核心上总的CPU时间占用百分比。注意在多核系统中这个值可以超过100%。例如一个8核设备如果一个进程的线程完全占满两个核心其%CPU可能接近200%。常用参数adb shell top -d 1设置刷新间隔为1秒。adb shell top -m 10只显示前10个进程。adb shell top -s %CPU按CPU占用率排序部分top版本支持。adb shell top -p PID只监控特定进程ID。top的缺点是它不告诉你进程的线程具体跑在哪个核心上。这就需要更细粒度的工具。3.2dumpsys cpuinfoAndroid视角的CPU负载这是Android系统特有的命令能提供更贴近框架层的信息。adb shell dumpsys cpuinfo输出示例Load: 8.31 / 7.52 / 7.21 CPU usage from 12345ms to 23456ms ago: 45% 12345/com.example.myapp: 45% user 0% kernel 20% 678/system_server: 15% user 5% kernel ... 5.2% TOTAL: 4.1% user 1.1% kernel 0% iowait 0% irq 0% softirqLoad average系统负载平均值1分钟、5分钟、15分钟。这个值除以CPU核心数可以粗略判断系统繁忙程度。例如8核设备负载为8意味着平均每个核心都刚好满负荷。CPU usage from ... ago这是dumpsys cpuinfo最核心的功能。它提供了一个过去一段时间内如上例中的约11秒的CPU使用率快照。这对于分析一个已经发生的卡顿或发热问题特别有用你可以复现问题后立即执行该命令查看是哪个进程在那段“问题时间窗口”内消耗了大量CPU。TOTAL总计的CPU占用拆分为用户态、内核态等。这个命令是分析历史性能问题的利器弥补了top只能看瞬时的不足。3.3ps与taskset查看与绑定线程要看到线程级别并知道线程跑在哪个核心上我们需要组合使用ps和taskset或查看/proc文件系统。查看进程的所有线程adb shell ps -T -p PID-T参数会显示线程信息。你会看到很多线程每个线程有自己的TID线程ID。查看特定线程当前运行在哪个CPU核心上 最直接的方法是查看内核为每个线程在/proc文件系统中暴露的信息。adb shell cat /proc/TID/stat这个文件第39个字段从1开始计数就是processor表示该线程最后一次被调度执行时所在的CPU核心编号。注意这是“上一次”的位置线程可能很快被调度到其他核心。更实时的方法使用top的H模式 在adb shell top的界面中按H键大写可以切换显示线程信息。这样就能实时看到每个线程的CPU占用但依然看不到核心绑定信息。绑定线程到特定CPU核心tasksettaskset命令可以用来设置或查询一个进程/线程的CPU亲和性affinity即它允许在哪些CPU核心上运行。这通常用于性能测试或隔离。# 查询进程PID 12345的CPU亲和性 adb shell taskset -p 12345 # 输出如pid 12345s current affinity mask: ff # ‘ff’是十六进制二进制为11111111表示可以运行在0-7号核心。 # 将进程PID 12345绑定到仅运行在cpu0和cpu1上需root adb shell taskset -p 0x3 12345 # 0x3的二进制是00000011对应cpu0和cpu1。 # 启动一个新进程并绑定到cpu4-7大核簇 adb shell taskset 0xf0 command # 0xf0二进制是11110000对应cpu4,5,6,7。实操心得强制绑定CPU亲和性在生产环境中需极其谨慎。不当的绑定可能破坏系统的负载均衡策略导致某些核心过载而其他核心闲置反而降低性能或增加功耗。它主要用于特定的基准测试或调试场景例如你想测试一个计算密集型任务如果被限制在小核上运行其耗时和发热情况。4. 深入/proc文件系统获取最原始的CPU数据Linux的/proc是一个虚拟文件系统提供了大量内核和进程的运行时信息。对于CPU监控以下几个文件至关重要。4.1/proc/stat系统全局CPU时间统计这个文件包含了自系统启动以来所有CPU核心累积的工作时间统计单位是USER_HZ通常为1/100秒。adb shell cat /proc/stat输出首行通常是cpu 234566 12345 67890 1234567 890 5678 1234 0 0 0这一行是所有CPU核心的合计。各列含义依次为user用户态运行时间。nice低优先级nice值0用户态运行时间。system内核态运行时间。idle空闲时间。iowait等待IO完成的时间。irq处理硬中断时间。softirq处理软中断时间。steal虚拟化环境下被宿主机“偷走”的时间。guest运行虚拟CPU时间。guest_nice低优先级虚拟CPU时间。紧接着cpu行之后你会看到cpu0,cpu1,cpu2...等行它们是每个独立核心的相同统计信息。如何计算实时CPU使用率/proc/stat提供的是累积值。要计算某个时间点的使用率需要采样两次然后做差计算。在时间点T1读取/proc/stat记录cpu行的total1 usernicesystemidleiowaitirqsoftirqsteal以及idle1。等待一段时间间隔如1秒。在时间点T2再次读取得到total2和idle2。过去1秒内的CPU利用率 ((total2 - total1) - (idle2 - idle1)) / (total2 - total1) * 100%。许多系统监控工具的内部原理正是如此。4.2/proc/PID/stat与/proc/PID/task/TID/stat进程与线程详情如前所述这个文件包含了进程/线程的详细信息。除了第39字段的processor其他有用字段包括字段 1: PID。字段 2: 可执行文件名在括号内。字段 3: 进程状态R运行S睡眠D不可中断睡眠等。字段 14/15: 用户态/内核态累积占用CPU时间单位USER_HZ。通过计算这两个值的增量可以精确算出某个时间段内该进程消耗的CPU时间。4.3/proc/PID/sched与/proc/PID/schedstat调度器信息这两个文件提供了更底层的调度信息对于高级性能分析很有帮助。adb shell cat /proc/PID/sched可以查看进程的调度策略如SCHED_NORMAL即CFS、优先级prio、权重load.weight等。adb shell cat /proc/PID/schedstat输出三个数字例如1234567 8901234 567890。第一个数字该进程在CPU上执行的时间纳秒。第二个数字在运行队列上等待的时间纳秒。第三个数字被调度执行的次数。 通过分析等待时间与执行时间的比例可以判断进程是否经常因为CPU竞争而处于等待状态。5. 实战案例定位一个高CPU占用导致的发热问题让我们回到开头的那个场景。测试同事反馈App在后台发热严重。第一步宏观定位首先连接设备使用top命令快速查看当前哪个进程的CPU占用异常。adb shell top -d 2 -m 5观察几轮刷新发现我们的目标应用com.example.myapp在后台时%CPU持续在60%-80%之间波动。这显然不正常一个后台应用不应该持续消耗如此多的CPU。第二步深入进程内部获取该应用的PID假设为12345然后查看其所有线程的CPU使用情况。adb shell top -H -p 12345或者adb shell ps -T -p 12345 | grep -v “-”发现有一个名为NetworkThread的线程CPU占用率异常高几乎占满了整个进程的CPU时间。第三步结合历史数据分析为了确认这个高消耗是持续性的我们使用dumpsys cpuinfo来获取过去一段时间比如发生发热的那几分钟的总体情况。adb shell dumpsys cpuinfo在输出中我们清晰地看到com.example.myapp在过去的统计周期内占据了接近50%的CPU总时间是消耗最大的应用。这证实了我们的判断。第四步线程级核心分布分析我们想看看这个NetworkThread是否被不恰当地调度到了大核上。由于top -H不显示核心信息我们需要找到该线程的TID假设为12346然后持续监控其/proc信息。# 写一个简单的shell循环来监控 adb shell while true; do cat /proc/12346/stat | awk ‘{print “Core:” $39 “, State:“ $3}’; sleep 0.5; done观察输出发现NetworkThread大部分时间都显示processor字段为4,5,6,7根据之前拓扑分析这些正是大核的编号。同时进程状态$3几乎一直是R运行说明它在疯狂运行几乎没有休眠。第五步溯源与解决现在问题很明确了一个后台网络线程持续活跃且被调度在大核上执行。我们接下来需要检查代码这个线程在做什么检查NetworkThread的run()方法发现它在一个while(true)循环中不断地进行非阻塞的Socket读取没有合适的等待/休眠机制导致空转。为什么调度在大核因为它的执行几乎是连续的负载很高系统调度器认为它是高性能需求任务因此倾向于将其放到大核上处理。解决方案修改NetworkThread的逻辑在没有数据时调用Thread.sleep()或使用带超时的Selector进行等待避免空转循环。考虑是否真的需要一个常驻的后台网络线程能否用WorkManager或JobScheduler等系统调度机制来替代。非必要不推荐在极端情况下如果确认该线程是低优先级任务可以尝试以nice值启动它或使用taskset将其绑定到小核簇需root且仅作测试但这只是治标优化代码逻辑才是根本。修改代码并发布新版本后重复上述监控步骤发现该线程的CPU占用降到了接近0%processor字段也经常出现在0-3小核范围手机发热问题消失。通过这个案例你可以看到从宏观的top发现异常到微观的/proc查看线程核心绑定再到结合dumpsys的历史数据分析最后定位到代码问题一套完整的adb shellCPU命令链是如何在真实排查中发挥作用的。这远比凭空猜测或盲目优化要高效和准确得多。掌握这些命令就等于拥有了透视Android设备CPU运行状态的“眼睛”。