先聊个现象我们平时在便利店、水果摊、奶茶店听到的那句“收款到账XX元”听起来只是一句话背后其实是一个很小的语音播报组件。这个组件看着不起眼真到动手做的时候坑却一个接一个。做 Saa 类收银、门店管理系统、自助设备、充电桩这类项目时几乎都会遇到同样的需求收一笔钱就要让设备“开口说话”。我最近完整做了一个类似收款到账语音提示的组件 VoiceBroadcast从需求梳理、方案选型到多端适配都走了一遍这一篇就是完整的复盘适合正在做支付回调播报、叫号提示、设备语音反馈的开发者参考也可以直接拿去做技术方案评审或接入落地。1. 先把场景收拢这个组件到底在替谁干活1.1 看起来需要语音播报的地方其实不只是收银语音播报组件最容易想到的场景是线下商家收款。店主在忙的时候经常眼睛不看手机或收银屏幕如果每笔款都要低头确认效率很低漏单风险也高。所以收款到账的语音提示是刚需。但如果只盯着这个场景做设计出来的组件大概率是偏科。我梳理了一下实际项目里需要语音播报的场景至少有这么几类门店收银与聚合收款到账金额、支付渠道、退款、优惠券核销后都需要语音反馈。自助设备自助售货机、充电桩、自助借还书柜。这类设备没有专人值守用户操作成功或失败后要“开口说话”。取餐叫号与排队系统后厨噪音大且后厨工作人员不便靠近屏幕语音播报订单号或取餐号是最直接的方案。后台作业仓库配料、快递分拣、园区摆渡车调度。现场工作人员戴手套、手持扫码枪不方便掏手机看通知语音就是唯一可靠的信息通道。硬件联动播报小票打印机自带喇叭、云喇叭、收款音箱。这些硬件本质上是“把播报能力物理化”。把这些场景放在一起看需求就不再是“播放一段音效”这么简单了。它的本质是把系统里产生的事件转成一段清晰、可靠、不吵人、不遗漏的语音信息并在各种设备条件下准时送达给正在忙的人。1.2 从场景倒推出来的硬性需求清单把所有场景的需求列成清单很多模糊的设计决策会变清晰。我的组件需求清单是这么几条低延迟从支付回调或订单事件发生到扬声器出声感知延迟应控制在几百毫秒内。用户侧的感受是“刚付完就报出来了”如果超过 1 秒体验就很拖沓。离线可用商家门店 Wi-Fi 质量参差不齐收款那一刻网络未必顺畅。若播报依赖云端 TTS断网时就会“失声”这是绝对无法接受的。多端覆盖同一个组件的逻辑要能跑在 Android、iOS、Web 以及部分嵌入式设备上。不能只在某一平台上写死。队列串行多条消息可能同时到达比如会员充值时同时触发到账播报和积分提示需要按优先级排队逐条播报不能叠音。音量可控但不过载播报声音要能在嘈杂环境下听清但又不能刺耳。直播间、夜间门店、办公室场景对音量舒适度要求完全不同。低资源占用不能为了播一句话就常驻一个几百兆的语音引擎。这张清单直接决定了技术选型的方向。下面展开讲方案是怎么定的。2. 技术选型为什么我没有直接塞一个现成 SDK 了事2.1 三种“出声”方案的分岔路口实现语音播报本质上就是把文字变成声音。市面上大体有三条路在线云合成、离线端侧引擎、预录音频拼接。这三条路不是互斥的但很多人一上来就选第一条结果被网络和费用绑架。先看在线云合成。像常见的云厂商语音合成接口输入文本返回 MP3 或 PCM 音频。优点是音色自然、支持多音色和多语言缺点是依赖网络请求且接口通常要鉴权、要计费、可能限流。对于支付播报这种高实时、高频次、偶发断网场景把核心链路压在云端风险太高。云端合成只适合做“增强音色”的可选能力不能当主力。再看离线端侧引擎。现在很多端侧 SDK 可以本地合成语音音色比早期那种机械音好很多支持离线、延迟低。缺点是引擎体积通常较大有的要二三十 MB 甚至更大而且不少离线引擎有授权费、只提供特定 SDK 格式对多端适配不够灵活。如果项目只需要播报固定模板比如“收款到账XX元”“取餐号XX号”让一个完整 TTS 引擎常驻内存性价比不高。最后是预录音频拼接。把可能出现的语音片段提前录好例如“收款到账”“元”“角”“分”“支付宝”“微信”“XX号”播报时按文案顺序拼接。这种做法延迟极低、彻底离线、内存占用小适合模板固定、组合有限的场景。缺点是文案一旦出现模板之外的字词比如自定义店铺名、客户昵称拼接就失效了。我的最终方案是“模板拼接为主、端侧 TTS 兜底、云端 TTS 可选增强”三者组合。严格来说VoiceBroadcast 不是一个纯播放器而是一个“播报策略调度中心”。2.2 现成 SDK 与自研组件的边界做选择之前我也认真对比过“直接买现成的语音播报 SDK”。现成 SDK 的优势很明显开发量小、稳定、不用操心后台保活和音频焦点这些细节。但它的问题往往在使用一段时间后才暴露封闭性播报文案结构、音量调节策略、队列优先级很难按自己的业务定制。体积与依赖为了一个小功能引入整套推送和账号体系合规和包体积都不太划算。端侧适配黑盒Android 各厂商系统行为差异很大现成 SDK 常驻后台被杀、AudioFocus 抢占异常这类问题出了问题只能提工单无法自查。成本线性上涨有的按设备数、按调用次数收费业务增长的同时成本跟着走不够透明。我自己的判断是如果业务只是“临时接个播报”用现成 SDK 最稳妥但如果这个组件要进自己的核心收银链路、要考虑千万级设备的成本就必须自研一套。VoiceBroadcast 的定位是后者一套可以嵌入自己业务系统的播报基础组件。三类方案对比我整理成一张表方便选型时直接对照维度在线云合成离线端侧引擎预录音频拼接延迟高200ms-1s低极低网络依赖强依赖无无音色自然度高中高中取决于实录包体积影响小大极小可扩展文案强强弱单位成本按调用计费授权费一次性录制成本适合场景多语言/个性化通用文本播报固定模板高频播报2.3 整体架构长什么样VoiceBroadcast 的模块划分上我参考了消息队列的思路但做了很多“小而轻”的取舍。整体分成四层触发层接收支付回调、订单事件、推送消息统一转换成内部播报消息。调度层维护一个串行播报队列管理优先级、去重、丢弃策略并推送消息给合成层。合成层按文案类型选择拼接或 TTS 合成输出 PCM/WAV 音频数据。播放层负责 AudioFocus 申请、音量控制、播放器实例管理以及多端播放器适配。这样分层的核心好处是每一层的替换成本都很低。以后想换更好的 TTS 通过替换合成层实现想接入新的硬件喇叭重写播放层即可。调度层保持无状态天然支持多线程调用。3. 核心模块设计与实现从消息到出声3.1 播报消息的标准化所有进入 VoiceBroadcast 的事件先要做一次“格式化”。这一步很关键它决定了后面所有层能不能稳定工作。我定义的消息结构大概是这样的public class BroadcastMessage { private String id; // 消息唯一ID用于去重 private int priority; // 优先级数值越大越先播 private String templateId; // 模板ID如“收款到账” private MapString, String params; // 模板参数如金额12.34 private String fallbackText; // 兜底纯文本模板无法覆盖时用 TTS private long expireAt; // 过期时间超时未播则丢弃 private BroadcastCallback callback; // 播报完成回调用于业务联动 }为什么不用一个简单的 String 直接传因为业务方调用时往往只知道自己有什么数据不知道该怎么组织语音文案。比如支付回调里可能是 amount1200单位分我这边统一负责把 1200 转成“十二元”并拼进“收款到账十二元”。这样调用方只需要传结构化参数文案规范和播报风格都收敛在组件内部不会出现各端各写一套文案的乱象。另外消息必须带优先级。在自助设备上“故障告警”和“收款到账”同时发生时肯定是故障告警先播就算它晚到也要插队。优先级从低到高我分了 INFO、NORMAL、URGENT、CRITICAL 四级调度层根据优先级和到达时间共同决定插队策略。3.2 串行播放队列与状态机音频播放和 UI 一样最怕并发。如果两条播报消息同时到达而不加控制就会出现“收款到账十元收款到账二十元”叠在一起两个声音糊成一片用户什么都听不清。语音播报必须是串行的一条播完再播下一条。我实现了一个基于状态机的串行播放器核心状态是 IDLE、PREPARING、PLAYING、WAITING_STOP。队列用一个线程安全的阻塞队列承接消息播放线程串行消费。因为语音播报本身的时长很短一般 2 到 5 秒单线程处理完全够用还省掉了锁竞争和并发调度的复杂度。核心代码示意如下class SpeechPlayer(private val synthesizer: SpeechSynthesizer) { private val queue PriorityBlockingQueueBroadcastMessage() private val executor Executors.newSingleThreadExecutor { r - Thread(r, voice-broadcast-worker).apply { isDaemon true } } fun enqueue(message: BroadcastMessage) { queue.offer(message) } fun start() { executor.execute { while (isRunning) { val msg queue.take() playSafely(msg) } } } private fun playSafely(msg: BroadcastMessage) { try { val audioData synthesizer.synthesize(msg) playbackHandler.play(audioData, volume msg.priority.volumeLevel) } catch (e: Exception) { // 单条消息异常不能拖垮整个队列记录后继续 Logger.e(play message failed: ${msg.id}, e) } } }这里有一个细节PriorityBlockingQueue 在优先级相同时不保证先进先出所以入队时要给每条消息一个自增序号优先级相同时序号小的先出队。否则用户会听到偶尔乱序的情况。3.3 合成策略先拼后合成减少不必要的 TTS 调用合成层的核心策略是“能不 TTS 就不 TTS”。因为支付播报的文案高度模板化绝大多数情况下不需要完整 TTS 翻译只需要拼接。拿“收款到账12.34元”举例。我先把这个文案拆成几段固定前缀“收款到账”预录音频整数金额“十二”预录音频或数字分段小数点“点”预录音频小数金额“三四”预录音频单位“元”预录音频这里的难点是金额转中文读法。数字不是简单从左到右读要处理“零”的问题。比如 1024 读“一千零二十四”1200 读“一千二百”12.04 读“十二点零四”读法的规则其实不少。我实现了一个金额朗读转换器专门处理整数位、小数位、连续的零、角分单位并且针对支付场景做了两套模式简洁模式12.34 读作“十二块三毛四”适合门店日常收款。标准模式12.34 读作“十二点三四元”适合金额精确展示或财务场景。两种模式可以运行时切换但必须保证同一笔播报过程内一致不能前半句用简洁后半句用标准。拼接方式的落地细节是预录音频我统一转成了 16kHz 单声道 16bit PCM播报时直接在内存里做 PCM 拼接然后交给播放器避免了每次播报都解码文件的 IO 开销速度非常快。这种方案在低端设备上有明显优势CPU 占用极低。当然模板拼接覆盖不了所有场景。比如商家的自定义语音问候语、用户名播报这些文案可能不在预设模板里。我用了一个兜底策略先把文本扔给端侧 TTS 引擎试一次同时做一个结果缓存同样的文本第二次播报直接走缓存音频。实测大多数自定义短句首次延迟可以控制在可接受范围内第二次播报基本无感。3.4 音频焦点与系统音量管理播放层是踩坑最多的地方。多端涉及的系统音频策略差异非常大。在 Android 上最重要的是 AudioFocus。播报是一段短暂提示音应该用短时焦点AUDIOFOCUS_GAIN_TRANSIENT播完立刻释放不能长时间占用否则后台的音乐会被你“打断”很久用户会认为 App 是“流氓”。正确姿势是请求短时焦点拿到焦点后播放播放结束后立即 abandon 焦点。private fun requestFocus(): Boolean { val result audioManager.requestAudioFocus( focusChangeListener, AudioManager.STREAM_MUSIC, AudioManager.AUDIOFOCUS_GAIN_TRANSIENT ) return result AudioManager.AUDIOFOCUS_REQUEST_GRANTED } private val focusChangeListener AudioManager.OnAudioFocusChangeListener { change - when (change) { AudioManager.AUDIOFOCUS_LOSS - { // 其他应用抢走焦点停止播报 playbackHandler.stop() } AudioManager.AUDIOFOCUS_LOSS_TRANSIENT - { // 临时丢失如来电可以暂停后恢复 playbackHandler.pause() } AudioManager.AUDIOFOCUS_GAIN - { // 恢复播放 playbackHandler.resume() } } }在 iOS 上核心是 AVAudioSession 的 category 配置。如果只设成 playback 且 options 里没有处理静音开关拨到静音拨片时插播会被静音这是测试里最容易翻车的场景。要在播报前确认 session 配置尤其是使用 AVAudioSession.Category.playback 来绕开静音拨片。但这也会带来一个副作用App 在后台也会播声音所以必须评估自己的业务场景是否符合平台规范不要为了播报滥用后台音频权限。在 Web 端最大的障碍是浏览器自动播放策略。语音播报组件如果在一进入页面就调用 AudioContext 播放大概率会被浏览器拦截。常规做法是监听用户的首次点击事件提前创建并 resume AudioContext把音频解锁掉const ctx new AudioContext(); document.body.addEventListener(touchstart, () { if (ctx.state suspended) { ctx.resume(); } }, { once: true });音量管理上我用的是“相对音量 最大音限幅”策略。组件不直接控制系统媒体音量而是读取当前系统音量后按比例叠乘一个播报系数。比如系统音量 50%播报系数 1.2实际播报音量为 60%。同时设一个上限阈值默认不超过系统音量的 80%防止播报声音突兀刺耳。这个比例在夜间或安静环境中调低可以通过外部参数在线设置不需要发版。3.5 触发链路与后台保活不依赖前台页面语音播报组件一个很容易被忽略的需求是播报时 App 可能不在前台甚至收银员把手机放裤兜里。所以触发链路不能依赖 Activity 可见必须放在一个常驻的轻量级服务中。Android 端我用前台服务承载播报 worker并给用户一个可关闭的常驻通知。很多国产系统会杀后台进程前台服务配合通知能极大提高存活率虽然不能保证 100% 存活但实测下来稳定性比纯后台 Service 好很多。触发链路设计如下支付结果通过推送、本地广播、HTTP 回调进入组件。组件在进入时先做业务幂等判断防止同一笔订单重复播报。若当前播报队列已满或正在播报高优消息新消息按优先级插入。播报完成后通过回调通知业务方“已播报成功”业务方可以做后续动作比如开小票、弹窗确认。需要特别说明的是不要把支付回调里“播报成功”当成“支付成功”这两件事必须解耦。曾经见过有项目在语音播报失败时回滚订单状态这会导致非常严重的资金一致性问题。播报只是一种提示手段支付成功与否应该以支付网关的最终状态为准。4. 真实环境里的踩坑记录这些问题文档里不会写4.1 声音播不出来的三大元凶上线前测试时最容易遇到的问题是“代码明明在跑就是没有声音”。我排查过 N 次之后总结出三大元凶音频焦点没申请到。Android 上如果其他 App 正在持续播放音乐并且它占用了长期焦点你的短时焦点可能不会被授予此时播放会直接失败或静默。处理办法是播放前检查焦点申请结果申请失败时不要硬播稍后重试或者在焦点变化回调里补播。播放器用的声道和音频数据不匹配。比如预录音频是单声道 PCM但播放器配置了立体声输出播放出来全是噪音或者声音极轻。这个低级错误很常见排查时先检查 AudioTrack/播放器的 sampleRate、channel 配置。音量被设置成 0。有些设备在初始化时系统音量默认为 0或者某个渠道包把媒体音量意外调低而你没有在播报前读取和控制音量策略就会出现“看起来在播实际没声音”的现象。解决方式是播报前读取当前音量若低于阈值则给出提示或临时抬升到可听水平。4.2 后台被系统回收播报中断Android 厂商对后台应用的限制越来越严格振动、后台弹窗、音频播放都可能是管控对象。最夸张的一次是产后重启设备后应用处于后台白名单之外所有播放请求全部被静默丢弃。我的应对策略有三层。第一层是前台服务 常驻通知尽量减少被杀概率。第二层是支持系统级的“电池优化白名单”引导但要克制不能强逼用户开启。第三层是加了一个简单的“遗嘱”机制把未播报的消息持久化存储组件下次被拉起时会重新检查并补播。虽然做不到绝对实时但至少不会丢消息。4.3 iOS 静音键的方向搞反了iOS 侧的坑很有意思。测试时在模拟器里一切正常上了真机才发现静音拨片往下一拨语音就没了。原因是 AVAudioSession 的默认行为会跟随静音键。想要播报不跟随静音键需要显式设置播放类别。但这里有个隐性坑当你设置了播放类别之后App 的音频播放会被系统判定为“需要继续播放”在控制中心可能出现音频播放控制卡片。如果产品上只需要短暂播报没想做成一个“正在播放”的 App这个副作用会让用户困惑。我的做法是播报结束后主动 deactivate 音频会话尽量不留下播放状态痕迹。这个行为在接入第三方推送语音、连续播报场景下需要仔细权衡。4.4 队列堆积导致的声音“碎掉”高峰期时同一秒内可能进来好几条播报请求如果播放器并发控制没做好会出现声音像卡带一样碎掉或只播最后一句的现象。根因往往不是队列本身而是播放器实例没有正确释放。比如上一段音频还在播放下一条消息就已经开始了播放器重初始化前一个播放器被强制 stop但底层资源还没完全释放导致后续音频数据被截断。我的修复方式是播放器全局唯一串行复用并在一段音频播完后主动等待播放器状态回调确认完成再拉取下一条。这个改动看似简单实际上把拼接错乱的概率降到了接近零。4.5 低端设备首字延迟优化部分低端 Android 设备首字延迟特别明显从事件进入到出声可能要 1 秒以上。优化手段是三层预加载App 启动时异步把预录音频片段加载到内存并把端侧 TTS 引擎做一次预热避免首次调用才初始化。热门金额缓存把经常出现的金额和对应音频做内存缓存比如“10元”“20元”“50元”这些高频金额直接命中缓存连拼接和 TTS 都省了。异步播放链播报消息解析、合成、播放之间用工作线程处理避免在 UI 线程上执行任何耗时操作同时保证合成结果直接写入播放器缓冲区减少一次拷贝。三项优化叠加后低端设备普通播报延迟稳定在 200ms 左右感知上基本“秒出”。5. 接入指南与扩展思路5.1 快速接入的四个步骤如果要把 VoiceBroadcast 装进自己项目抽象成四个步骤就够了。第一步初始化组件。传入 Context、配置文件、音量策略参数。第二步注册业务事件。把支付回调、订单事件、设备告警事件与对应的播报模板绑定。第三步调用播报入口。业务侧只需一句话VoiceBroadcast.getInstance().announce(new BroadcastMessage(...))。第四步处理回调。播报完成、失败、被丢弃三个回调按自己的需求处理账单打印、补报逻辑。这个接入过程尽量保持同步语义简单。调用方不需要关心消息是走了拼接还是 TTS也不需要关心当前播放器状态组件内部全处理。这也是组件存在的意义把这件事做成一键接入的基础能力而不是每个业务方各写一套。5.2 扩展方向从语音播报到语音交互组件在结构上保留了扩展空间。目前只做“播报”但如果后续要做多语言播报、情感播报比如“退款到账”用稍低沉的音色、动态语速调整都只需要在合成层增加实现。比较实用的一个扩展是噪声环境自适应采集环境噪声动态提高播报音量或让播报内容重复两遍。硬件喇叭场景下还可以把播放层对接到底层音频设备支持更大功率的播报。我也预留了“打断播报”接口比如用户触发更高优先级操作时可以直接终止当前播报并进入新播报。这个在交互型设备上非常必要比如自助设备上用户已经点按屏幕了语音还在推荐上一个流程体验会很奇怪。打断接口的实现关键是要同时清理当前音频流和队列状态不能只停播放器否则下一个消息会异常。5.3 做这个组件的一点长期心得我把话说在前面项目里出现语音播报需求第一反应通常是“很简单的功能”但让它稳定工作在所有用户的设备上要打磨的细节远超预期。音频焦点处理、后台保活、多端差异、队列状态、音量策略每一个环节单独看都不难组合在一起就容易出幺蛾子。遇到问题不要慌先把链路拆开分清是触发层、调度层、合成层还是播放层的问题定位速度会快很多。6. 写在最后的个人体会做 VoiceBroadcast 这一年多我最大的感受是越小的功能越考验基本功。语音播报本质上是“闹钟式”的信息触达它不追求复杂的音效和 UI只追求一件事——“关键时刻能响”。为了这“能响”两个字我需要处理各种莫名其妙的系统策略、低端设备的性能瓶颈、嘈杂环境下的可听性甚至用户手机静音键的物理位置。还有一个很实际的建议如果你也在做类似组件尽量把“播报成功”和“业务完成”解耦永远不要让播报的成败影响业务数据的正确性这是组件稳定性之外更重要的一条底线。项目做到最后真正让人踏实的不是功能多丰富而是异常发生时该丢的丢、该补的补、该响的一定要响。 
长河君 · 2026/10/16 1:47:18 · 阅读 1.2k 语音播报组件全解析：从TTS选型到多端适配与落地实践
先聊个现象我们平时在便利店、水果摊、奶茶店听到的那句“收款到账XX元”听起来只是一句话背后其实是一个很小的语音播报组件。这个组件看着不起眼真到动手做的时候坑却一个接一个。做 Saa 类收银、门店管理系统、自助设备、充电桩这类项目时几乎都会遇到同样的需求收一笔钱就要让设备“开口说话”。我最近完整做了一个类似收款到账语音提示的组件 VoiceBroadcast从需求梳理、方案选型到多端适配都走了一遍这一篇就是完整的复盘适合正在做支付回调播报、叫号提示、设备语音反馈的开发者参考也可以直接拿去做技术方案评审或接入落地。1. 先把场景收拢这个组件到底在替谁干活1.1 看起来需要语音播报的地方其实不只是收银语音播报组件最容易想到的场景是线下商家收款。店主在忙的时候经常眼睛不看手机或收银屏幕如果每笔款都要低头确认效率很低漏单风险也高。所以收款到账的语音提示是刚需。但如果只盯着这个场景做设计出来的组件大概率是偏科。我梳理了一下实际项目里需要语音播报的场景至少有这么几类门店收银与聚合收款到账金额、支付渠道、退款、优惠券核销后都需要语音反馈。自助设备自助售货机、充电桩、自助借还书柜。这类设备没有专人值守用户操作成功或失败后要“开口说话”。取餐叫号与排队系统后厨噪音大且后厨工作人员不便靠近屏幕语音播报订单号或取餐号是最直接的方案。后台作业仓库配料、快递分拣、园区摆渡车调度。现场工作人员戴手套、手持扫码枪不方便掏手机看通知语音就是唯一可靠的信息通道。硬件联动播报小票打印机自带喇叭、云喇叭、收款音箱。这些硬件本质上是“把播报能力物理化”。把这些场景放在一起看需求就不再是“播放一段音效”这么简单了。它的本质是把系统里产生的事件转成一段清晰、可靠、不吵人、不遗漏的语音信息并在各种设备条件下准时送达给正在忙的人。1.2 从场景倒推出来的硬性需求清单把所有场景的需求列成清单很多模糊的设计决策会变清晰。我的组件需求清单是这么几条低延迟从支付回调或订单事件发生到扬声器出声感知延迟应控制在几百毫秒内。用户侧的感受是“刚付完就报出来了”如果超过 1 秒体验就很拖沓。离线可用商家门店 Wi-Fi 质量参差不齐收款那一刻网络未必顺畅。若播报依赖云端 TTS断网时就会“失声”这是绝对无法接受的。多端覆盖同一个组件的逻辑要能跑在 Android、iOS、Web 以及部分嵌入式设备上。不能只在某一平台上写死。队列串行多条消息可能同时到达比如会员充值时同时触发到账播报和积分提示需要按优先级排队逐条播报不能叠音。音量可控但不过载播报声音要能在嘈杂环境下听清但又不能刺耳。直播间、夜间门店、办公室场景对音量舒适度要求完全不同。低资源占用不能为了播一句话就常驻一个几百兆的语音引擎。这张清单直接决定了技术选型的方向。下面展开讲方案是怎么定的。2. 技术选型为什么我没有直接塞一个现成 SDK 了事2.1 三种“出声”方案的分岔路口实现语音播报本质上就是把文字变成声音。市面上大体有三条路在线云合成、离线端侧引擎、预录音频拼接。这三条路不是互斥的但很多人一上来就选第一条结果被网络和费用绑架。先看在线云合成。像常见的云厂商语音合成接口输入文本返回 MP3 或 PCM 音频。优点是音色自然、支持多音色和多语言缺点是依赖网络请求且接口通常要鉴权、要计费、可能限流。对于支付播报这种高实时、高频次、偶发断网场景把核心链路压在云端风险太高。云端合成只适合做“增强音色”的可选能力不能当主力。再看离线端侧引擎。现在很多端侧 SDK 可以本地合成语音音色比早期那种机械音好很多支持离线、延迟低。缺点是引擎体积通常较大有的要二三十 MB 甚至更大而且不少离线引擎有授权费、只提供特定 SDK 格式对多端适配不够灵活。如果项目只需要播报固定模板比如“收款到账XX元”“取餐号XX号”让一个完整 TTS 引擎常驻内存性价比不高。最后是预录音频拼接。把可能出现的语音片段提前录好例如“收款到账”“元”“角”“分”“支付宝”“微信”“XX号”播报时按文案顺序拼接。这种做法延迟极低、彻底离线、内存占用小适合模板固定、组合有限的场景。缺点是文案一旦出现模板之外的字词比如自定义店铺名、客户昵称拼接就失效了。我的最终方案是“模板拼接为主、端侧 TTS 兜底、云端 TTS 可选增强”三者组合。严格来说VoiceBroadcast 不是一个纯播放器而是一个“播报策略调度中心”。2.2 现成 SDK 与自研组件的边界做选择之前我也认真对比过“直接买现成的语音播报 SDK”。现成 SDK 的优势很明显开发量小、稳定、不用操心后台保活和音频焦点这些细节。但它的问题往往在使用一段时间后才暴露封闭性播报文案结构、音量调节策略、队列优先级很难按自己的业务定制。体积与依赖为了一个小功能引入整套推送和账号体系合规和包体积都不太划算。端侧适配黑盒Android 各厂商系统行为差异很大现成 SDK 常驻后台被杀、AudioFocus 抢占异常这类问题出了问题只能提工单无法自查。成本线性上涨有的按设备数、按调用次数收费业务增长的同时成本跟着走不够透明。我自己的判断是如果业务只是“临时接个播报”用现成 SDK 最稳妥但如果这个组件要进自己的核心收银链路、要考虑千万级设备的成本就必须自研一套。VoiceBroadcast 的定位是后者一套可以嵌入自己业务系统的播报基础组件。三类方案对比我整理成一张表方便选型时直接对照维度在线云合成离线端侧引擎预录音频拼接延迟高200ms-1s低极低网络依赖强依赖无无音色自然度高中高中取决于实录包体积影响小大极小可扩展文案强强弱单位成本按调用计费授权费一次性录制成本适合场景多语言/个性化通用文本播报固定模板高频播报2.3 整体架构长什么样VoiceBroadcast 的模块划分上我参考了消息队列的思路但做了很多“小而轻”的取舍。整体分成四层触发层接收支付回调、订单事件、推送消息统一转换成内部播报消息。调度层维护一个串行播报队列管理优先级、去重、丢弃策略并推送消息给合成层。合成层按文案类型选择拼接或 TTS 合成输出 PCM/WAV 音频数据。播放层负责 AudioFocus 申请、音量控制、播放器实例管理以及多端播放器适配。这样分层的核心好处是每一层的替换成本都很低。以后想换更好的 TTS 通过替换合成层实现想接入新的硬件喇叭重写播放层即可。调度层保持无状态天然支持多线程调用。3. 核心模块设计与实现从消息到出声3.1 播报消息的标准化所有进入 VoiceBroadcast 的事件先要做一次“格式化”。这一步很关键它决定了后面所有层能不能稳定工作。我定义的消息结构大概是这样的public class BroadcastMessage { private String id; // 消息唯一ID用于去重 private int priority; // 优先级数值越大越先播 private String templateId; // 模板ID如“收款到账” private MapString, String params; // 模板参数如金额12.34 private String fallbackText; // 兜底纯文本模板无法覆盖时用 TTS private long expireAt; // 过期时间超时未播则丢弃 private BroadcastCallback callback; // 播报完成回调用于业务联动 }为什么不用一个简单的 String 直接传因为业务方调用时往往只知道自己有什么数据不知道该怎么组织语音文案。比如支付回调里可能是 amount1200单位分我这边统一负责把 1200 转成“十二元”并拼进“收款到账十二元”。这样调用方只需要传结构化参数文案规范和播报风格都收敛在组件内部不会出现各端各写一套文案的乱象。另外消息必须带优先级。在自助设备上“故障告警”和“收款到账”同时发生时肯定是故障告警先播就算它晚到也要插队。优先级从低到高我分了 INFO、NORMAL、URGENT、CRITICAL 四级调度层根据优先级和到达时间共同决定插队策略。3.2 串行播放队列与状态机音频播放和 UI 一样最怕并发。如果两条播报消息同时到达而不加控制就会出现“收款到账十元收款到账二十元”叠在一起两个声音糊成一片用户什么都听不清。语音播报必须是串行的一条播完再播下一条。我实现了一个基于状态机的串行播放器核心状态是 IDLE、PREPARING、PLAYING、WAITING_STOP。队列用一个线程安全的阻塞队列承接消息播放线程串行消费。因为语音播报本身的时长很短一般 2 到 5 秒单线程处理完全够用还省掉了锁竞争和并发调度的复杂度。核心代码示意如下class SpeechPlayer(private val synthesizer: SpeechSynthesizer) { private val queue PriorityBlockingQueueBroadcastMessage() private val executor Executors.newSingleThreadExecutor { r - Thread(r, voice-broadcast-worker).apply { isDaemon true } } fun enqueue(message: BroadcastMessage) { queue.offer(message) } fun start() { executor.execute { while (isRunning) { val msg queue.take() playSafely(msg) } } } private fun playSafely(msg: BroadcastMessage) { try { val audioData synthesizer.synthesize(msg) playbackHandler.play(audioData, volume msg.priority.volumeLevel) } catch (e: Exception) { // 单条消息异常不能拖垮整个队列记录后继续 Logger.e(play message failed: ${msg.id}, e) } } }这里有一个细节PriorityBlockingQueue 在优先级相同时不保证先进先出所以入队时要给每条消息一个自增序号优先级相同时序号小的先出队。否则用户会听到偶尔乱序的情况。3.3 合成策略先拼后合成减少不必要的 TTS 调用合成层的核心策略是“能不 TTS 就不 TTS”。因为支付播报的文案高度模板化绝大多数情况下不需要完整 TTS 翻译只需要拼接。拿“收款到账12.34元”举例。我先把这个文案拆成几段固定前缀“收款到账”预录音频整数金额“十二”预录音频或数字分段小数点“点”预录音频小数金额“三四”预录音频单位“元”预录音频这里的难点是金额转中文读法。数字不是简单从左到右读要处理“零”的问题。比如 1024 读“一千零二十四”1200 读“一千二百”12.04 读“十二点零四”读法的规则其实不少。我实现了一个金额朗读转换器专门处理整数位、小数位、连续的零、角分单位并且针对支付场景做了两套模式简洁模式12.34 读作“十二块三毛四”适合门店日常收款。标准模式12.34 读作“十二点三四元”适合金额精确展示或财务场景。两种模式可以运行时切换但必须保证同一笔播报过程内一致不能前半句用简洁后半句用标准。拼接方式的落地细节是预录音频我统一转成了 16kHz 单声道 16bit PCM播报时直接在内存里做 PCM 拼接然后交给播放器避免了每次播报都解码文件的 IO 开销速度非常快。这种方案在低端设备上有明显优势CPU 占用极低。当然模板拼接覆盖不了所有场景。比如商家的自定义语音问候语、用户名播报这些文案可能不在预设模板里。我用了一个兜底策略先把文本扔给端侧 TTS 引擎试一次同时做一个结果缓存同样的文本第二次播报直接走缓存音频。实测大多数自定义短句首次延迟可以控制在可接受范围内第二次播报基本无感。3.4 音频焦点与系统音量管理播放层是踩坑最多的地方。多端涉及的系统音频策略差异非常大。在 Android 上最重要的是 AudioFocus。播报是一段短暂提示音应该用短时焦点AUDIOFOCUS_GAIN_TRANSIENT播完立刻释放不能长时间占用否则后台的音乐会被你“打断”很久用户会认为 App 是“流氓”。正确姿势是请求短时焦点拿到焦点后播放播放结束后立即 abandon 焦点。private fun requestFocus(): Boolean { val result audioManager.requestAudioFocus( focusChangeListener, AudioManager.STREAM_MUSIC, AudioManager.AUDIOFOCUS_GAIN_TRANSIENT ) return result AudioManager.AUDIOFOCUS_REQUEST_GRANTED } private val focusChangeListener AudioManager.OnAudioFocusChangeListener { change - when (change) { AudioManager.AUDIOFOCUS_LOSS - { // 其他应用抢走焦点停止播报 playbackHandler.stop() } AudioManager.AUDIOFOCUS_LOSS_TRANSIENT - { // 临时丢失如来电可以暂停后恢复 playbackHandler.pause() } AudioManager.AUDIOFOCUS_GAIN - { // 恢复播放 playbackHandler.resume() } } }在 iOS 上核心是 AVAudioSession 的 category 配置。如果只设成 playback 且 options 里没有处理静音开关拨到静音拨片时插播会被静音这是测试里最容易翻车的场景。要在播报前确认 session 配置尤其是使用 AVAudioSession.Category.playback 来绕开静音拨片。但这也会带来一个副作用App 在后台也会播声音所以必须评估自己的业务场景是否符合平台规范不要为了播报滥用后台音频权限。在 Web 端最大的障碍是浏览器自动播放策略。语音播报组件如果在一进入页面就调用 AudioContext 播放大概率会被浏览器拦截。常规做法是监听用户的首次点击事件提前创建并 resume AudioContext把音频解锁掉const ctx new AudioContext(); document.body.addEventListener(touchstart, () { if (ctx.state suspended) { ctx.resume(); } }, { once: true });音量管理上我用的是“相对音量 最大音限幅”策略。组件不直接控制系统媒体音量而是读取当前系统音量后按比例叠乘一个播报系数。比如系统音量 50%播报系数 1.2实际播报音量为 60%。同时设一个上限阈值默认不超过系统音量的 80%防止播报声音突兀刺耳。这个比例在夜间或安静环境中调低可以通过外部参数在线设置不需要发版。3.5 触发链路与后台保活不依赖前台页面语音播报组件一个很容易被忽略的需求是播报时 App 可能不在前台甚至收银员把手机放裤兜里。所以触发链路不能依赖 Activity 可见必须放在一个常驻的轻量级服务中。Android 端我用前台服务承载播报 worker并给用户一个可关闭的常驻通知。很多国产系统会杀后台进程前台服务配合通知能极大提高存活率虽然不能保证 100% 存活但实测下来稳定性比纯后台 Service 好很多。触发链路设计如下支付结果通过推送、本地广播、HTTP 回调进入组件。组件在进入时先做业务幂等判断防止同一笔订单重复播报。若当前播报队列已满或正在播报高优消息新消息按优先级插入。播报完成后通过回调通知业务方“已播报成功”业务方可以做后续动作比如开小票、弹窗确认。需要特别说明的是不要把支付回调里“播报成功”当成“支付成功”这两件事必须解耦。曾经见过有项目在语音播报失败时回滚订单状态这会导致非常严重的资金一致性问题。播报只是一种提示手段支付成功与否应该以支付网关的最终状态为准。4. 真实环境里的踩坑记录这些问题文档里不会写4.1 声音播不出来的三大元凶上线前测试时最容易遇到的问题是“代码明明在跑就是没有声音”。我排查过 N 次之后总结出三大元凶音频焦点没申请到。Android 上如果其他 App 正在持续播放音乐并且它占用了长期焦点你的短时焦点可能不会被授予此时播放会直接失败或静默。处理办法是播放前检查焦点申请结果申请失败时不要硬播稍后重试或者在焦点变化回调里补播。播放器用的声道和音频数据不匹配。比如预录音频是单声道 PCM但播放器配置了立体声输出播放出来全是噪音或者声音极轻。这个低级错误很常见排查时先检查 AudioTrack/播放器的 sampleRate、channel 配置。音量被设置成 0。有些设备在初始化时系统音量默认为 0或者某个渠道包把媒体音量意外调低而你没有在播报前读取和控制音量策略就会出现“看起来在播实际没声音”的现象。解决方式是播报前读取当前音量若低于阈值则给出提示或临时抬升到可听水平。4.2 后台被系统回收播报中断Android 厂商对后台应用的限制越来越严格振动、后台弹窗、音频播放都可能是管控对象。最夸张的一次是产后重启设备后应用处于后台白名单之外所有播放请求全部被静默丢弃。我的应对策略有三层。第一层是前台服务 常驻通知尽量减少被杀概率。第二层是支持系统级的“电池优化白名单”引导但要克制不能强逼用户开启。第三层是加了一个简单的“遗嘱”机制把未播报的消息持久化存储组件下次被拉起时会重新检查并补播。虽然做不到绝对实时但至少不会丢消息。4.3 iOS 静音键的方向搞反了iOS 侧的坑很有意思。测试时在模拟器里一切正常上了真机才发现静音拨片往下一拨语音就没了。原因是 AVAudioSession 的默认行为会跟随静音键。想要播报不跟随静音键需要显式设置播放类别。但这里有个隐性坑当你设置了播放类别之后App 的音频播放会被系统判定为“需要继续播放”在控制中心可能出现音频播放控制卡片。如果产品上只需要短暂播报没想做成一个“正在播放”的 App这个副作用会让用户困惑。我的做法是播报结束后主动 deactivate 音频会话尽量不留下播放状态痕迹。这个行为在接入第三方推送语音、连续播报场景下需要仔细权衡。4.4 队列堆积导致的声音“碎掉”高峰期时同一秒内可能进来好几条播报请求如果播放器并发控制没做好会出现声音像卡带一样碎掉或只播最后一句的现象。根因往往不是队列本身而是播放器实例没有正确释放。比如上一段音频还在播放下一条消息就已经开始了播放器重初始化前一个播放器被强制 stop但底层资源还没完全释放导致后续音频数据被截断。我的修复方式是播放器全局唯一串行复用并在一段音频播完后主动等待播放器状态回调确认完成再拉取下一条。这个改动看似简单实际上把拼接错乱的概率降到了接近零。4.5 低端设备首字延迟优化部分低端 Android 设备首字延迟特别明显从事件进入到出声可能要 1 秒以上。优化手段是三层预加载App 启动时异步把预录音频片段加载到内存并把端侧 TTS 引擎做一次预热避免首次调用才初始化。热门金额缓存把经常出现的金额和对应音频做内存缓存比如“10元”“20元”“50元”这些高频金额直接命中缓存连拼接和 TTS 都省了。异步播放链播报消息解析、合成、播放之间用工作线程处理避免在 UI 线程上执行任何耗时操作同时保证合成结果直接写入播放器缓冲区减少一次拷贝。三项优化叠加后低端设备普通播报延迟稳定在 200ms 左右感知上基本“秒出”。5. 接入指南与扩展思路5.1 快速接入的四个步骤如果要把 VoiceBroadcast 装进自己项目抽象成四个步骤就够了。第一步初始化组件。传入 Context、配置文件、音量策略参数。第二步注册业务事件。把支付回调、订单事件、设备告警事件与对应的播报模板绑定。第三步调用播报入口。业务侧只需一句话VoiceBroadcast.getInstance().announce(new BroadcastMessage(...))。第四步处理回调。播报完成、失败、被丢弃三个回调按自己的需求处理账单打印、补报逻辑。这个接入过程尽量保持同步语义简单。调用方不需要关心消息是走了拼接还是 TTS也不需要关心当前播放器状态组件内部全处理。这也是组件存在的意义把这件事做成一键接入的基础能力而不是每个业务方各写一套。5.2 扩展方向从语音播报到语音交互组件在结构上保留了扩展空间。目前只做“播报”但如果后续要做多语言播报、情感播报比如“退款到账”用稍低沉的音色、动态语速调整都只需要在合成层增加实现。比较实用的一个扩展是噪声环境自适应采集环境噪声动态提高播报音量或让播报内容重复两遍。硬件喇叭场景下还可以把播放层对接到底层音频设备支持更大功率的播报。我也预留了“打断播报”接口比如用户触发更高优先级操作时可以直接终止当前播报并进入新播报。这个在交互型设备上非常必要比如自助设备上用户已经点按屏幕了语音还在推荐上一个流程体验会很奇怪。打断接口的实现关键是要同时清理当前音频流和队列状态不能只停播放器否则下一个消息会异常。5.3 做这个组件的一点长期心得我把话说在前面项目里出现语音播报需求第一反应通常是“很简单的功能”但让它稳定工作在所有用户的设备上要打磨的细节远超预期。音频焦点处理、后台保活、多端差异、队列状态、音量策略每一个环节单独看都不难组合在一起就容易出幺蛾子。遇到问题不要慌先把链路拆开分清是触发层、调度层、合成层还是播放层的问题定位速度会快很多。6. 写在最后的个人体会做 VoiceBroadcast 这一年多我最大的感受是越小的功能越考验基本功。语音播报本质上是“闹钟式”的信息触达它不追求复杂的音效和 UI只追求一件事——“关键时刻能响”。为了这“能响”两个字我需要处理各种莫名其妙的系统策略、低端设备的性能瓶颈、嘈杂环境下的可听性甚至用户手机静音键的物理位置。还有一个很实际的建议如果你也在做类似组件尽量把“播报成功”和“业务完成”解耦永远不要让播报的成败影响业务数据的正确性这是组件稳定性之外更重要的一条底线。项目做到最后真正让人踏实的不是功能多丰富而是异常发生时该丢的丢、该补的补、该响的一定要响。