记录一次排查Android App启动时偶现卡顿问题的过程
背景
最近开发了一个在Rk 3588上跑的app，其中集成了很多其他部门开发的模块，提测时，发现app启动后会有10~20s左右的卡顿问题，主要是app输出计算结果较慢，帧率浮动比较大。
排查工具
- Android Studio Profiler(2024.3.1) ；
- vmstat ；
- iptop
排查步骤
- 应用Android Studio Profiler的
Capture System Activities和View Live Telemetry工具查看CPU、各个线程的运行情况。发现CPU并没有在高负载的运行，内存的使用情况也还好，反倒是有某些线程经常处于wait的状态。看到这个结果，就怀疑是IO阻塞导致的线程wait ； - 为了验证步骤1的结论，应用vmstat查看系统运行情况，发现cpu的wa列有异常(wa 表示CPU在等待IO完成的时间占比)，我这里是4%~9%浮动，帧率稳定的时候基本维持在0%，再查看procs的b列发现b=1(b=1: 1个进程在等待IO，就是我的app进程) ；
- 通过1和2基本已经确定IO问题了，IO问题多数是磁盘IO问题了。不过又用iptop工具进一步排查了一下。发现IO项对应app的进程确实有变化(IO: IO等待时间百分比)
- 想用iostat了，我的3588上没这个工具，也懒着安装了。
经验总结
- 该问题的定位还是挺迅速的，为了确认并排除这个问题，我特意将应用层的写日志操作给屏蔽了，但是发现问题没有得到改善，这就有点违反直觉了，这通常可能是第三方库在偷偷的读写磁盘。不巧的是，领导来了解情况，他提出通过注释大法来排查问题，其实我很抵触这种方式的，这相当于没有找到问题的根本，用最笨的方式来暴力排查。无奈，一言堂的职场环境，只能硬着头皮照做了，算是有个交代吧，结果浪费了好几天，问题依然没有解决。因为屎山一样的代码，二分法的注释，软件经常就跑不起来了......好在最后发现确实是算法库的大量cout引起的(本来cout没啥问题，但是好巧不巧，cout被重定向到磁盘文件上了，然后疯狂占用磁盘IO)
- 最后再次通过上述方法步骤，又走了一遍验证流程，确定了问题所在，也算是总结了一个经验案例。