综合实战：构建自定义音频策略、实现虚拟音频设备、音频通路监控工具开发、性能调优实战案例

好，到了咱们这门课的最后一章实战了。说实话，前面讲了那么多 AudioFlinger 的机制、策略、路由、混音，都是零散的知识点。今天咱们就把这些东西串起来，真正动手干点活。

我会带你走完四个完整的实战案例：

• 构建自定义音频策略
• 实现一个虚拟音频设备
• 开发音频通路监控工具
• 做一次完整的性能调优

每个案例我都会给出核心思路、关键代码片段，以及我踩过的坑。你跟着走一遍，基本就能把 AudioFlinger 的脉络摸透了。

案例一：构建自定义音频策略

先说说策略。Android 默认的策略文件在 /vendor/etc/audio_policy_configuration.xml 里。但很多时候，默认策略满足不了产品需求。比如，你希望某个 App 播放音乐时强制走蓝牙，而不管当前是否有线耳机插入。

我遇到过这样一个需求：车载系统中，导航语音必须从车载扬声器输出，而媒体音乐可以走蓝牙。默认策略做不到这么细的区分。怎么办？自己写策略。

核心思路

自定义策略的本质，是修改 AudioPolicyManager 的路由决策逻辑。有两种方式：

1. 修改策略配置文件：在 XML 中定义新的 mixPort 和 devicePort 映射关系。
2. 重写策略引擎：继承 AudioPolicyManager，覆盖 getDeviceForStrategy 方法。

我个人更推荐第二种，因为灵活。配置文件改起来容易，但遇到复杂逻辑就捉襟见肘了。

代码示例

// 自定义策略管理器
class CustomAudioPolicyManager : public AudioPolicyManager {
public:
    audio_devices_t getDeviceForStrategy(audio_strategy_t strategy, 
                                          const audio_attributes_t* attributes) override {
        // 如果是导航应用，强制走内置扬声器
        if (attributes && attributes->usage == AUDIO_USAGE_NAVIGATION) {
            return AUDIO_DEVICE_OUT_SPEAKER;
        }
        // 其他情况走默认逻辑
        return AudioPolicyManager::getDeviceForStrategy(strategy, attributes);
    }
};

案例二：实现虚拟音频设备

虚拟音频设备，说白了就是一个假的音频设备。它不连接真实硬件，但 AudioFlinger 认为它是一个真实设备。有什么用？

• 测试场景：在没有硬件的情况下验证音频通路。
• 录音回放：把播放的音频数据抓取出来，供其他模块使用。
• 音频效果验证：在虚拟设备上挂载效果模块，不影响真实输出。

实现步骤

实现一个虚拟设备，需要完成三件事：

1. 在 HAL 层注册一个虚拟设备。
2. 实现 open_output_stream 和 open_input_stream 接口。
3. 在策略配置中声明这个设备。

// 虚拟设备 HAL 实现片段
static ssize_t out_write(struct audio_stream_out *stream, 
                          const void *buffer, size_t bytes) {
    // 把音频数据写入环形缓冲区，供其他模块读取
    ring_buffer_write(g_virtual_buffer, buffer, bytes);
    return bytes;
}

static int out_set_parameters(struct audio_stream_out *stream, 
                               const char *kvpairs) {
    // 解析参数，比如设置虚拟设备的延迟
    ALOGI("Virtual device set params: %s", kvpairs);
    return 0;
}

案例三：音频通路监控工具开发

做音频开发，最头疼的就是不知道音频流到底走了哪条路。是走了扬声器？还是蓝牙？还是 USB？中间有没有被重采样？延迟是多少？

我开发过一个叫 AudioPathMonitor 的工具，专门干这个事。核心原理很简单：

• 监听 AudioPolicyService 的路由变化广播。
• 解析 dumpsys media.audio_policy 的输出。
• 在关键节点打桩，记录音频数据流经的模块。

核心代码

// 监控工具核心逻辑
void AudioPathMonitor::onRoutingChanged(audio_io_handle_t output) {
    // 获取当前输出设备的详细信息
    AudioPolicyInterface::output_desc_t desc;
    mAudioPolicy->getOutputForDevice(output, &desc);
    
    // 记录通路信息
    ALOGI("Audio path: output=%d, device=0x%x, sample_rate=%d, channel_mask=0x%x",
          output, desc.device, desc.sample_rate, desc.channel_mask);
    
    // 如果开启了详细模式，打印整个混音线程的拓扑
    if (mVerbose) {
        dumpMixerThread(output);
    }
}

案例四：性能调优实战

最后说说性能调优。音频性能的核心指标就两个：延迟和卡顿。延迟高了，用户体验差；卡顿多了，用户直接骂娘。

我调优过一个项目，蓝牙播放音乐时总是有 200ms 左右的延迟。排查下来，问题出在缓冲区配置上。

调优步骤

步骤	操作	预期效果
1	检查 audio_policy_configuration.xml 中的缓冲区大小	确认当前配置是否为最优
2	调整 AudioFlinger 的 mNormalFrameCount	减少缓冲区大小，降低延迟
3	提升混音线程的优先级	减少调度延迟
4	启用 fast mixer 路径	绕过重采样，直接输出

// 调整缓冲区大小
// 在 AudioFlinger.cpp 中
mNormalFrameCount = 256;  // 默认通常是 1024，减少到 256 可以降低延迟

// 提升线程优先级
// 在 PlaybackThread::onFirstRef 中
int policy = SCHED_FIFO;
int priority = 2;
sched_setscheduler(thread_id, policy, &priority);

调优结果验证

调优完成后，用 dumpsys media.audio_policy 查看当前的延迟数据：

adb shell dumpsys media.audio_policy | grep -i latency
  Output 12: latency 45 ms  // 调优前是 200ms

嗯，45ms，这个结果还算能接受。如果再想往下压，就得动硬件层面了，比如优化蓝牙协议栈的传输效率。

好了，四个实战案例讲完了。从自定义策略到虚拟设备，从监控工具到性能调优，这些技能你掌握了，基本就能在 AudioFlinger 的世界里横着走了。记住，音频系统没有银弹，每个问题都要结合具体场景去分析。多动手，多踩坑，慢慢就熟了。

---