第5章音频策略规则引擎

课程目录第5章音频策略规则引擎

5、音频策略规则引擎：规则定义与优先级、策略规则匹配流程、自定义策略规则实战

音频策略规则引擎，说白了就是Android系统里那个决定「声音从哪出」的大脑。你插上耳机，声音自动切过去；拔掉耳机，声音又回到扬声器。这背后就是规则引擎在干活。

我刚开始接触这部分时，觉得不就是个if-else嘛。后来被坑了几次才发现，这里面的门道比想象中深得多。今天咱们就把这个引擎拆开看看。

5.1 规则定义与优先级

规则引擎的核心，是一堆预先定义好的策略规则。每条规则都包含两部分：条件和动作。

条件就是「什么情况下触发」，比如：

设备类型：耳机、蓝牙A2DP、USB声卡、HDMI
设备状态：已连接、已断开、正在使用
音频流类型：音乐、通话、导航、铃声
应用包名：某些App有特殊路由需求

动作就是「触发后干什么」，比如：

将音频路由到指定设备
改变音量
启用/禁用某个音频效果

关键点：规则是有优先级的。高优先级规则会覆盖低优先级规则。这个优先级机制，是规则引擎最容易被忽视但又最容易出问题的地方。

优先级怎么定？我见过的大多数系统都采用数值越小优先级越高的方式。比如：

优先级	规则描述	典型场景
1	强制路由规则	通话必须走听筒或蓝牙耳机
2	用户偏好规则	用户手动选择了蓝牙音箱
3	设备连接规则	插入耳机自动切换
4	默认路由规则	没有其他规则时走扬声器

嗯，这里要注意：优先级不是死的。不同厂商、不同Android版本可能会有调整。我曾在某个项目中遇到过，厂商把「通话强制路由」的优先级设得比「用户手动选择」还低，结果用户选了蓝牙音箱后，一来电话声音还是从听筒出来，用户直接炸了。

5.2 策略规则匹配流程

规则匹配的流程，我习惯把它分成三步：

收集当前状态：系统把所有音频设备的状态、当前运行的App、音频流类型等信息收集起来
遍历规则列表：按优先级从高到低遍历所有规则
执行匹配规则：找到第一条匹配的规则，执行它定义的动作

为什么会这样设计？你想想看，如果同时有两条规则都匹配了，到底听谁的？所以规则引擎采用「先匹配先服务」的策略，一旦找到匹配的规则，就不再往下找了。

我画了一张流程图，帮你理解这个过程：

这个流程看起来简单，但实际实现时有很多细节。比如「收集当前状态」这一步，设备状态是动态变化的，你收集到的信息可能下一秒就变了。所以规则引擎通常会在状态变化时重新触发匹配流程。

小技巧：调试规则匹配时，我习惯在关键节点加日志，打印出「当前匹配到的规则ID」和「执行的动作」。这样一旦路由不对，一眼就能看出是哪条规则在作怪。

5.3 自定义策略规则实战

理论说完了，咱们来点实战。假设你接到一个需求：某个直播App，用户戴上蓝牙耳机后，声音要从蓝牙走；但如果是普通有线耳机，声音还是从扬声器出。这个需求听起来有点怪，但客户最大嘛。

要实现这个，你得自定义一条策略规则。在Android里，策略规则通常定义在audio_policy_configuration.xml或类似的配置文件中。不过直接改系统配置风险太大，我建议用动态规则注入的方式。

下面是一个简化版的代码示例，演示如何通过AudioManager的API来模拟自定义规则：

// 伪代码：自定义策略规则引擎
class CustomAudioPolicyEngine {
    
    // 规则列表，按优先级排序
    private val rules = mutableListOf<AudioPolicyRule>()
    
    fun addRule(rule: AudioPolicyRule) {
        rules.add(rule)
        // 按优先级排序，数值越小优先级越高
        rules.sortBy { it.priority }
    }
    
    fun matchAndExecute(context: Context, audioStream: AudioStreamInfo) {
        for (rule in rules) {
            if (rule.matches(audioStream)) {
                Log.d("CustomPolicy", "匹配到规则: ${rule.name}")
                rule.execute(context, audioStream)
                return  // 只执行第一条匹配的规则
            }
        }
        // 没有匹配的规则，走默认路由
        Log.d("CustomPolicy", "未匹配到规则，走默认路由")
    }
}

// 自定义规则：直播App + 蓝牙耳机 → 路由到蓝牙
class LiveStreamBluetoothRule : AudioPolicyRule {
    override val priority = 1  // 高优先级
    override val name = "直播蓝牙规则"
    
    override fun matches(stream: AudioStreamInfo): Boolean {
        // 条件1：是直播App
        val isLiveApp = stream.packageName == "com.example.liveapp"
        // 条件2：蓝牙耳机已连接
        val isBluetoothConnected = checkBluetoothConnected()
        return isLiveApp && isBluetoothConnected
    }
    
    override fun execute(context: Context, stream: AudioStreamInfo) {
        // 动作：将音频路由到蓝牙设备
        val audioManager = context.getSystemService(Context.AUDIO_SERVICE) as AudioManager
        audioManager.setDeviceForStream(
            AudioManager.STREAM_MUSIC,
            AudioDeviceInfo.TYPE_BLUETOOTH_A2DP
        )
    }
    
    private fun checkBluetoothConnected(): Boolean {
        // 实际项目中需要查询蓝牙适配器状态
        return true  // 简化处理
    }
}

注意：上面的代码是简化示例，实际Android系统中，策略规则的注入需要系统级权限，普通App无法直接调用setDeviceForStream。如果你是在做系统开发，可以通过AudioPolicy类的setDeviceForStrategy方法来实现。

我曾经在一个车载项目中，需要实现「导航语音走主驾头枕音箱，音乐走全车喇叭」的奇葩需求。当时就是用类似上面的方式，自定义了一条策略规则，优先级设得比默认规则高。调试时发现一个问题：导航语音和音乐同时播放时，规则引擎只匹配了第一条规则，导致音乐没声音了。

后来怎么解决的？我把规则改成了「按音频流类型分别匹配」，而不是「匹配一条就退出」。说白了，就是让规则引擎能同时处理多个音频流，每个流独立匹配规则。这个改动虽然不大，但涉及到底层路由策略的重构，折腾了我整整两天。

所以啊，自定义策略规则时，一定要想清楚你的规则是「全局覆盖」还是「按流独立」。这两者的实现难度和影响范围完全不同。

5.4 避坑指南

最后分享几个我踩过的坑：

优先级冲突：两条规则优先级相同怎么办？系统通常按规则添加顺序决定，但不同厂商实现可能不同。我建议明确约定优先级数值，不要出现相同值。
状态同步延迟：设备连接状态变化到规则引擎感知到，中间可能有几百毫秒的延迟。如果你发现规则没生效，先检查状态是否已经更新。
规则数量过多：规则太多会影响匹配性能。我见过一个项目里塞了50多条规则，每次匹配都要遍历一遍，导致音频切换有明显卡顿。建议控制在10条以内。

我曾经在一个项目中，因为规则优先级没理清楚，导致用户插上耳机后声音时断时续。查了两天才发现，是一条低优先级的规则在耳机连接后还在不断尝试把声音切回扬声器，和高优先级规则打架。从那以后，我每次设计规则引擎，都会先画一张优先级表格，贴在墙上天天看。

好了，规则引擎的核心内容就这些。记住一句话：规则是死的，场景是活的。理解规则引擎的原理，比背下所有API更重要。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

5、音频策略规则引擎：规则定义与优先级、策略规则匹配流程、自定义策略规则实战

5.1 规则定义与优先级

5.2 策略规则匹配流程

5.3 自定义策略规则实战

5.4 避坑指南