嵌入式音频卡顿问题分析过程

问题还原

设备存在一路音频播放数据为从网络传入，在项目进行过程中，观察到音频播放存在不流畅的问题。

分析流程

为直接分析是否是修改引起，将项目进行了回滚。通过大量的回滚和测试，最终确定是编译选项增加了 -O3 引起。初步的解决方案就是在最新版本上去掉了 O3 选项，去掉之后音频卡顿问题出现了明显的改善，但是具体是什么原因引起这个问题，没有深究。

但是这个问题并没有就此停止，因为在后续测试过程中，仍然发现音频流播放存在偶尔卡顿的问题。为了解决这个问题，通过分析系统性能主要消耗的线程，定位到了可能的优化点。其中一个是在画面上叠加图层的线程。这个线程主要的性能消耗点包括对图层内存的初始化和叠加，因此初期的主要优化点是通过只擦除掉绘制的部分来避免图层内存的全部初始化，从而降低 CPU 消耗。但是在优化结束后，发现尽管 CPU 使用率降低了，但是音频播放反而出现了较为明显的卡顿问题。

考虑 CPU 占用下降反而出现了音频播放性能不足的问题，猜测性能消耗点可能主要出现在叠加图层的接口调用上。通过一个没有休眠的死循环反复调用图层叠加接口，发现音频几乎不能播放了。这个猜测得到了证实。

为了解决这个问题，考虑到这个问题的主要瓶颈在于内存的拷贝，因此使用了一个直接在图层上绘制的接口（而不是绘制好之后再拷贝进去），经试验，这个解决方案最终使得音频播放的卡顿问题得到了解决。

再分析

为什么会出现上述现象，其实过程还是比较有趣的。

首先，O3 优化确实起到了优化的效果，并且具有非常明显的优化效果。但是 O3 优化仅仅是对未编译的代码进行了优化，使得这些代码里的一些存在优化点的部分的计算量下降，从而直接引起那些负载比较重、优化效果比较明显的线程的运行速度加快。图层叠加线程即是这样一个线程。

图形叠加线程速度加快后，直接后果就是对于叠图接口的调用频率提高。由于系统刚好已经处于瓶颈点了，这一点提升恰好引起了音频播放资源的不足（具体原因不明，可能是内存带宽不足），从而出现了卡顿。