★ FEATURED ARTICLE 简介这是一份面向 Android 开发者的离线文字转语音TTS演示工程核心价值在于不依赖手机系统自带 TTS 引擎即使设备未安装任何语音包也能正常发声适合需要为应用集成离线播报能力的初中级开发者参考。压缩包共 25 个文件约 511KB以 14 个 xml 布局与配置、3 个 java 源码、1 个 so 本地库及若干工程属性文件为主涵盖界面布局、语音引擎调用与资源目录等模块结构完整可直接导入运行。工程实现了文字转语音、音色切换与语速调节等基础功能并附带离线语音资源文件便于读者快速理解离线 TTS 的接入流程与参数控制方式。目前已有 3094 人学习下载。作者也指出英文单词会被逐字母朗读的遗留问题为后续优化留出讨论空间适合作为排错与二次开发的起点。1. 离线语音合成在 Android 上到底能跑多稳去年帮一个做工业巡检的朋友看设备端方案他们的需求很朴素车间里没有稳定 Wi-Fi工人戴着蓝牙耳机点一下按钮设备把当前工单内容念出来。听起来简单但一上真机就翻车——在线 TTS 请求超时、返回 4G 信号弱、语音断断续续。后来换成 android_tts_离线语音demo包文字转语音 这套思路把模型和引擎全部塞进 APK才把问题按住。离线 TTS 的核心价值就一句话不依赖网络、不依赖云端计费、响应延迟可控。它适合三类人做工业手持终端的、做车载/穿戴语音播报的、以及做无障碍阅读功能的开发者。但离线不等于零成本模型体积、音色自然度、多音字处理、内存占用每一项都要在工程上做取舍。这篇笔记按「先跑通最小 Demo → 再调参数 → 再避坑 → 最后做进阶验证」的顺序展开代码可以直接抄参数会标清楚边界。2. 把离线 TTS 引擎跑起来从依赖到第一句话2.1 为什么优先选系统自带 TTS 引擎而不是自己塞模型Android 从早期版本就内置了android.speech.tts.TextToSpeech这套 API它本身是一个抽象层底层可以对接不同厂商的合成引擎。很多国产 ROM 出厂就预装了离线引擎包比如某些设备自带的中文离线音色。这意味着你不需要把几百 MB 的模型打进 APK直接调用系统能力就能实现离线播报。判断设备是否支持离线合成关键看TextToSpeech.getEngines()返回的引擎列表里哪些EngineInfo的isNetworkConnectionRequired()为 false。如果为 false说明该引擎可以离线工作。这是最省事的路径适合对音色要求不高、但要求稳定可用的场景。如果设备出厂没有离线引擎或者你需要统一音色那就得走「自带引擎 模型文件」的方案常见做法是集成一个轻量级合成库把模型放在 assets 或外部存储首次启动时拷贝到应用私有目录。两种路径的选型逻辑很简单设备可控、ROM 统一优先用系统引擎设备型号杂、音色要一致才考虑自带模型。2.2 最小可运行 Demo初始化、语言检查与播报下面这段代码是跑通离线 TTS 的最小闭环。注意onInit回调里的状态判断这是最容易出问题的地方。// 初始化 TextToSpeech传入 Context 和 OnInitListener TextToSpeech tts new TextToSpeech(getApplicationContext(), new TextToSpeech.OnInitListener() { Override public void onInit(int status) { if (status TextToSpeech.SUCCESS) { // 查询设备支持的语言优先选中文 int result tts.setLanguage(Locale.CHINA); if (result TextToSpeech.LANG_MISSING_DATA || result TextToSpeech.LANG_NOT_SUPPORTED) { // 语言数据缺失说明当前引擎没有中文离线包 Log.e(TTS, 中文离线数据缺失需要换引擎或安装语音包); return; } // 设置语速1.0 为正常速度范围通常 0.5~2.0 tts.setSpeechRate(1.0f); // 设置音调1.0 为正常范围 0.5~2.0 tts.setPitch(1.0f); // 指定使用离线模式避免引擎偷偷走网络 tts.setEngineByPackageName(getOfflineEnginePackage()); // 播报第一句话QUEUE_FLUSH 表示打断之前的播报 tts.speak(设备已启动当前工单编号 A 一零二四, TextToSpeech.QUEUE_FLUSH, null, utteranceId_1); } else { Log.e(TTS, 初始化失败status status); } } });逻辑说明onInit是异步回调不能直接在new TextToSpeech之后立刻调用speak否则会静默失败。setLanguage的返回值必须判断LANG_MISSING_DATA表示引擎存在但缺中文数据LANG_NOT_SUPPORTED表示引擎根本不支持中文。setEngineByPackageName用于锁定离线引擎避免系统默认引擎在弱网时尝试联网。参数方面setSpeechRate超过 1.5 后中文听感会明显发飘工业场景建议 0.9~1.1setPitch一般不动除非要做特殊音效。speak的第四个参数utteranceId用于后续追踪播报状态建议每条都传唯一值。2.3 把模型文件放进 APKassets 拷贝与路径校验如果你走自带模型路线模型文件通常不能直接放在 assets 里被引擎读取因为多数合成库要求文件系统路径。常见做法是首次启动时把 assets 下的模型拷贝到getFilesDir()或外部私有目录。// 将 assets 中的离线模型拷贝到应用私有目录 private void copyModelIfNeeded() throws IOException { File destDir new File(getFilesDir(), tts_model); if (!destDir.exists()) { destDir.mkdirs(); } File modelFile new File(destDir, zh_offline.bin); // 已存在且大小一致则跳过避免重复拷贝 if (modelFile.exists() modelFile.length() 0) { return; } try (InputStream is getAssets().open(tts_model/zh_offline.bin); FileOutputStream fos new FileOutputStream(modelFile)) { byte[] buffer new byte[8192]; int len; while ((len is.read(buffer)) ! -1) { fos.write(buffer, 0, len); } fos.flush(); } // 拷贝完成后校验文件大小防止拷贝中断 if (modelFile.length() 0) { throw new IOException(模型拷贝失败文件为空); } }逻辑说明拷贝操作必须放在子线程否则会阻塞主线程导致 ANR。判断「已存在」时不能只看文件是否存在还要看大小是否大于 0因为拷贝中断会留下空文件。参数上buffer用 8192 字节是折中值太小会增加 IO 次数太大占内存。模型文件建议控制在 50MB 以内超过这个量级首次启动拷贝会明显变慢用户感知差。3. 离线 TTS 的参数调优与多音字处理3.1 语速、音调、音量三者的联动边界离线引擎的参数调节不是孤立的。语速调快后音调如果不变中文的声调会压缩听起来像机器人赶工。实测下来语速 1.2 配音调 1.05 比较自然语速 0.8 配音调 0.95 适合老年无障碍场景。音量不要用setVolume去调那个是相对系统媒体的比例直接调系统媒体音量更可靠。另外setSpeechRate在不同引擎上的实际映射曲线不一样有的引擎 1.5 就很快有的 2.0 才明显。建议在设置页暴露一个「试听」按钮让用户自己拖到舒服为止而不是在代码里写死。3.2 多音字与数字读法用 SSML 还是预处理离线引擎对 SSML 的支持参差不齐。系统自带引擎通常支持部分 SSML 标签比如speak、phoneme但自带模型库往往只认纯文本。稳妥做法是在文本进入引擎之前做一层预处理把「1024」转成「一千零二十四」或「一零二四」把「行」根据上下文替换成「xíng」或「háng」的拼音标注。如果引擎支持addSpeech接口可以把特定词条绑定到自定义音频文件这是处理多音字最彻底的方式但会增加包体积。// 文本预处理数字转中文读法避免引擎读成英文 private String preprocess(String input) { // 简单示例把连续数字逐位转换适合编号类文本 StringBuilder sb new StringBuilder(); for (char c : input.toCharArray()) { if (c 0 c 9) { sb.append(零一二三四五六七八九.charAt(c - 0)); } else { sb.append(c); } } return sb.toString(); }逻辑说明这段预处理只适合工单编号、设备号这类需要逐位读的场景。如果是金额或数量逐位读会闹笑话需要另一套规则。参数上建议把预处理规则做成可配置的不同业务走不同分支不要一个函数打天下。3.3 播报队列与打断策略QUEUE_FLUSH 和 QUEUE_ADD 怎么选QUEUE_FLUSH会打断当前播报立刻播新的QUEUE_ADD会排队等当前播完再播。工业场景里报警信息必须用 FLUSH普通提示可以用 ADD。但要注意频繁调用 FLUSH 会导致引擎内部状态来不及复位出现吞字或重复。血泪经验是在调用 FLUSH 之前先调一次tts.stop()再speak给引擎一个明确的复位信号。另外播报完成回调UtteranceProgressListener里不要做耗时操作否则会阻塞引擎线程。4. 离线 TTS 避坑五个让 Demo 翻车的真实问题4.1 初始化成功但没声音现象onInit返回 SUCCESSspeak也调用了但设备静音。原因通常是媒体音量被调成 0或者音频流类型不对。解决检查AudioManager的STREAM_MUSIC音量并在speak的Bundle里指定KEY_PARAM_STREAM为AudioManager.STREAM_MUSIC。有些设备默认走通话流音量键调不动必须显式指定。4.2 中文读成英文或乱码现象数字和英文混排时引擎把中文也按英文音标读。原因setLanguage设置的语言和引擎实际加载的语音数据不匹配。解决先isLanguageAvailable(Locale.CHINA)判断再setLanguage并且确认引擎的默认语音是中文。如果引擎支持多语音用setVoice指定中文 voice而不是只设 language。4.3 首次播报延迟两三秒现象第一次speak要等很久才出声之后正常。原因引擎首次加载模型到内存属于冷启动。解决在应用启动时用一段空字符串或极短文本触发一次「预热」播报把模型加载提前。预热文本建议用「初始化」播报时把音量设 0 或直接 stop用户无感知。4.4 拷贝模型后引擎仍报数据缺失现象模型文件明明拷贝到私有目录了引擎还是说LANG_MISSING_DATA。原因引擎要求的路径不是getFilesDir()而是它自己约定的目录或者需要调用引擎特定的setModelPath接口。解决查引擎文档确认路径要求不要想当然。如果引擎没有公开接口考虑把模型放到外部存储的固定目录并申请读取权限。4.5 长时间播报内存溢出现象连续播报几十分钟后应用崩溃日志显示 OOM。原因每次speak都创建新的Bundle和回调对象引擎内部队列堆积。解决复用Bundle和UtteranceProgressListener实例控制队列长度超过阈值就stop清空。另外播报长文本时切成短句分段送入每段之间留 100ms 间隔给引擎释放缓冲的时间。5. 进阶验证怎么确认离线 TTS 真的没走网络5.1 用飞行模式和抓包双重验证最直接的验证方法打开飞行模式关掉 Wi-Fi跑一遍所有播报场景。如果全部正常说明离线路径通了。但飞行模式不能证明引擎没有尝试联网有些引擎会在后台静默请求。更严格的做法是用抓包工具看应用进程有没有 DNS 查询或 HTTP 请求。如果发现请求检查引擎的isNetworkConnectionRequired返回值并在代码里强制setEngineByPackageName锁定离线引擎。5.2 延迟与资源占用的量化指标离线 TTS 的核心指标有三个首字延迟、内存增量、CPU 占用。首字延迟指从调用speak到听到第一个字的时间冷启动建议控制在 500ms 以内热启动 200ms 以内。内存增量用Debug.MemoryInfo在播报前后各采一次正常应该在 10MB~30MB 之间超过 50MB 说明模型太大或泄漏。CPU 占用在播报时用top命令观察持续超过 15% 就要考虑降采样或换轻量模型。下面是一个简单的延迟测量代码片段。// 测量首字延迟记录 speak 调用时间和播报开始回调时间 long speakTime System.currentTimeMillis(); tts.setOnUtteranceProgressListener(new UtteranceProgressListener() { Override public void onStart(String utteranceId) { long latency System.currentTimeMillis() - speakTime; Log.d(TTS, 首字延迟 latency ms, id utteranceId); } Override public void onDone(String utteranceId) { } Override public void onError(String utteranceId) { } });逻辑说明onStart回调触发时引擎已经开始输出音频所以这个时间差就是首字延迟。注意speakTime要在speak之前记录且每次播报都要重置。参数上如果延迟超过 800ms优先检查模型是否放在慢速存储上或者引擎是否在后台做网络探测。5.3 一个我常用来做回归验证的小习惯每次改完 TTS 相关代码我不会只点一下按钮听个响就完事。我会准备一个包含 20 条文本的测试集纯中文、中英混排、纯数字、长句、短句、带标点、不带标点、多音字、生僻字、超长文本。然后写一个循环脚本逐条播报并记录延迟和是否报错。这个习惯帮我提前发现过好几次「某类文本在特定引擎上静默失败」的问题。离线 TTS 的坑大多不在主流程而在边界输入上。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
