有现场
adb shell进入系统:
在命令行连续输出进程top10 cpu占用的线程:
top -H -b -d 1 -m 10 -p 6008,10003,4765 > /data/local/tmp/top.txt
(top -H -b -d 1 -m 10 -p `pidof android.hardware.audio.service`)
在命令行连续输出 cpu占用的进程:
top -b -d 1 -m 10 > /data/local/tmp/top.txt
压测的推荐方式:每天版本要用monkey压测,monkey脚本中集成上述命令持续抓取进程cpu占用,如果发现进程cpu占用超过阈值,就抓取这个进程的线程cpu占用,生成一张cpu变化的趋势图,通过人工或者代码识别出超过标准的进程
没现场
线上场景,没有脚手架,出现了bug,如何判断cpu是否正常呢?
业界有的新建一个native守护进程system_monitord,定期读取top cpu占用率的进程。system_monitord进程是一个Android的native进程,在init.rc启动时启动起来,每隔一段时间从"/proc/stat"获取CPU total使用率,再从"/proc/pid/cmdline"读取每个进程的cpu使用率。
计算后写到Android log文件中
system_monitord进程的详细介绍
- 1,可以为指定进程设置cpu监控阈值,如超过了阈值就生成一个cpu_overload文件记录下当前进程各个线程调用栈(adb shell debuggerd -j pid),并抓取simplerperf分析进程哪些线程在做哪些事情,哪些线程最繁忙
- 2,可以为进程指定1个max cpu阈值,连续超过了一定次数就认定为cpu跑飞,在合适场景会强制重启进程。并生成cpu_fly文件记录下当前进程各个线程调用栈(adb shell debuggerd -j pid),并且抓simplerperf和systrace
simplerperf和systrace的分析技巧,以及遇到实际bug如何分析在下一篇文章介绍,敬请期待!
感谢您抽出宝贵时间读完本文,希望您有收获,能不能动动小手指给完❤再走?