启动回调中立即结束会话
Session 发布 → onStart → writeAudio / finish / cancel → 回调门
onStart 表示会话已经可用，调用方可以在回调内同步结束或取消。适配层用 generation 与 gate 保护当前会话，防止旧 native 回调进入下一场会话，或在资源释放后继续返回结果。
Appearance
Skip to content
跳到项目内容Android 离线语音识别 Demo01 / 02 Android 与 HarmonyOS 使用不同原生桥接，共享推理能力。进程级模型资源与会话级音频状态分离，final 和 complete 受会话终态约束。
SDK 与交付/阶段交付
语音 SDK 与模型服务
原生离线语音、模型接口与多平台交付
01
核心业务
离线语音 SDK 面向 Android 与 HarmonyOS 原生应用，提供流式 ASR 和 TTS，并封装模型安装、许可证、会话创建和回调。底层复用 C++、sherpa-onnx 与 ONNX Runtime，平台层分别使用 Kotlin / JNI 和 ArkTS / N-API。
跨端接口相同不意味着线程和生命周期相同。模型属于进程级资源，会话持有自己的音频、解码和终态；业务回调又可能同步调用写入、结束或取消。SDK 需要在桥接、核心会话和业务适配层共同维护这一契约。
音频鉴伪作为独立模型服务纳入同一交付体系，提供文件输入、预处理、模型推理与检测结果接口。端侧语音 SDK、Windows 本地服务和私有 Docker 服务分别运行，复用模型资产校验、授权与制品验证方法。
- 运行时与资源
- Runtime 管理许可证、模型池和共享后处理，Engine 管理识别配置，Session 持有流与音频状态。
- 音频与文本
- PCM 输入经增益、切分、流式解码和最终文本处理；标点、ITN、声纹与领域处理各有入口。
- 宿主集成
- 原生接口、回调重入、资源释放、设备授权与 SDK / Demo 制品一起交付。
- 模型服务交付
- 语音能力以原生 SDK 接入宿主应用，鉴伪能力以本地 HTTP 服务或私有镜像对接业务系统；接口和运行依赖分别管理。
02
技术栈
- 公共推理
- C++ · sherpa-onnx · ONNX Runtime
- Android
- Kotlin · JNI · Gradle · AAR / APK
- HarmonyOS
- ArkTS · N-API · DevEco · HAR / HAP
- 授权与交付
- 离线许可证 · 设备绑定 · 模型清单与验签
03
系统架构与部署
Android
Kotlin / JNI / Gradle / AAR + APK接口适配、HandlerThread 调度、原生依赖与模型资源随宿主集成。
HarmonyOS
ArkTS / N-API / HAR + HAPPromise 串行队列、音频分发与回调门控制 native 重入和生命周期。
原生能力
C++ / sherpa-onnx / ONNX RuntimeRecognizer、Stream、VAD、标点、ITN、声纹和模型资产校验。
Windows 安装包
ZIP / Setup EXE / 便携 Python安装器解出解释器、依赖、模型和服务，注册 Windows Service。
推理变体
PyTorch-slim / ONNX Runtime CPU两种引擎独立构建、独立哈希与真机验证；ONNX 候选仍由 Python 承载。
私有服务器
Docker / Python 模型服务模型资产与服务镜像组织为独立交付，不用 Windows 验收替代服务端验证。
04
核心业务链路
一句话结束与整场识别结束
partial → isFinal → 继续输入；finish → isLast → onComplete
endpoint 可以产生多条 isFinal=true、isLast=false。只有显式结束或会话终止条件进入唯一的最后结果，再触发唯一 complete；cancel 路径不补 final 与 complete。长录音连续断句必须遵守这个区分。
05
关键机制与取舍
模型池复用与会话状态隔离
模型加载耗时且占用内存，如果每场会话重建就会增加启动成本；共享可变 VAD、Stream 或音频缓存又会产生串扰。
Runtime 管理按语言与配置组织的 Recognizer 池及共享后处理，会话持有独立流和音频状态。并发审查逐项核对模型对象可共享性与 VAD reset 的作用范围，不将所有 native 句柄视为无状态资源。
模型生命周期与录音生命周期可以分别处理，跨端修复围绕对象所有权进行。
解码、后处理与业务回调分开串行
decode、文本增强和宿主回调处在不同线程或语言边界，finish 与回调同步重入容易打乱最后结果顺序。
Android 会话使用解码、后处理和回调调度；Harmony 使用串行尾队列、音频分发与回调门。Core 与适配层共同保证 last / complete 的终止合同，并清理取消后的回调。
生命周期设计落到可检查的线程与状态对象，而不是只提供 start / stop 方法名。
授权与交付按设备和能力分别校验
ASR 与 TTS 能力、宿主设备指纹和模型资产需要与具体制品匹配，单独编译 SDK 不能证明客户可以运行。
为能力和设备生成独立授权产物，检查设备去重、签名、包内许可证和模型清单。SDK、Demo、原生依赖与集成文档分层组织，两端制品分别验收。
阶段授权覆盖 65 个唯一设备，ASR / TTS 两套授权包分别验签；这项结果对应授权产物完整性。
运行依赖决定主要包体
模型文件更换后，如果仍保留完整 PyTorch 与重复依赖，交付体积不会随引擎名称自然下降。
先建立 PyTorch 精简依赖变体，再为 ONNX Runtime 单独组织解释器、CPU Runtime 和 NumPy 预处理。候选保留独立版本和构建清单，安装与推理接口保持一致。
Windows 候选 PyTorch-slim 为 414.48 MiB，较基线减少 7.68%；ONNX 为 286.18 MiB，减少 36.26%。
卸载处理原生 DLL 的释放窗口
Windows 服务已经退出时，模型运行时 DLL 句柄仍可能延迟释放，直接删除目录会使卸载失败。
在卸载流程中处理服务停止与句柄释放时序，并在 Windows 真机检查安装目录、服务项和防火墙规则残留。
两种候选分别通过 9 项安装、运行和卸载验证；同一音频两引擎分数差约 2.384e-7，这一对照只对应当次样本。
06
实践成果与验证
Android / HarmonyOS
原生桥接
Kotlin / JNI 与 ArkTS / N-API 分别处理平台线程和采集生命周期。
Runtime / Session
两层生命周期
模型池复用与音频会话状态分开，终态约束贯穿 Core 和适配层。
65 个设备
阶段授权覆盖
唯一设备去重，ASR / TTS 独立授权包验签与完整性检查。
286.18 MiB
ONNX 候选包体
Windows x64 Python 承载方案，较原基线缩小 36.26%。
414.48 MiB
PyTorch 精简包体
保留 PyTorch 兼容路径，较基线缩小 7.68%。
9 / 9
各候选真机验收
Windows 11：离线安装、授权正反例、推理、服务、升级切换和卸载。
- 技术覆盖原生推理、音频处理、跨语言桥接、线程调度、设备授权与客户集成。
- 接口行为通过对象所有权与终态合同解释，便于处理长录音、回调重入和资源释放问题。
- 模型工程延伸到离线运行时、系统服务、安装生命周期与产物验证。
- 两条 Windows 工程候选具备绑定精确哈希的真机结果，平台矩阵仍区分各部署形态。
继续浏览
别急，先让缓存热一下。