简介：这是一份基于PocketSphinx的安卓离线语音识别Demo，面向需要在无网络环境下实现语音交互的Android开发者，尤其适用于智能助手、车载导航、智能家居等场景。资源共108个文件，约5.79MB，涵盖Java源码、XML布局/配置、Gradle构建脚本、so动态库，以及发音词典、语言模型、声学模型（如dic、lm、mdef等）和模型参数文件，结构清晰，便于直接导入Android Studio运行或对照二次开发。目前已有1488人学习下载。通过该Demo可完整了解离线识别的集成流程，包括添加库依赖、配置中英文模型、初始化识别器、用AudioRecord采集录音并送入引擎，以及处理识别回调和异常；同时可体验离线识别在隐私保护、实时响应和网络稳定性上的优势。内置可直接运行的示例界面与模型，是快速实现离线语音命令识别的实用起点。 搞安卓离线语音识别，最容易被卡住的不是算法，而是“选型”和“跑通 Demo”这两步。早年我在做智能家居控制模块时，被迫在“在线识别”和“离线识别”之间反复横跳，最终锁定 PocketSphinx 这个轻量级方案，才把体验拉回正轨。这篇就围绕一个最基础、也最实用的目标展开：在安卓端跑通 PocketSphinx Demo，并把它改造成一个真正能用的离线语音识别模块。
1. 为什么选 PocketSphinx 做离线识别
1.1 在线方案的三个痛点
先说说我为什么坚决要离线。当时项目场景是车内语音控制，网络信号在隧道和高架桥下极不稳定，如果用云端识别，每次请求要等网络往返，延迟忽高忽低，用户一旦连说三遍没反应，基本就会放弃这个功能。
在线识别的第二个痛点是隐私合规。音频数据要传到服务器，哪怕在传输过程加密，用户仍然会有顾虑。而离线识别把录音、解码、识别全部留在本机，音频不出设备，隐私上天然占优势。
第三个痛点是成本。在线方案按调用量计费，设备量大之后，每个月都是持续性的资金投入。离线方案是一次性集成，后续只费电，不费钱。综合下来，如果你的使用场景是固定命令词、封闭词汇表、网络不可控，那么第一选择就应该落到离线识别上。
1.2 PocketSphinx 的定位与优势
PocketSphinx 是卡内基梅隆大学 CMU Sphinx 语音识别工具包家族里的轻量级成员，专门为移动端和嵌入式设备设计。它体积小、无第三方服务依赖、完全本地解码，对安卓这种移动平台非常友好。
它支持三种主要的识别模式：
- 关键词唤醒（Keyword Spotting）：识别一个或几个固定的唤醒词，比如“你好小智”；
- 有限状态语法（FSG）：通过 JSGF 语法文件定义一组命令，比如开关灯、调音量；
- N-gram 语言模型：用于更自然的大词汇量识别，但模型体积和耗电都会明显上升。
对 Demo 阶段来说，前两种模式完全够用。我在项目里也是先用“固定语法”跑通空调控制，再用“关键词唤醒”做语音启动，最后才考虑引入语言模型做自由对话。
1.3 官方 Demo 能跑到什么程度
PocketSphinx 官方在 GitHub 提供了一份安卓 Demo，地址是 cmushinsky/pocketsphinx-android（注意是吃了官方重命名后的新组织名）。这份 Demo 不是我见过的那种“只给一堆代码让你自己拼”的半成品，而是可以直接跑的完整工程：它内置了英文模型、唤醒词配置、语法切换、实时听写示例，你只要花十几分钟构建一次，就能在真机上听到“Ready”、“Hello”等识别结果。
但这里要提个醒：默认模型是英文，如果你直接拿它做中文识别，是识别不出结果的。官方 Demo 的价值更多在于验证工程环境和理解 API 调用流程，中文场景需要额外替换语言模型，这一点我在后面单独展开。
2. 工程初始化和模型准备
2.1 用 Android Studio 拉取官方 Demo
我建议直接 Git Clone 官方 Repo，而不是从网页下载 Zip 再手动导入，因为后续可能得切换分支或者拉模型更新。命令行操作如下：
git clone https://github.com/cmushinsky/pocketsphinx-android.git然后打开 Android Studio，选 Open，定位到这个目录。Gradle 同步时如果网络不好可能会卡在依赖下载，尤其是 Google Maven 和 JCenter 这两个源。官方工程里的仓库地址通常已经配置好，但建议你打开根目录build.gradle确认一下：
allprojects { repositories { google() mavenCentral() } }注意：如果你的 Android Studio 版本太老，可能默认只认 JCenter，而 JCenter 现在已经只读甚至部分失效了。我在一台旧电脑上第一次同步就卡了二十分钟，最后把仓库地址改成 google() + mavenCentral() 才通过。
2.2 依赖导入与版本说明
如果你不打算直接用官方工程，而是想在自己的项目里集成 PocketSphinx，那么在app/build.gradle里加一行依赖就够了：
implementation 'edu.cmu.pocketsphinx:pocketsphinx-android:5.0.0'这个版本号是官方发布在 Maven Central 上的稳定版本。集成后需要注意，PocketSphinx 的原生库是带 SO 文件的，所以你要留意你的项目有没有做 ABI 过滤。如果你只保留arm64-v8a，在部分 32 位模拟器上可能会闪退，后面排查问题会专门讲。
至于为什么用 5.0.0 而不是其他版本，一方面是因为 5.x 修复了 4.x 时代在 Android 10+ 上的若干录音问题，另一方面是 API 更稳定，SpeechRecognizer的调用方式变化不大。如果你是从老教程里看到setupRecognizer和addKeywordSearch这些方法名，放心，它们还在。
2.3 模型文件放进 assets 的正确姿势
PocketSphinx 的模型文件是识别器的“灵魂”。官方 Demo 在app/src/main/assets/sync目录下放了一套英文模型，以及en-us的声学模型、字典和语言模型。为什么叫sync？这是官方 Demo 约定存放同步模型文件的目录，setupRecognizer会自动扫描这个路径下的模型文件。
如果你在自己的项目里集成，需要维护以下结构的模型目录：
assets/ └── sync/ ├── en-us-ptm/ │ ├── feat.params │ ├── mdef │ ├── means │ ├── noisedict │ ├── sendump │ ├── transition_matrices │ └── variance ├── en-us.lm.bin ├── en-us.dict └── cmudict-en-us.dict注意，en-us.dict是发音字典，cmudict-en-us.dict是扩充字典。如果词典里查不到你在语法里写的词，识别器会直接报错或者忽略该词，这是初学者最容易踩的坑。
3. 核心识别流程与 API 解析
3.1 SpeechRecognizer 初始化
整个 PocketSphinx 的核心就是一个SpeechRecognizer对象，它负责管理麦克风录音、前端信号处理、解码器状态和结果回调。初始化方式在官方 Demo 里是这样写的：
SpeechRecognizer recognizer = SpeechRecognizerSetup.defaultSetup() .setAcousticModel(new File(assetsDir, "en-us-ptm")) .setDictionary(new File(assetsDir, "cmudict-en-us.dict")) .getRecognizer(); recognizer.addListener(new RecognitionListener() { @Override public void onPartialResult(Hypothesis hypothesis) { if (hypothesis != null) { String text = hypothesis.getHypstr(); // 处理中间识别结果：常用于实时反馈“听到一半” } } @Override public void onResult(Hypothesis hypothesis) { if (hypothesis != null) { String text = hypothesis.getHypstr(); // 处理最终识别结果 } } @Override public void onTimeout() { // 检查到静音或超时 } });你会发现这里用到了assetsDir，它通常是从AssetManager拷贝出来的缓存路径：
File assetsDir = new File(getCacheDir(), "pocketsphinx"); Utils.copyAssets(getAssets(), "sync", assetsDir);为什么要拷贝到缓存目录，而不能直接读 assets？因为 PocketSphinx 底层是 C 实现的，需要通过文件系统路径读取声学模型和字典文件，安卓的 assets API 没法直接传给 native 层。这也是我最初困惑的地方：明明把模型放进了 assets，编译也没报错，运行时就一直找文件失败。
3.2 关键词搜索和语法搜索
初始化之后，最关键的是配置“搜索”。PocketSphinx 支持在同一识别器里注册多个搜索项，你可以随时切换。官方 Demo 的经典写法是：
recognizer.addKeywordSearch("wakeup", keywordFile); recognizer.addGrammarSearch("menu", grammarFile);这里keywordFile是一个关键词列表文件，内容是一行一个词或短语，例如：
hello pocket sphinx /1e-40/后面的阈值数字是关键词灵敏度，数值越小越“灵敏”但越容易误报，数值越大越“迟钝”但错报少。grammarFile是 JSGF 语法文件，内容类似：
#JSGF V1.0; grammar menu; public <command> = turn on the light | turn off the light | increase volume;这里推荐一个实操习惯：把 JSGF 语法里的词先用en-us.dict查一遍，确认每个词都有对应发音。没有发音的词直接删掉或换说法，不然整条语法都会失效。
3.3 结果回调与阈值调整
onPartialResult是识别到“中间结果”时回调，在持续监听模式下非常有用，可以做成边说边显示的效果。onResult是最终结果，当一段语音结束或检测到静音后触发。每次开始监听时，可以传入超时时间：
recognizer.startListening("menu", 3000);第二个参数 3000 表示 3 秒静音判定时间。如果没有有效语音，3 秒后触发onTimeout。这个值的设置很讲究：设得太短，用户在句子里稍微停顿一下就被判定结束；设得太长，识别响应会显得迟钝。我在实际调试中，控制命令场景用 2-3 秒比较舒服，唤醒词场景可以更短，比如 1 秒。
还有一个关键点是阈值。如果识别到大量莫名其妙的结果（没说的话也识别出来了），说明模型和阈值不匹配。常见处理策略是把关键词文件里的/1e-40/调成/1e-30/或更高，逐步试。注意细节：改动后要杀掉进程重跑，因为阈值在识别器启动时就已经加载到内存里。
4. 把 Demo 改造成可用的“语音开关”
4.1 一个最小可用的语音控制 Demo
官方 Demo 功能太多，反而不适合快速验证。我用一个最小的场景来示范：通过离线语音识别控制一个开关。核心代码可以浓缩成下面几段。
首先在布局里放一个TextView显示识别状态和结果，一个Button用来手动停止监听。然后在 MainActivity 里初始化识别器：
public class MainActivity extends AppCompatActivity implements RecognitionListener { private SpeechRecognizer recognizer; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); try { File assetsDir = new File(getCacheDir(), "pocketsphinx"); Utils.copyAssets(getAssets(), "sync", assetsDir); recognizer = SpeechRecognizerSetup.defaultSetup() .setAcousticModel(new File(assetsDir, "en-us-ptm")) .setDictionary(new File(assetsDir, "cmudict-en-us.dict")) .getRecognizer(); recognizer.addListener(this); File grammarFile = new File(assetsDir, "commands.gram"); recognizer.addGrammarSearch("switch", grammarFile); } catch (IOException e) { // 处理复制模型/初始化失败 } } @Override public void onResult(Hypothesis hypothesis) { if (hypothesis != null) { String command = hypothesis.getHypstr(); // 在这里判断命令并执行开关逻辑 } recognizer.startListening("switch", 2000); } @Override public void onPartialResult(Hypothesis hypothesis) { // 可忽略，也可以用于显示识别中间态 } @Override public void onTimeout() { recognizer.startListening("switch", 2000); } }这个 Demo 只做一件事：识别 “turn on the light” / “turn off the light”，识别成功后再次进入监听状态。注意onResult和onTimeout里都要重新startListening，否则只会识别一次就停了。这个“识别一次后自动续听”的逻辑是最容易漏掉的。
4.2 生命周期管理与释放
PocketSphinx 的 native 层占用内存不小，如果退出页面时不释放，再进一次会撑爆内存，严重的直接 OOM。正确做法是在onDestroy里清理：
@Override protected void onDestroy() { super.onDestroy(); if (recognizer != null) { recognizer.cancel(); recognizer.shutdown(); } }cancel是停止当前录音但不销毁上下文，shutdown是彻底释放资源。如果你的应用是一个常驻后台的服务，建议在服务被系统回收时也执行同样的释放逻辑，否则下次启动会出现“麦克风占用”或 “Failed to initialize recognizer” 的异常。
另外，SpeechRecognizer初始化必须在主线程完成。这是因为底层会绑定Looper来处理回调消息，如果在子线程初始化会出现状态错乱。我有一段时间把初始化放到线程池里，结果回调时好时坏，最后查源码才发现这个限制。
4.3 中文识别的替换方案
前面一直提英文模型，这里说中文。PocketSphinx 本身支持中文识别，前提是你要有中文声学模型和字典。而 CMU 官方并不直接提供高质量中文模型，网上能找到的多是社区训练版本，或者是针对特定场景（如电视语音遥控器）优化的词表模型。
我的经验是，如果只是做中文固定命令词识别，不要直接上大词表语言模型，而是先用一个有限的词表配合关键词搜索来跑。这样音频解码压力小，识别速度更快，误识别率也更容易控制。具体做法是在官方 Demo 的sync目录下替换en-us-ptm为中文声学模型，并把字典文件和语法文件改成中文词组。
如果你对模型训练没有把握，也可以考虑先使用 PocketSphinx 自带的拼音字典，中文词条按拼音拆成音节。比如“开关”写成 “kai guan”，确保字典里有对应的拼音发音。这种方案虽然不如现成模型完美，但 Demo 阶段完全足够，能让整个流程先跑起来，优先级最高。
5. 常见问题与排错实录
5.1 一直提示 Initialization failed
这个问题在直接在 Android 10 以上的真机最容易出现。主要原因有三个：一是WRITE_EXTERNAL_STORAGE或RECORD_AUDIO权限没给，二是在初始化时没有把 assets 里的模型拷贝到缓存目录，三是模型文件路径带上了中文字符或者空格。建议按顺序排查：先检查运行时权限，再打印拷贝后的文件名，最后确认 init 时拿到的路径存在。
有一个典型的细节：如果你在setAcousticModel里传的是 assets 原始路径，比如file:///android_asset/sync/en-us-ptm，这不会生效。因为 native 层拿不到 Android 的虚拟文件系统路径，必须用真实文件路径。
5.2 识别率差、识别不到关键词
识别率差最常见的原因是麦克风采样率不匹配。PocketSphinx 默认使用 16kHz 的音频流，但部分手机在通话模式下会把采样率强制改为 8kHz 或 44.1kHz，导致识别器收到的声音“变调”，结果自然对不上。解决方案是设置SpeechRecognizerSetup时指定采样率：
.setSampleRate(16000)如果已经设置了采样率还是识别不到，优先检查字典文件。字典文件里没有的词，无论语法怎么定义都不会被识别出来。我喜欢用一个笨办法：先把所有候选词在adb shell里跑一遍 pocketsphinx 的命令行工具，确认每个词都有发音条目，再拿到安卓端用。
5.3 延迟高、CPU 占用高
离线识别的优势本来就有低延迟这一项，如果延迟还是高，多半是语言模型太大或者 CPU 调的 core 数不够。官方默认的en-us.lm.bin有几十 MB，在低端机上解码开销不小。如果是固定命令词场景，强烈建议去掉语言模型，只用addKeywordSearch或addGrammarSearch，延迟能降到原来的三分之一。
CPU 占用高则与 VAD（语音活动检测）有关。PocketSphinx 里的SpeechRecognizerSetup会保留 VAD 功能，但如果触发过于频繁，后台耗电明显。可考虑在停止监听时调用recognizer.stopListening()，不要持续挂起识别线程，否则电池曲线会非常难看。
5.4 Demo 在模拟器上跑不起来
如果你的测试机是模拟器，大概率会遇到“麦克风不可用”或“音频输入初始化失败”。原因很简单：很多模拟器默认没有虚拟麦克风，或者输入源采样率不匹配。建议直接换真机测试，PocketSphinx 这类依赖真实录音的库，真机才是标准环境。
如果一定要在模拟器上跑，可以在 Android 模拟器配置里勾选“虚拟麦克风音频 input”，但依然要设置好宿主机的麦克风权限，效果也比较难保证。我的建议是：老老实实插一台真机，跑起来再回来改代码。
最后说个实在的：离线语音识别的坑不是算法，而是把“模型、字典、语法、采样率、生命周期”这五件事对齐。PocketSphinx 的优势在于轻量、可控、可定制，你不需要理解复杂的深度神经网络也能在几分钟内让一个可爱的小开关听懂指令。真机调试时，记得先拿官方 Demo 验证环境，再逐步加入自己的语法和逻辑。这套流程走通之后，你会发现离线识别并没有想象中那么高不可攀。
本文还有配套的精品资源，点击获取
