Oboe项目中OpenSL ES音频录制回调崩溃问题分析

问题背景

在Android音频开发中，Oboe是一个重要的跨平台音频库，它封装了AAudio和OpenSL ES两种音频API。近期在Android 10系统上发现了一个与OpenSL ES音频录制相关的崩溃问题，该问题发生在音频录制回调过程中，导致应用崩溃。

崩溃现象分析

从崩溃堆栈来看，问题发生在CallbackProtector::enterCbIfOk方法中，具体表现为访问了一个无效的内存地址0x55555555555565。这个地址实际上是mLock成员变量的位置，表明该对象已经被释放。

深入分析代码逻辑，发现问题源于以下时序竞争：

1. 音频录制线程正在执行回调函数audioRecorder_callback
2. 回调函数中调用了enterCbIfOk检查回调保护
3. 在检查protector != 0通过后，另一个线程同时调用了android_audioRecorder_destroy
4. 销毁函数释放了mCallbackProtector资源
5. 回调线程继续执行enterCb方法时访问了已释放的mLock

根本原因

问题的根本原因在于enterCbIfOk方法使用了sp<CallbackProtector>&引用参数，这种设计无法保证回调保护对象的生命周期。当销毁函数释放资源时，引用参数无法阻止对象的销毁，导致后续访问已释放内存。

解决方案探讨

针对这个问题，技术团队提出了几种可能的解决方案：

1. 使用弱引用(wp)替代强引用：将参数类型改为wp<CallbackProtector>，这样可以安全地检查对象是否仍然有效。但这种方法可能引入额外的性能开销。

2. 强制等待回调完成：在销毁音频录制对象前，显式调用stopAndJoinCallbacks方法，确保所有回调都已完成执行。这种方法更安全可靠，但需要充分测试。

3. 重构资源管理逻辑：避免显式调用析构函数，采用更安全的资源管理方式。

技术建议

对于开发者而言，有以下建议：

1. 优先使用AAudio：在Android 9及以上版本，建议优先使用AAudio API，它比OpenSL ES更现代且性能更好。

2. 注意线程安全问题：在音频回调中处理资源时要特别小心，确保资源的生命周期管理。

3. 全面测试：任何音频相关的修改都需要在各种设备和场景下充分测试。

问题修复

Google内部已经修复了这个问题（CL ag/28998374），主要采用了更安全的资源管理方式。对于开发者来说，升级到最新版本的Oboe库可以避免这个问题。

这个案例提醒我们，在音频开发中，回调安全和资源生命周期管理是需要特别关注的重点问题。