问题复盘

本文先整理电压采样的方案设计思路，再复盘下面五类电量与充电问题： 电压稳定方案的设计思路 电量曲线 温度采样 上报精度 电量管控 状态刷新 一、电压稳定方案的设计思路 电量计算不会直接使用一次 ADC 采样结果。播放音乐、蓝牙发射和负载切换都会造成短时波动，因此在进入电量估算前，需要先得到一份相对稳定的电压。 这里先分清三个值： 数据 含义 新采样电压 ADC 本次换算得到的电压，每次都可能变化 平均电压 经过滤波后缓慢上升或下降的中间值 稳定电压 达到更新条件后才改变，提供给后续电量算法使用 稳定电压不是手机显示的百分比，也不是永远固定不变。它只是在平均电压没有达到更新条件时保持原值。 方案一：去极值后取平均值 先连续采集一组电压，去掉其中几个最大值和最小值，再对剩余数据求平均。偶发的异常高值和异常低值不会直接影响结果，适合 ADC 容易出现尖峰干扰的场景。 这种方案的优点是抗单点异常能力强，思路也比较直观。缺点是需要保存一组采样数据，还要完成极值查找或排序，会占用更多内存和计算资源。采样窗口越长，结果越稳定，但输出延迟也越大，真实电压发生变化时不容易及时跟上。 方案二：递推平均加更新阈值 递推平均不需要保存整组数据。每得到一个有效采样值，就让原来的平均电压向新采样值移动一小步。新采样值低于旧平均值时向下移动，高于旧平均值时向上移动，每次移动的大小由两者差值和递推系数决定。 这种方案的优点是内存和计算开销小，适合持续采样，也可以通过调整递推系数改变响应速度。缺点是它不会自动剔除异常值，一个突发尖峰会影响后续一段时间；系数过小，电压变化跟得慢，系数过大，又容易把短时波动带进结果。 以递推系数 1/32 为例： 当前平均电压和稳定电压都是 4000mV。 本次新采样电压为 3800mV，与平均电压相差 200mV。 本次只向下移动差值的 1/32，也就是 6.25mV，新的平均电压约为 3993.75mV。 新的平均电压再与稳定电压比较。两者向下相差约 6.25mV，达到当前项目的下降更新条件，稳定电压才更新。 如果旧平均电压低于新采样电压，处理方向相反：旧平均电压加上两者差值的 1/32，得到新的平均电压。无论差值大小，每次采样都会参与递推；更新阈值只负责决定稳定电压是否改变。 当前项目在平均电压下降约 5mV 时允许更新稳定电压，向上则需要变化约 10mV。下降阈值更小，可以及时反映放电趋势；上升阈值更大，可以减少负载解除后电压回弹带来的影响。 对于 TWS 耳机这种电压变化缓慢、需要持续采样的设备，递推平均占用资源少，也方便调整响应速度，当前 SDK 采用的就是第二种方案。如果还会出现明显的异常采样，可以先剔除异常值，再进入递推平均。 二、电量曲线 问题现象 耳机从满电持续播放音乐时，有些 10% 很快掉完，有些区间长时间不变化；左右耳在同一电量区间的续航也可能相差较大。总续航接近要求，但百分比曲线不均匀。 问题原因 这次问题的直接原因是软件仍使用旧电池的电压—电量表，与当前电芯的充放电曲线不匹配，导致各百分比区间对应的实际续航不均匀。左右耳的主从角色还会带来功耗差异，因此双耳验证时也要把主从切换考虑进去。 处理结果 根据当前电芯的实测充放电数据更新电量表，同时调整电量相关的主从切换逻辑。修改后分别在 ANC 开启和关闭场景下完成整轮放电验证，各 10% 区间的续航恢复到要求范围内。 三、温度采样 问题现象 ...

本文围绕下面四类问题，整理对应的现象、问题原因和处理结果： 快速开关盖后异常断连 左右耳回复不一致，盒子灯效频闪 耳机已经进入配对，盒子却不显示配对灯效 配对超时后，盒子显示了错误灯效 一、快速开关盖后异常断连 问题现象 快速开关盖时，耳机低概率断开。日志中没有完整的关盖命令，耳机却进入了充电状态。 问题原因 快速开关盖时，充电盒重新拉起供电。电平持续时间超过原来的防抖阈值，耳机提前判断为稳定入盒。状态切换由充电检测触发，不是串口丢包。 处理结果 将充电电平持续检测时间从约 600 ms 延长到 1 s，避免短暂电平触发充电模式。连续快速开关盖验证后，未再出现异常断连。 二、左右耳回复不一致，盒子灯效频闪 问题现象 耳机进入配对状态并放入盒内后，充电盒白灯闪烁不均匀，部分场景出现频闪或亮度异常。 问题原因 左右耳返回给充电盒的配对状态不一致。盒子先收到一只耳机的配对状态，又收到另一只耳机的非配对状态，灯效状态被反复切换。 左耳回复：配对中 右耳回复：非配对 ↓ 盒子灯效在两个状态之间反复切换 处理结果 由从耳同步主耳的配对状态，确保左右耳向充电盒返回一致的数据。双耳状态一致后，配对灯效恢复正常。 三、耳机进入配对，盒子却不显示配对灯效 问题现象 耳机已经连接一台手机，再进入配对模式并放入盒内。充电盒只显示耳机电量，没有显示配对灯效。 问题原因 耳机同时存在“已连接”和“可发现可连接”两个状态。原来的回复逻辑优先返回已连接状态，覆盖了正在配对的状态，盒子因此没有进入配对灯效。 /* 修改前 */ if (phone_connected()) { report_connected(); } else if (pairing()) { report_pairing(); } /* 修改后 */ if (pairing()) { report_pairing(); } else if (phone_connected()) { report_connected(); } 处理结果 回复状态时优先判断配对状态，再判断手机连接状态。修改后，耳机在已连接状态下重新进入配对，盒子能够正常显示配对灯效。 四、配对超时后，盒子显示了错误灯效 问题现象 耳机在配对状态下入盒，配对超时后，充电盒显示了配对成功灯效，而不是结束灯效。 问题原因 耳机在配对超时后返回无效状态，充电盒却把这个状态按配对成功处理。数据传输正常，但两端对同一状态的含义没有统一。 处理结果 统一耳机与充电盒对回复状态的定义。收到无效状态时直接结束灯效，不再进入配对成功灯效。 这四类问题对应的检查入口是：充电电平、左右耳回复是否一致、状态判断优先级、两端状态定义。

写在开始 这篇文章整理项目中比较有代表性的音量问题单。只保留已经写明原因和处理方向的内容，并按音量控制链路归为三类。 排查音量问题时，可以先确认四个结果： 1. 收到的目标音量是否正确 ↓ 2. 左右耳保存的音量是否一致 ↓ 3. 两耳应用音量的时间是否一致 ↓ 4. 实际写入硬件的音量是否正确 本文围绕下面三类问题，整理对应的现象和排查思路： 回连后的初始音量不对 ； 快速调节时双耳音量不同步 ； 出盒恢复时单耳突然变大 。 一、回连后的初始音量不对 问题现象 1 耳机重新组队并连接手机后，预期使用耳机的默认音量，实际却变成手机之前保存的最大音量。 排查思路 1 按时间确认三个值：重新组队后恢复的默认音量、手机首次下发的历史音量，以及最终实际生效的音量。若默认值恢复正确，但最终值变成手机历史值，说明问题出在手机下发后的覆盖。 耳机重新组队后已恢复到默认音量，但手机连接时下发的历史音量又覆盖了本地值。如果要求重新组队后采用耳机默认音量，可以在首次连接的短暂保护窗口内忽略手机下发的音量，使用耳机的默认音量，同时将默认音量写回给 App。 问题现象 2 一拖二场景下，设备 A 已连接耳机且音量调到最大；设备 B 的音量较小，在播放音乐时抢连耳机。抢连成功后，音乐开始时仍按设备 A 的最大音量播放，随后才突然降到设备 B 的低音量。 排查思路 2 检查抢连后耳机采用的是哪台设备的音量，以及 A2DP 开始播放前硬件音量是否已经更新。 已有问题中，设备 B 抢连成功后，硬件音量设置晚于音乐开始，导致开始播放时仍保留设备 A 的最大音量。处理时要在 A2DP 出声前，按设备 B 的音量设置好硬件音量。 二、快速调节时双耳音量不同步 问题现象 1 长按手机音量键或快速滑动音量条时，声音会短暂偏向一边；从最大音量降到静音时，一只耳机比另一只更晚无声。反复在最大和最小音量之间切换时，还可能出现音量跳变。 排查思路 1 先看手机下发音量后，主从耳是不是在 alarm 到点前就各自更新了本地媒体音量；再对比 alarm 回调里两边实际采用的目标值。 已有问题中，主从耳在 alarm 到点前更新本地媒体音量的路径不同。快速滑动时，虽然两边在同一时刻进入 alarm 回调，但取到的音量基准已经不一致，所以会出现一边先变大、先变小或更晚静音。 ...

写在开始 这篇文章整理项目中比较有代表性的 ANC 问题单，并按问题现象归为五类。 有些问题标题虽然带有 ANC，但最后确认是电量、功耗或连接问题，这里不展开。本文只保留能够放回 ANC 控制链路解释的问题，没有明确结论的地方也不补充猜测。 先把 ANC 控制流程简化成四步： 1. 收到切换请求 ↓ 2. 确定并同步目标模式 ↓ 3. 加载参数，更新实际效果 ↓ 4. 保存状态并上报 App 本文围绕下面五类问题，整理对应的问题现象和排查思路： 实际模式正常，App 显示却不对 ； 单耳和双耳切换后，ANC 状态混乱 ； 按键或 App 操作后，ANC 没有切换 ； 模式切换成功，降噪效果却不对 ； 切换 ANC 时出现杂音、短暂无声或突变 。 一、实际模式正常，App 显示却不对 问题现象 1 从耳长按切换 ANC 后，耳机实际已经切换，App 仍显示原来的模式； 排查思路 1 先确认三个结果：从耳是否识别到长按、左右耳实际模式是否变化、主耳是否向 App 上报了新状态。 如果从耳和两耳实际模式都正常，重点查主耳是否收到新的目标模式、更新本地状态并上报 App。问题单中，从耳已经完成 ANC 切换，但主耳没有更新状态并发送新模式，因此问题出在主耳的状态同步和上报链路。 问题现象 2 耳机实际是高降噪，App 却显示低降噪；重新进入 App 后，等级还会发生跳变。 排查思路 2 对照耳机内部等级、协议值和 App 显示值是否一致。问题单中，耳机使用 1 表示低降噪、3 表示高降噪，App 却映射成1是高降噪，3是低降噪，导致高低等级颠倒。这是状态映射错误，不是 ANC 参数没有生效。 ...

一、本文要解决哪些提示音问题 这篇文章记录的是我对 TWS 耳机提示音问题的整理和理解。我结合问题单、原厂 SDK 以及实际修改点，把零散的问题按现象和根因重新归类，并从业务请求、队列、播放到状态恢复，整理出一套排查思路。 具体问题的修改结论，以问题单和现有代码记录为准；没有明确依据的地方，我不额外延伸。理解提示音问题，可以先把流程分成四步： 1. 业务事件发生 ↓ 2. 提示音请求进入队列 ↓ 3. 提示音开始播放 ↓ 4. 播放结束，恢复音频状态 有些提示音只是给用户提供声音反馈，有些提示音还和业务回调绑定在一起。原厂 SDK 中，ANC 和音乐/游戏模式会在提示音播放完成后更新；接听、拒接和回拨也会在提示音相关回调中触发。 所以排查时不能只看“有没有声音”，还要看对应的业务回调是否按预期执行。遇到问题时，先分清是“声音没有正常播放”，还是“提示音对应的业务动作没有执行”：前者检查资源、音量和播放链路，后者检查业务请求和回调。 本文主要围绕以下 7 类问题展开，后文会分别说明问题现象、原因和排查思路： 业务已经发生，提示音却没响或播错 ； 提示音太大、太小，或换资源后异常 ； 连续或快速操作后，提示音消失、滞后或重复 ； 提示音响错耳朵 ； 双耳提示音不同步，或音乐恢复不同步 ； 提示音响完，音乐却出现杂音或无声 ； 来电和双连接时，响铃状态混乱 。 二、业务已经发生，提示音却没响或播错 问题现象 1 电量已经低于 10%，却没有低电提示音。 排查思路 1 先确认低电条件是否真的触发。比如电量从 11% 直接变成 9% 时，可能跳过“等于 10%”的判断，后面就不会提交低电提示音。确认条件后，再检查代码是否走到提示音调用位置。 问题现象 2 来电双击已经接听，却播放成三击提示音。 排查思路 2 这个问题说明提示音请求已经提交，但事件和提示音没有正确对应。重点检查双击事件最终传入的提示音资源编号，确认是否误用了三击提示音。 这类问题可以按“业务条件、提示音调用、资源编号”的顺序检查。前三步没有问题后，再进入队列和播放流程。 三、提示音太大、太小，或换资源后异常 问题现象 1 通过 App 的“查找耳机”功能播放正常，但在手机设置中的 Google“查找设备”页面，点击“让耳机响铃”时声音偏小。 ...

一、写在开始 我参与的是一款基于中科蓝讯 BT8910 的 TWS 耳机品牌项目，目前这个项目已经完成。 项目结束后，我想把开发过程中接触到的 Jira 问题单重新梳理一遍。其中既有我参与处理的内容，也有同事负责的模块。 现在查一个函数、一个配置项并不难，真正值得记录的是：面对一个问题现象时，应该先判断哪一层，为什么往这个方向查，以及怎么通过日志一步步缩小范围。 所以这次复盘不是给出一套标准答案，而是站在我目前对应用层的理解上，把问题现象、判断过程和排查思路整理下来，供遇到类似问题的同学参考。 整理过程中我还发现，很多反馈看起来不一样，根因却有重复。按根因归类后，下次遇到类似现象时，就可以先判断问题属于哪个环节，再沿对应链路往下查。 后续我会继续按模块整理项目中的问题单，包括按键、提示音、机盒通信、ANC、音量控制、功耗管理、出入盒、双耳同步、蓝牙问题和连接问题等内容。这一篇先从按键开始，归纳其中比较常见的 4 类问题。 阅读提示 全文约 2 300 字，预计 10 分钟读完。 本文包含 4 类按键问题：完全无响应、场景功能错误、误触，以及复杂手势互相干扰。重点不是讲基础原理，而是遇到类似反馈时，应该先查哪里、再往哪里查。 本文只讨论按键链路本身。如果按键已经触发正确功能，只是提示音没有播放或播放不对，就归到后续的提示音问题中。 二、所有手势都没有反应 客户反馈 其中一只耳机的触控按键完全无效，双击、三击、长按都没有反应。 排查思路 第一步：确认触控输入 先看这只耳机的触控按键是否有按下、松开的日志。 没有日志：先查这个触控按键的输入本身，例如触控是否启用、耳机是否在盒内、是否正处于禁键时间、触控阈值或通道是否正常。 有日志：说明这个触控按键已经有输入，继续往下查。 第二步：确认手势识别 再看目标手势有没有识别出来。 没有识别出来：重点查双击间隔、长按时间、松手后状态是否复位，以及组合手势是否把普通手势挡住了。 识别出来：说明手势已经产生，继续看功能。 第三步：确认功能消息 最后看手势有没有转换成正确的功能消息。 没有、为空或错误：查按键定义、场景切换和配置更新。 有正确消息：再确认功能处理是否执行；如果功能已经执行，后面只是没有提示音，就属于提示音问题，不再按按键问题处理。 判断与处理 “完全无效”不一定是触控硬件问题，也可能是手势已经产生、但后面没有正确链接到功能。处理时不要一开始就调灵敏度或改功能定义，先通过日志确认问题停在哪一层。 三、同一手势，功能却错了 客户反馈 听歌时双击正常，来电时双击却不能接听或挂断。 长按在听歌时能切换功能，到响铃或通话时却失效。 App 改完触控后，耳机执行的功能不对。 排查思路 第一步：固定一个场景复现 只测听歌、只测来电响铃，或只测通话，避免混在一起判断。 第二步：确认手势已经识别 如果手势都没出来，回到第一类问题排查。 第三步：核对当前场景的功能 手势正常后，直接看耳机最后想执行的是什么功能。 同样是“双击”：听歌时可能是切歌，来电时应该是接听或拒接，通话中又可能是其他操作。 来电时双击却去切歌：说明双击识别没有问题，只是耳机还在按“听歌时的规则”处理。 只有通话异常：重点检查进入通话后，双击和长按是否已经改成通话时该做的功能。 App 改完才异常：重点检查新设置是否把听歌、来电或通话时的功能改错了。 判断与处理 听歌、来电响铃、通话时都可以识别同一个“双击”或“长按”，但后续要执行的功能并不相同。 这类问题通常是耳机没有按当前使用状态执行对应功能。处理重点是把每种状态下的功能对应关系确认清楚。 四、不该响应时仍然响应 客户反馈 耳机放在盒内还能切歌；刚出盒或拿取耳机时，容易误触切换功能。 排查思路 第一步：确认误触发生的时机 ...