Oboe音频库中FullDuplexPass回调异常问题分析与解决方案

问题背景

在Android音频开发中使用Oboe库时，开发人员可能会遇到一个典型的崩溃问题。该问题通常发生在直播过程中突然拔掉耳机时，系统会立即停止Oboe的直播流，随后导致应用崩溃。崩溃日志显示异常发生在libc++_shared.so的abort_message函数中，调用栈追溯到FullDuplexPass::onBothStreamsReady回调函数。

技术分析

崩溃原因定位

通过分析崩溃堆栈，我们可以清晰地看到问题发生的路径：

1. 音频流准备就绪时触发onAudioReady回调
2. 通过fireDataCallback传递音频数据
3. 最终在FullDuplexPass::callBack函数中抛出异常
4. JNI异常检查失败导致abort

核心问题出现在FullDuplexPass类的回调处理中，特别是在设备突然断开（如拔掉耳机）时，音频流状态发生变化，而代码没有正确处理这种异常情况。

深层原因

进一步分析发现，这个问题涉及几个关键因素：

1. JNI环境管理：崩溃日志中显示uc::jni::exception_check()失败，表明存在JNI环境问题
2. 资源竞争：音频流关闭与回调执行之间存在时序竞争
3. 异常处理不完善：onErrorBeforeClose和onErrorAfterClose等错误回调没有正确处理

解决方案

1. 使用智能指针管理音频流

建议使用shared_ptr来管理音频流对象，这可以有效防止因对象提前释放而导致的竞争条件：

std::shared_ptr<oboe::AudioStream> inputStream;
std::shared_ptr<oboe::AudioStream> outputStream;

2. 完善错误回调处理

实现并正确处理以下关键回调函数：

void onErrorBeforeClose(oboe::AudioStream* stream, oboe::Result error) {
    // 处理流关闭前的错误
}

void onErrorAfterClose(oboe::AudioStream* stream, oboe::Result error) {
    // 处理流关闭后的错误
}

3. JNI环境安全处理

确保在JNI回调中正确处理异常情况：

void callback(void* audioData, int32_t numFrames) {
    JNIEnv* env = ...; // 正确获取JNI环境
    if (env->ExceptionCheck()) {
        env->ExceptionClear();
        // 执行错误处理逻辑
        return;
    }
    // 正常处理逻辑
}

4. 资源释放时序控制

确保在销毁JNI环境前，先安全停止所有音频流并等待回调完成：

void releaseResources() {
    // 1. 先停止音频流
    if (stream) {
        stream->requestStop();
        stream->close();
    }
    
    // 2. 等待所有回调完成
    // ...
    
    // 3. 最后释放JNI资源
    // ...
}

最佳实践建议

1. 状态监控：实现音频流状态监控机制，及时检测设备断开等异常情况
2. 异步处理：将音频处理逻辑放在独立线程，避免阻塞主线程
3. 资源隔离：确保音频处理资源与JNI环境生命周期分离
4. 日志记录：在关键回调函数中添加详细日志，便于问题追踪

总结