我在一个Android apps中使用openSL ES。当应用程序处于前台时，回调是非常有规律的。麦克风回拨大约每10ms调用一次，扬声器回拨也是如此。然而，如果我把我的应用程序放在后台，打开一个浏览器（或另一个应用程序），我会看到打开浏览器（或浏览）时会触发一场回调"风暴"。有办法绕过这个吗？为什么会发生这种情况？openSL是否补偿了它无法执行回调的一段时间？（好像它在努力追赶）。
我的源代码在C中，我在Jelly Bean 4.3. 中
我已经尝试过增加AudioTrack和AudioRecorder的线程优先级，这似乎确实有帮助，但我不确定这是怎么回事。
其他问题
所以你的意思是，即使增加了线程优先级，你也可能会得到一系列回调，你应该放弃这些回调吗？
这怎么是一个好的解决方案？你会丢失麦克风数据包（或耗尽扬声器数据包的来源），对吧？如果你不丢弃麦克风包，麦克风包的接收器会将麦克风包的突发解释为过度抖动，对吧？
更重要的是：我手动增加了AudioTrack和AudioRecorder的线程优先级，并将sched策略更改为循环。它需要根访问和安装BusyBox（它附带了一个用于更改线程优先级/sched策略的命令行util）。这是如何用C程序实现的？我想确保增加的是单个线程的优先级，而不仅仅是我的应用程序（进程）的优先级。
是的，这是设计的。试图提高线程优先级是解决问题的合法方法。确保使用本机缓冲区大小和采样（请参阅Android上的低延迟音频播放）以获得最佳效果。你仍然应该准备好放弃突然的回调，因为没有办法保证它们永远不会发生。当你的应用程序处于后台时，你还应该尽量减少它的整体CPU消耗和RAM足迹。