1. 项目概述为什么我们需要关注CPU核的命令在Android应用性能调优和系统问题排查的日常工作中CPU的使用情况往往是第一个需要关注的指标。无论是应用卡顿、手机发热还是后台服务异常耗电其根源常常与CPU的调度和负载分配直接相关。作为一名常年与各种“疑难杂症”打交道的开发者我深刻体会到仅仅通过Android Studio自带的Profiler查看宏观的CPU占用率是远远不够的。当我们需要定位到具体是哪一个线程在“疯狂吃U”或者想知道系统是如何将任务分配到大小核上的就必须深入到Linux内核层面而adb shell正是我们通往这个层面的“瑞士军刀”。adb shell提供了大量与CPU核心Core相关的底层命令这些命令是进行深度性能分析、功耗优化乃至竞品分析Benchmark的基石。它们能让我们看到系统最真实的运行状态比如每个核心的实时频率、负载、在线状态以及调度策略。掌握这些命令意味着你不再是被动地看日志和图表而是能主动地探查、干预和分析系统的CPU行为。这对于应用开发者、系统工程师乃至热衷于折腾手机的极客来说都是一项极其宝贵的技能。本文将从实用角度出发拆解那些最常用、最关键的CPU核相关命令并结合实际场景分享如何解读数据以及避坑经验。2. 核心命令工具箱从状态查询到动态控制Android基于Linux内核因此大部分CPU相关的信息都通过Linux的虚拟文件系统如sysfs、procfs暴露出来。adb shell命令是我们访问这些信息的桥梁。下面我们将命令分为几个功能模块进行详解。2.1 探查CPU整体与核心拓扑信息在动手调整之前我们必须先了解设备的“硬件底子”。这包括CPU有多少个核心是什么架构以及大小核的集群划分。1. 查看CPU核心总数与基本信息最直接的方法是查看/proc/cpuinfo文件adb shell cat /proc/cpuinfo这条命令会输出所有CPU核心的详细信息列表。对于每一颗核心通常以processor : 0开头你会看到processor 逻辑CPU编号从0开始。BogoMIPS 一个粗略衡量CPU速度的指标在跨平台比较时意义不大但在同一设备上可以作为一个参考。Features CPU支持的指令集特性如neon,aes,pmull等对于某些依赖特定指令集优化的应用很重要。CPU implementer/architecture/variant/part/revision 用于精确识别CPU型号如ARM Cortex-A78。注意现代手机多采用ARM big.LITTLE或类似的大小核架构/proc/cpuinfo会列出所有核心但不会直接告诉你哪些是“大核”哪些是“小核”。你需要结合CPU part编号例如0x805可能对应小核Cortex-A550x80d对应大核Cortex-A77和频率信息来综合判断。一个更简洁的查看逻辑核心数的方法是adb shell cat /proc/cpuinfo | grep “processor” | wc -l或者使用adb shell nproc2. 查看CPU核心的拓扑与集群关系这对于理解大小核调度至关重要。信息位于/sys/devices/system/cpu/目录下。查看所有CPU核心的列表adb shell ls /sys/devices/system/cpu/你会看到类似cpu0,cpu1,cpu2,cpu3,cpu4,cpu5,cpu6,cpu7的目录代表8个逻辑核心。查看核心的在线状态是否被启用adb shell cat /sys/devices/system/cpu/cpu0/online输出1表示在线0表示离线。这对于测试热插拔或省电模式很有用。查看核心所属的物理封装和簇clusteradb shell cat /sys/devices/system/cpu/cpu0/topology/physical_package_id adb shell cat /sys/devices/system/cpu/cpu0/topology/core_siblings_listphysical_package_id相同的核心属于同一个物理CPU封装对于手机通常都是0。core_siblings_list更关键它列出了与当前核心共享某些资源如L2缓存的核心列表这通常对应一个“簇”。在大核簇和小核簇的设备上不同簇的核心会显示在不同的siblings_list中。2.2 监控CPU频率与实时负载知道了核心布局下一步就是看它们“干活”的状态跑得多快忙不忙。1. 查看与设置CPU频率CPU频率动态调整DVFS是功耗和性能平衡的关键。查看每个核心的可用频率档位adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies查看当前频率adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq或者查看CPU驱动设置的频率adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq两者在大多数情况下一致但scaling_cur_freq反映的是调度器请求的频率cpuinfo_cur_freq是硬件实际报告的频率。查看频率策略和 governor调频器adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor常见的governor有performance性能优先常驻最高频、powersave省电优先常驻最低频、schedutil基于调度器负载动态调整现代内核默认、ondemand传统负载响应式调整。需root权限设置 governor 或频率adb root # 获取root权限 adb shell “echo performance /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor”或者直接锁定频率不推荐长期使用adb shell “echo 1804800 /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq” adb shell “echo 1804800 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq”2. 查看CPU实时负载与使用率/proc/stat文件提供了自系统启动以来CPU时间的累计统计。adb shell cat /proc/stat输出第一行cpu是所有核心的聚合后面cpu0,cpu1等是每个核心的独立统计。每一列的含义是单位USER_HZ通常为1/100秒user 用户态运行时间。nice 低优先级nice值0用户态运行时间。system 内核态运行时间。idle 空闲时间。iowait 等待I/O完成的时间。irq 处理硬中断时间。softirq 处理软中断时间。steal虚拟化环境 被宿主机“偷走”的时间。guest 运行虚拟CPU时间。计算某个核心的瞬时使用率是一个经典技巧间隔1秒采样两次/proc/stat中对应核心的数据然后计算非空闲时间总时间-空闲时间的增量占总时间增量的百分比。这个计算可以通过脚本自动化是许多性能监控工具的基础。2.3 控制CPU核心的在线与离线热插拔为了极致省电系统或用户可以动态关闭离线某些核心通常是先关闭大核再关闭小核。这称为CPU热插拔。查看核心当前在线状态adb shell cat /sys/devices/system/cpu/cpu7/online通常需root权限使核心离线/在线adb shell “echo 0 /sys/devices/system/cpu/cpu7/online” # 关闭cpu7 adb shell “echo 1 /sys/devices/system/cpu/cpu7/online” # 开启cpu7这个操作在测试多核负载分布、模拟低端机环境或进行功耗测试时非常有用。例如你可以手动关闭所有大核观察你的应用在小核集群上的性能表现。重要警告热插拔核心有风险特别是不能关闭所有核心cpu0通常是启动核心不能离线。不当操作可能导致系统无响应或死机需要重启才能恢复。务必在明确目的和可承受风险的情况下操作。2.4 进程/线程级别的CPU亲和性Affinity这是高级优化手段。CPU亲和性决定了进程或线程可以被调度到哪些核心上运行。将其绑定到特定核心如大核可以提升关键线程的性能和确定性但也可能破坏系统的负载均衡。查看进程的当前亲和性掩码adb shell taskset -p PID输出一个十六进制的位掩码如f每一位代表一个CPU核心从0开始。f二进制1111表示可以运行在0-3号核心上。设置进程的CPU亲和性adb shell taskset -p mask PID例如taskset -p 1 1234将PID为1234的进程绑定到仅运行在cpu0上。启动新进程并设置亲和性adb shell taskset mask command实操心得对于音频播放、高优先级渲染线程或关键后台服务可以考虑将其绑定到大核簇以减少因被调度到小核而产生的性能抖动。但不要滥用否则可能导致大核过载而小核闲置整体能效比下降。在Android上更常见的做法是利用cpusetcgroup由系统服务管理进程组而非直接使用taskset。3. 实战场景组合命令进行问题诊断与性能分析单独的命令只是工具组合起来才能解决实际问题。下面通过几个典型场景展示如何灵活运用上述命令。3.1 场景一诊断应用卡顿与发热现象某个游戏或应用在运行时出现间歇性卡顿且手机后背发热明显。排查步骤定位问题进程使用adb shell top -d 1或adb shell ps -A | grep 应用名找到可疑进程的PID。监控整体CPU负载在另一个终端持续运行adb shell “watch -n 1 ‘cat /proc/stat | head -n 5’”观察所有核心的idle值是否持续很低。如果所有核心的idle都接近0%说明系统整体负载饱和。查看各核心频率运行adb shell “watch -n 1 ‘cat /sys/devices/system/cpu/cpu[0-7]/cpufreq/scaling_cur_freq’”。观察是否所有核心尤其是大核都长时间运行在最高频率附近。如果是说明应用计算压力大触发了性能模式。分析进程线程获取进程PID后查看其所有线程的CPU占用和运行在哪个核心上。adb shell top -H -d 1 -p PID或者更精细地通过/proc/PID/task/目录查看每个线程的stat文件结合adb shell ps -T -p PID查看线程名。找到持续占用CPU高的线程。检查线程亲和性对于高占用的线程TID使用adb shell taskset -p TID查看它被允许在哪些核心上运行。如果它被错误地限制在了小核簇可能就是卡顿的原因之一。检查CPU热插拔运行adb shell “cat /sys/devices/system/cpu/cpu*/online”。看看是否因为温度过高系统主动关闭了一些大核显示为0导致性能下降进而引发更严重的发热和卡顿恶性循环。通过这一套组合拳你就能判断卡顿是源于单线程计算瓶颈一个核心满载其他空闲、多线程竞争多个核心均高负载、频率上不去温控限制、还是核心被关闭热插拔。3.2 场景二进行功耗与性能的基准测试在进行竞品对比或评估优化效果时需要控制变量。CPU核心状态就是一个关键变量。测试准备固定频率需root将所有核心的scaling_governor设置为performance并锁定scaling_max_freq和scaling_min_freq为同一值例如大核锁定在2.0GHz小核锁定在1.5GHz。这消除了DVFS带来的性能波动。控制核心数需root通过online接口分别测试在“仅小核开启”、“大小核全开”、“仅大核开启”等不同核心配置下的应用性能如帧率、任务完成时间和功耗通过电池电流或功率计读取。监控状态在测试过程中使用脚本持续记录/proc/stat、scaling_cur_freq和online状态确保测试条件符合预期没有发生热降频或核心意外离线。这样得到的数据可以清晰地揭示你的应用在不同算力配置下的性能天花板和能效比为产品定义需要几核和优化方向优化大核利用率还是小核效率提供数据支撑。3.3 场景三排查系统后台异常唤醒与耗电现象手机待机耗电异常查看电池统计发现某个系统服务如mediaserver或system_server的CPU占用很高。排查步骤定位唤醒源使用adb shell dumpsys alarm或adb shell dumpsys jobscheduler检查是否有异常的定时任务。关联CPU占用找到可疑服务后用top或ps获取其PID。深入线程级通过adb shell ps -T -p PID列出该进程所有线程再用adb shell top -H -d 2 -p PID观察是哪个线程在持续运行。查看线程状态与核心结合/proc/PID/task/TID/stat可以查看线程的状态S睡眠、R运行等和最近运行的CPU编号processor字段。如果发现某个线程频繁从睡眠S进入运行R并且总是在某个核心上被调度可能就是它在不断被唤醒。分析唤醒链此时可以进一步使用systrace或perfetto工具进行跟踪查看该线程被唤醒的调用栈定位到底是哪个驱动、哪个定时器或哪个其他进程的Binder调用在唤醒它。这个过程中CPU核心相关的命令/proc/stat,top -H,/proc/*/stat帮助我们完成了从“进程耗电”到“具体哪个线程在哪个核心上异常运行”的精准定位。4. 常见问题、避坑技巧与脚本化实践在实际操作中你肯定会遇到各种预料之外的情况。下面分享一些我踩过的坑和总结的技巧。4.1 权限问题与解决方案这是新手遇到的第一道坎。很多/sys下的节点需要root权限才能写入修改频率、开关核心。没有Root权限怎么办使用调试版本或工程机在开发阶段尽量使用userdebug版本的Android系统或工程样机它们通常默认带有root权限通过adb root获取。利用Android平台工具部分信息可以通过dumpsys命令获取例如adb shell dumpsys cpuinfo能提供进程级的CPU占用摘要无需root。使用性能剖析工具systrace/perfetto在非root设备上也能捕获详细的CPU调度和频率信息它们是更高级、更图形化的分析手段。申请厂商接口对于手机厂商的工程师可以使用内部提供的、签名权限的API或HIDL/I接口来间接控制CPU策略。adb root失败或显示adbd cannot run as root in production builds这说明你设备上的Android是user用户版本adbd守护进程没有以root权限运行。这是零售机的正常安全限制。除了刷机为userdebug版本几乎没有其他办法绕过。此时你的操作应仅限于读取操作cat和部分无需root的监控。4.2 数据解读的陷阱/proc/stat的累计值它显示的是从开机以来的总时间。直接看数字没有意义必须计算时间差才能得到一段时间内的使用率。很多人在这里犯错。频率不等于性能scaling_cur_freq显示的是当前频率但CPU的实际算力还受到架构、缓存、内存带宽、温度是否降频等多重影响。一个A78核心在2.0GHz下的性能远高于A55核心在2.0GHz下的性能。不能单纯用频率比较不同核心甚至不同芯片的性能。online状态与调度器将一个核心设为offline后Linux调度器会完全忽略它。但有时你发现核心显示online1负载却一直为0。这可能是因为该核心被cpusetcgroup排除在了某个进程组的允许集合之外或者系统负载低调度器觉得没必要往上面放任务。4.3 实用脚本片段手动敲命令效率太低这里提供几个实用的Shell脚本片段可以保存为.sh文件通过adb shell sh script.sh运行或者直接在adb shell环境下逐行执行。1. 实时监控各核心频率与负载1秒刷新#!/system/bin/sh while true; do clear echo “ CPU Frequency (MHz) ” for cpu in /sys/devices/system/cpu/cpu[0-9]*; do if [ -e “$cpu/cpufreq/scaling_cur_freq” ]; then freq$(cat $cpu/cpufreq/scaling_cur_freq) echo “${cpu##*/}: $((freq / 1000))” fi done echo -e “\n CPU Load (approx %) ” # 第一次采样 for i in 0 1 2 3 4 5 6 7; do if [ -e “/sys/devices/system/cpu/cpu$i/online” ] [ “$(cat /sys/devices/system/cpu/cpu$i/online)” -eq “0” ]; then continue fi stat1$(grep “^cpu$i “ /proc/stat) u1$(echo $stat1 | awk ‘{print $2$3$4$5$6$7$8$9}’) # 总时间 i1$(echo $stat1 | awk ‘{print $5}’) # idle时间 eval “total1_$i$u1” eval “idle1_$i$i1” done sleep 1 # 第二次采样并计算 for i in 0 1 2 3 4 5 6 7; do if [ -e “/sys/devices/system/cpu/cpu$i/online” ] [ “$(cat /sys/devices/system/cpu/cpu$i/online)” -eq “0” ]; then echo “cpu$i: OFFLINE” continue fi stat2$(grep “^cpu$i “ /proc/stat) u2$(echo $stat2 | awk ‘{print $2$3$4$5$6$7$8$9}’) i2$(echo $stat2 | awk ‘{print $5}’) eval “total1\$total1_$i” eval “idle1\$idle1_$i” total_diff$((u2 - total1)) idle_diff$((i2 - idle1)) if [ $total_diff -eq 0 ]; then usage0 else usage$((100 * (total_diff - idle_diff) / total_diff)) fi echo “cpu$i: ${usage}%” done sleep 2 done2. 一键锁定所有核心到最高性能模式需root#!/system/bin/sh for gov in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo “performance” $gov 2/dev/null done for cpu in /sys/devices/system/cpu/cpu*/cpufreq; do max_freq$(cat $cpu/scaling_max_freq) echo $max_freq $cpu/scaling_min_freq 2/dev/null done echo “All CPUs locked to performance governor and max frequency.”3. 检查并打印CPU拓扑信息#!/system/bin/sh echo “CPU Topology:” for cpu in /sys/devices/system/cpu/cpu[0-9]*; do cpu_id${cpu##*/} if [ -f “$cpu/online” ] [ “$(cat $cpu/online)” -eq “0” ]; then echo “$cpu_id: OFFLINE” continue fi pkg_id$(cat $cpu/topology/physical_package_id 2/dev/null) core_siblings$(cat $cpu/topology/core_siblings_list 2/dev/null) echo “$cpu_id - Physical Package: $pkg_id, Siblings: $core_siblings” done将这些脚本灵活组合运用你就能构建出属于自己的、强大的Android CPU性能分析工作流。从宏观状态监控到微观线程绑定这些命令赋予了你透视和干预系统底层行为的能力。掌握它们无疑是向高级Android性能工程师迈进的关键一步。