一、本文要解决哪些提示音问题
这篇文章记录的是我对 TWS 耳机提示音问题的整理和理解。我结合问题单、原厂 SDK 以及实际修改点，把零散的问题按现象和根因重新归类，并从业务请求、队列、播放到状态恢复，整理出一套排查思路。
具体问题的修改结论，以问题单和现有代码记录为准；没有明确依据的地方，我不额外延伸。理解提示音问题，可以先把流程分成四步：
1. 业务事件发生
↓
2. 提示音请求进入队列
↓
3. 提示音开始播放
↓
4. 播放结束，恢复音频状态
有些提示音只是给用户提供声音反馈，有些提示音还和业务回调绑定在一起。原厂 SDK 中，ANC 和音乐/游戏模式会在提示音播放完成后更新；接听、拒接和回拨也会在提示音相关回调中触发。
所以排查时不能只看“有没有声音”，还要看对应的业务回调是否按预期执行。遇到问题时，先分清是“声音没有正常播放”，还是“提示音对应的业务动作没有执行”：前者检查资源、音量和播放链路，后者检查业务请求和回调。
本文主要围绕以下 7 类问题展开，后文会分别说明问题现象、原因和排查思路：
- 业务已经发生，提示音却没响或播错 ；
- 提示音太大、太小，或换资源后异常 ；
- 连续或快速操作后，提示音消失、滞后或重复 ；
- 提示音响错耳朵 ；
- 双耳提示音不同步，或音乐恢复不同步 ；
- 提示音响完，音乐却出现杂音或无声 ；
- 来电和双连接时，响铃状态混乱 。
二、业务已经发生，提示音却没响或播错
问题现象 1
电量已经低于 10%，却没有低电提示音。
排查思路 1
先确认低电条件是否真的触发。比如电量从 11% 直接变成 9% 时，可能跳过“等于 10%”的判断，后面就不会提交低电提示音。确认条件后，再检查代码是否走到提示音调用位置。
问题现象 2
来电双击已经接听，却播放成三击提示音。
排查思路 2
这个问题说明提示音请求已经提交，但事件和提示音没有正确对应。重点检查双击事件最终传入的提示音资源编号，确认是否误用了三击提示音。
这类问题可以按“业务条件、提示音调用、资源编号”的顺序检查。前三步没有问题后，再进入队列和播放流程。
三、提示音太大、太小，或换资源后异常
问题现象 1
通过 App 的“查找耳机”功能播放正常，但在手机设置中的 Google“查找设备”页面，点击“让耳机响铃”时声音偏小。
排查思路 1
这个问题中，Google“查找设备”使用了手机提示音的音量，没有和 App 的“查找耳机”使用同一套音量设置。排查时要比较两个入口实际使用的资源和音量来源。
问题现象 2
音乐播放中进入配对，提示音响起时音乐短暂无声。
排查思路 2
问题单 246 中，配对提示音使用 MP3 时，原厂 SDK 会先停止当前音乐，提示音播放结束后再恢复音乐。停止和恢复之间存在一段时间，因此出现了约 2 秒无声。改成 WAV 后，提示音没有走 MP3 分支中的音乐停止和恢复流程，所以这个场景恢复正常。
这里的结论针对当前 SDK 的播放实现，并不是说 MP3 格式本身一定会打断音乐。遇到类似问题时，要重点检查提示音格式对应的播放分支，以及它是否会暂停或停止背景音乐。
问题现象 3
替换提示音文件后，耳机仍然播放旧声音。
排查思路 3
先确认新资源是否成功编译，再确认包含新资源的固件是否真正烧录或升级到设备。前两步没有问题后，再检查提示音编号和资源文件的映射关系。
四、连续或快速操作后，提示音消失、滞后或重复
问题现象 1
快速切换降噪和通透后，提示音越来越滞后，几秒后状态又被切回。
排查思路 1
快速切换 ANC 时，旧提示音可能还没有播放，新请求又进入队列。由于 ANC 状态在提示音结束回调中更新，旧提示音播放完成后可能再次执行旧状态，于是出现提示音滞后或状态回跳。处理时可以在入队前过滤已经过期的同类请求。
问题现象 2
反复接听、挂断几次后，双击和三击仍有效，但没有提示音。
排查思路 2
重点检查队列长度和入队结果。已有问题确认过队列计数只增加、没有正确减少，几次操作后队列被认为已满，后续请求就无法进入。
排查时记录请求、入队、出队、开始播放和结束回调，确认旧请求是否还在队列，以及计数是否成对变化。ANC 这类只需要保留最新状态的提示音，可以过滤旧请求；连接、断连等提示音是否能清理，要按业务设计确认。
五、提示音响错耳朵
问题现象
只双击左耳，左右耳却同时播放触控反馈音。
排查思路
先确认这段提示音是否需要两耳播放。如果不需要，就调用本地播放接口，例如 bsp_res_play_local()，只让操作耳播放，不通知另一只耳机，也不做两耳同步。触控反馈通常就属于这种情况。
只有连接、断连和共同模式变化等需要两耳反馈的提示音，才使用双耳播放和同步流程。出现两边同时响时，先检查播放接口和播放范围是否用错，再检查双耳同步时序。
六、双耳提示音不同步
问题现象 1
回连或来电时，两只耳机都有声音，但一只耳明显先响。
排查思路 1
先通过日志分别记录左右耳提示音实际开始播放的时间，确认两边相差多少。如果时间差比较大，先检查当前使用的同步方式，确认是否已经使用 alarm 级同步。
如果已经使用 alarm 级同步，但仍然偶尔出现明显延迟，就继续检查蓝牙任务、算法或其他任务是否阻塞了提示音准备流程。线程过于繁忙时，一侧可能准备或启动得更晚，导致播放滞后。
问题现象 2
提示音播放后，音乐也是一只耳先恢复。
排查思路 2
这不一定是某一只耳机没有重新打开音乐通路，更可能是两只耳机恢复音乐的时间不同。提示音播放前，耳机要先让音乐暂时让路；提示音结束后，再恢复音乐。如果一只耳机先完成这套流程，就会出现一只耳先恢复的现象。
排查时记录两耳进入音频暂避、开始播放、结束播放和恢复音乐的时间。如果两边都执行了恢复动作，但时间差比较大，就继续检查提示音同步和两耳结束确认。问题单最终确认是提示音不同步导致两耳音频暂避时间不一致，最后音乐恢复不一致，处理方向也是优化提示音同步流程，修复后测试通过。
七、提示音响完，音乐却出现杂音或无声
问题现象 1
连接提示音结束时出现“啪”声。
排查思路 1
重点检查提示音尾部、缓存，以及音频通路关闭的时机。提示音结束时直接关闭通路，可能产生杂音。
问题现象 2
停止查找耳机后，后续音乐一直无声。
排查思路 2
重点检查 DAC（音频输出）、静音和音乐通路是否恢复。已有问题确认过，查找结束后 DAC 没有恢复，会导致后续音乐无声。
问题现象 3
音乐暂停、恢复后，其中一只耳保持无声。
排查思路 3
检查两耳的淡入淡出状态和音频通路是否一致。如果结束后音量不对，还要确认提示音播放期间是否阻塞了正常的音量消息。
原厂 SDK 播放提示音前会保存播放状态、音量、静音和 DAC 状态，结束后再恢复。因此，这类问题要重点检查提示音结束后的恢复过程。
八、来电和双连接时，响铃状态混乱
问题现象 1
电话接通后，耳机仍在响铃，随后单耳或双耳无声。
排查思路 1
按时间顺序检查来电、SCO（通话音频链路）建立、开始响铃、接听、退出响铃和通话音频打开。重点确认 ring（响铃状态）是否退出，以及两耳通话通路是否都打开。
问题现象 2
两台手机先后来电时，手机铃声和耳机本地铃声混在一起。
排查思路 2
分别记录两台手机的来电和 SCO 状态，再确认当前应该播放手机铃声还是耳机本地铃声。这个问题不能只看提示音资源，还要看双连接时的响铃状态切换。
问题现象 3
手机没有及时建立铃声通路时，耳机播放本地铃声。
排查思路 3
手机没有及时建立 SCO 时，耳机回退播放本地铃声可能是设计行为。确认属于正常回退后，不要直接按“提示音播错”处理。
九、最后总结
把提示音问题放回完整链路看，排查顺序可以归纳为：先确认业务请求和资源，再看队列与播放范围；双耳场景重点看同步；提示音结束后，再确认音乐、音频通路和通话状态是否恢复。