一次 CPU 问题的排查

2021-10-15 约 1565 字预计阅读 4 分钟

前言

最近来了个新环境，做了第一个需求——直播答题。

这边的风格大致就是：先在能使用的库的基础上快速完成需求，整个开发时间大概在2-3周，客户端总共俩人，我主要负责直播间内的业务逻辑。

直播间还是很简易的，没有礼物啊什么的，只有个弹幕聊天。

但是因为后端并没有长链接，所以弹幕、直播人数需要轮训来获取，感觉不太妙。

总之，最后算是很挫的完成了任务吧！

收获是，了解了一些音视频和直播答题的方案(好的方案需要音视频配合，但是需要他们排期，最后用了一个比较挫，但是能用的方案)，还有就是终于用上了 databinding，但是感觉用的很烂，kotlin 依然还是没在真实开发使用，主要这次有点赶，没敢用，下次一定。

但是，最终性能测试没有通过。因为有的设备性能很差，加上系统本身有一些基础服务占用 cpu，性能测试要求 app process cpu < 60%, total cpu < 80%

直播答题的 app 因为有音视频编解码，在最低端的设备上最终 app process cpu 40%, total cpu 80.25%(超标)

那咋办呢？

作为一个合格的工程师，当然是打开了 Google -> Android CPU 过高怎么办

基本就是说用 profiler 或者 adb 命令看一下，但是并没有具体的分析。

我感觉应该分为下面几个步骤：

确定复现场景(哪个页面 cpu 高？哪个场景 cpu 高？)
如果这个找不到，那根本无从查起了，比如我这边就是进入直播间 cpu 占用变高。
场景中有哪些消耗 cpu 的场景？控制变量，进一步缩小范围
比如我的直播间 cpu 过高的话，直播间有轮训的网络请求、动画、播放器，这三个可能会比较耗费 cpu 的东西，分别注释掉其余两个，看看到底是谁的锅？
需要有足够的耐心！
确定到具体的小方面，profiler 查看具体问题
我最终通过注释代码，发现大部分 cpu 是播放器的锅，但是播放器使用的是别的部门的，而且应该也是线上用的，想要给他们反馈 bug，肯定要有十足的证据。

通过前面的方法论，我当时基本确定了问题出现的场景：重新进出直播间，cpu 就会上涨 15% 左右(只上涨一次，只在一批固定低端设备产生问题)

所以，问题也很诡异，一开始反馈给播放器部门，他们尝试复现，结果并没有复现出来。

可是，这个问题不修复，总觉得好像是我不太行，第一个需求就因为 cpu 被卡了，所以只能用 profiler 来慢慢看了。

profiler 的使用就不多说了，android studio 直接使用，attach 到对应进程上就好了。

当时的 cpu 如下图：

Home 页面有一个可以预览的小的 VideoView

home(cpu 20%) -> 其他页面(静态页面 cpu 基本0) -> 返回home(cpu 36%)

具体的分析过程，用了半天左右，怀疑过各种问题

最终只好对比前后的线程数变化，最终发现了一个可疑的线程，然后通过 method tracing 发现了问题，如下图：

当 CPU 上涨的时候，伴随着这个诡异的 APM_TaskQueue 线程的疯狂运行，甚至比主线程还忙，看起来是个循环才会这样。看名字像是个队列，盲猜是一个神奇逻辑导致队列任务过多，执行任务使用的 while(true) 么？然后也永远执行不完?

然后 record 一段时间，打开具体的 tracing 看了一下，包名也是来自播放器提供的一个 jar 包内，似乎是做埋点上报的。

将以上截图发送播放器部门，他们重新出了一个包，说是依赖了这个第三方埋点库，这个库的问题导致的，最终 total cpu = 64%，通过性能测试，问题解决(但是看他们解决的速度，我咋感觉是直接把这个库干掉了？)

cpu 问题现在应该基本遇不到了，只有低端设备才会出现这些问题，都是具体问题具体分析的。

基本就是围绕着 cpu、内存和帧率来看的，这几个有时候会互相影响。

我遇到的这个问题很简单，通过 profiler 就能分析的出，android 的其他的诡异问题可是太多了！令人头秃！

这个项目写完，感觉自己对于 databinding 和 viewmodel 的使用很烂。

看另一个哥们写的就很简洁、灵动。

加油呗！

生日快乐