簡(jiǎn)介本資源是一套面向移動(dòng)開發(fā)者的科大訊飛語音識(shí)別SDK全棧集成實(shí)踐包專為iOS與Android雙平臺(tái)語音轉(zhuǎn)文字功能快速落地而設(shè)計(jì)適用于具備基礎(chǔ)原生開發(fā)能力的中高級(jí)工程師及跨平臺(tái)項(xiàng)目技術(shù)負(fù)責(zé)人。壓縮包共299個(gè)文件涵蓋93個(gè)頭文件.h與46個(gè)實(shí)現(xiàn)文件.m構(gòu)成的核心SDK接入層33個(gè)HTML文檔與2個(gè)PDF提供API說明與官方指引30個(gè)PNG圖標(biāo)與3個(gè)Storyboard/XIB界面資源支撐Demo演示另有APPID配置、Bitcode關(guān)閉、日志等級(jí)控制等關(guān)鍵配置項(xiàng)的完整工程化實(shí)現(xiàn)。資源大小22.87MB結(jié)構(gòu)清晰含可直接運(yùn)行的SYDemo_iflyMSC_VoiceRecognizer-master示例工程、附贈(zèng)的.docx使用指南及.txt集成注意事項(xiàng)覆蓋從SDK下載、權(quán)限配置、框架依賴管理到真機(jī)調(diào)試的全流程排錯(cuò)要點(diǎn)。目前已有157人學(xué)習(xí)下載是少有的兼顧雙端適配、配置細(xì)節(jié)與實(shí)戰(zhàn)驗(yàn)證的語音識(shí)別集成參考方案。科大訊飛語音識(shí)別SDK集成從下載配置到雙平臺(tái)落地這篇把坑都給你踩平了做語音轉(zhuǎn)文字功能繞不開科大訊飛。不管你是要給App加一個(gè)語音搜索入口還是做會(huì)議記錄工具、語音輸入法甚至是智能硬件配套App訊飛的語音識(shí)別SDK都是國內(nèi)開發(fā)者最常用的方案之一。這段時(shí)間我剛好把一個(gè)支持iOS和Android雙平臺(tái)的語音轉(zhuǎn)文字功能從零到一完整集成了一遍整個(gè)過程涉及SDK下載、APPID配置、框架依賴管理、Bitcode關(guān)閉、日志等級(jí)控制這些環(huán)節(jié)踩了不少坑也積累了一些經(jīng)驗(yàn)整理出來給正準(zhǔn)備做這塊的同行參考。這篇文章適合誰看如果你準(zhǔn)備在自己的App里接入訊飛語音識(shí)別或者已經(jīng)接入了但遇到初始化失敗、識(shí)別無結(jié)果、編譯報(bào)錯(cuò)這類問題這篇文章都能幫到你。我會(huì)把雙平臺(tái)的集成步驟拆開講清楚并解釋每一步背后的原因同時(shí)附帶我實(shí)測(cè)遇到的坑和排查思路。1. 項(xiàng)目整體設(shè)計(jì)與技術(shù)選型思路1.1 為什么選擇科大訊飛SDK而不是其他方案語音識(shí)別這個(gè)領(lǐng)域可選方案其實(shí)不少。蘋果有自帶的Speech框架安卓也有Google的SpeechRecognizer還有一些開源的離線識(shí)別引擎。但我在這個(gè)項(xiàng)目里最終選了科大訊飛核心原因有三點(diǎn)。第一是識(shí)別準(zhǔn)確率尤其是中文場(chǎng)景。訊飛的語音識(shí)別模型針對(duì)普通話、方言、中英混合都有專門優(yōu)化實(shí)測(cè)下來在正常噪音環(huán)境下普通話識(shí)別的準(zhǔn)確率能到95%以上這個(gè)數(shù)據(jù)在嘈雜環(huán)境下對(duì)比系統(tǒng)自帶的識(shí)別方案有明顯優(yōu)勢(shì)。我之前用iOS原生的Speech框架做過測(cè)試在安靜環(huán)境下表現(xiàn)尚可但一旦有背景音樂或者多人說話識(shí)別率下跌非常明顯。第二是平臺(tái)一致性。用系統(tǒng)原生方案的話iOS和Android兩套代碼完全分開寫識(shí)別效果還不一樣。而訊飛SDK在雙平臺(tái)提供一致的接口和識(shí)別效果可以大幅減少跨平臺(tái)適配的工作量。對(duì)于需要雙端同時(shí)上線的產(chǎn)品來說這個(gè)一致性非常關(guān)鍵。第三是功能完整性。除了基礎(chǔ)的語音轉(zhuǎn)文字訊飛SDK還內(nèi)置了語義理解、關(guān)鍵詞喚醒、合成播報(bào)等能力。也就是說同一個(gè)SDK后續(xù)如果產(chǎn)品想加語音播報(bào)功能不需要再集成另一個(gè)SDK在工程依賴管理上能省不少事。當(dāng)然訊飛SDK也不是沒有缺點(diǎn)。最大的問題就是它依賴網(wǎng)絡(luò)離線模式下需要用離線資源包而且離線識(shí)別效果相比在線要差一些。另外就是SDK體積不小iOS端的靜態(tài)庫加上資源文件有幾十MB。如果你做的是工具類輕量App這個(gè)體積成本需要提前評(píng)估。但綜合來看對(duì)于大多數(shù)需要高質(zhì)量中文識(shí)別場(chǎng)景的產(chǎn)品訊飛依然是最穩(wěn)妥的選擇。1.2 雙平臺(tái)架構(gòu)設(shè)計(jì)要點(diǎn)我在設(shè)計(jì)這個(gè)語音轉(zhuǎn)文字功能時(shí)沒有直接在各端的業(yè)務(wù)代碼里到處調(diào)用SDK而是封裝了一層統(tǒng)一的語音識(shí)別服務(wù)層。iOS端我封裝了一個(gè)SpeechRecognizerManagerAndroid端封裝了一個(gè)SpeechRecognizerHelper對(duì)外暴露的接口保持一致主要就是開始識(shí)別、停止識(shí)別、設(shè)置回調(diào)這幾個(gè)方法。這么設(shè)計(jì)的好處是后續(xù)如果業(yè)務(wù)方想換識(shí)別引擎只需要改內(nèi)部實(shí)現(xiàn)上層業(yè)務(wù)代碼完全不用動(dòng)。這個(gè)項(xiàng)目的業(yè)務(wù)場(chǎng)景是在App內(nèi)的一個(gè)語音輸入框里用戶點(diǎn)擊語音按鈕開始說話說完自動(dòng)停止并返回識(shí)別文本。邏輯上看很簡(jiǎn)單但真正的復(fù)雜度在SDK的初始化、權(quán)限處理、音頻會(huì)話管理、生命周期綁定這些細(xì)節(jié)上。一個(gè)容易被忽視的點(diǎn)是語音識(shí)別是耗時(shí)操作而且涉及網(wǎng)絡(luò)請(qǐng)求和錄音必須在生命周期上做嚴(yán)格管理。比如iOS端如果你在ViewController里直接持有識(shí)別器頁面pop時(shí)沒有釋放很容易出現(xiàn)音頻會(huì)話被占用、識(shí)別回調(diào)野指針這類問題。Android端同樣Activity重建時(shí)如果沒處理好會(huì)導(dǎo)致內(nèi)存泄漏甚至崩潰。還有一個(gè)架構(gòu)層面的考慮是錯(cuò)誤處理。語音識(shí)別并不是每次都成功的網(wǎng)絡(luò)超時(shí)、用戶說話太短、權(quán)限被拒、音頻焦點(diǎn)被搶這些情況都要有明確的錯(cuò)誤回調(diào)并且要在UI上給出友好的提示。我在封裝層里統(tǒng)一做了錯(cuò)誤碼映射將SDK拋出的錯(cuò)誤碼轉(zhuǎn)換為業(yè)務(wù)可讀的錯(cuò)誤信息這樣UI層不需要關(guān)心SDK內(nèi)部的錯(cuò)誤碼含義。1.3 核心功能拆解整個(gè)語音轉(zhuǎn)文字功能可以拆成下面幾個(gè)模塊后續(xù)的集成工作也都是圍繞這些模塊展開的語音錄制模塊負(fù)責(zé)從麥克風(fēng)采集音頻數(shù)據(jù)iOS端依賴AVAudioEngineAndroid端依賴AudioRecord。識(shí)別引擎模塊封裝訊飛SDK的核心能力負(fù)責(zé)將音頻流轉(zhuǎn)為文字結(jié)果。權(quán)限管理模塊處理麥克風(fēng)權(quán)限的申請(qǐng)、狀態(tài)檢測(cè)和異常引導(dǎo)。音頻會(huì)話管理模塊處理錄音與其他音頻播放的沖突比如用戶一邊聽音樂一邊用語音輸入。UI交互模塊展示錄音狀態(tài)、音量波形、識(shí)別中間結(jié)果和最終結(jié)果。錯(cuò)誤處理模塊統(tǒng)一捕獲和展示識(shí)別過程中的各類異常。每個(gè)模塊都不復(fù)雜但組合在一起就有很多需要注意的細(xì)節(jié)。比如音頻會(huì)話管理iOS端如果沒有正確配置AVAudioSession的Category為PlayAndRecord可能會(huì)出現(xiàn)錄音沒聲音或者聲音特別小的問題。Android端如果沒處理好AudioManager的焦點(diǎn)請(qǐng)求可能會(huì)出現(xiàn)在播放音樂時(shí)無法錄音的情況。2. SDK下載與工程配置實(shí)操2.1 SDK下載與版本選擇科大訊飛的SDK分兩個(gè)版本語音識(shí)別在線版和離線版。在線版依賴網(wǎng)絡(luò)識(shí)別效果更好SDK體積更小離線版把識(shí)別模型打包在本地?zé)o需網(wǎng)絡(luò)但模型文件較大識(shí)別效果相對(duì)弱一些。我這次做的項(xiàng)目以在線識(shí)別為主所以選用的是在線版SDK。下載SDK時(shí)需要在訊飛開放平臺(tái)創(chuàng)建應(yīng)用綁定你的Bundle IDiOS和包名Android然后每個(gè)平臺(tái)單獨(dú)下載對(duì)應(yīng)的SDK包。這里有一個(gè)關(guān)鍵點(diǎn)iOS和Android的SDK是分開的不能混用每個(gè)平臺(tái)的SDK包都要在自己的應(yīng)用下單獨(dú)下載。我在實(shí)際操作中發(fā)現(xiàn)訊飛開放平臺(tái)下載SDK時(shí)會(huì)讓你勾選需要的功能模塊。最初我只勾選了語音聽寫后面發(fā)現(xiàn)還需要語音合成又重新下載了一次SDK。建議在第一次下載時(shí)就看清楚自己后續(xù)可能用到的功能一次性勾選避免后面反復(fù)折騰SDK替換。另外需要注意SDK版本兼容性。iOS端的SDK從5.x版本開始對(duì)Xcode版本有要求Android端SDK對(duì)minSdkVersion也有最低要求。我用的Android SDK要求minSdkVersion 21以上iOS SDK要求iOS 11.0以上。如果你的App還支持Android 4.0之類的老版本需要提前確認(rèn)你選的SDK版本是否兼容。2.2 iOS端SDK導(dǎo)入與框架依賴配置iOS端訊飛SDK以靜態(tài)庫的形式提供下載解壓后你會(huì)看到iflyMSC.framework。我使用的是Xcode 14以上版本集成過程大致如下第一步將iflyMSC.framework拖入工程的Frameworks目錄。拖入時(shí)需要注意勾選Copy items if needed否則framework不會(huì)被復(fù)制到工程目錄下?lián)Q一臺(tái)電腦或清理工程后就會(huì)出現(xiàn)找不到framework的問題。第二步配置依賴的系統(tǒng)框架。訊飛SDK底層依賴多個(gè)系統(tǒng)庫需要在Build Phases的Link Binary With Libraries里添加以下這些libz.tbdlibc.tbdAVFoundation.frameworkSystemConfiguration.frameworkCoreTelephony.frameworkAudioToolbox.frameworkCoreLocation.frameworkUIKit.frameworkQuartzCore.frameworkCoreGraphics.frameworkSecurity.framework大部分框架都是必備項(xiàng)漏掉任何一個(gè)編譯時(shí)都會(huì)報(bào)Undefined symbols錯(cuò)誤。我第一次集成時(shí)遺漏了libc.tbd結(jié)果編了半天都是各種奇怪報(bào)錯(cuò)最后仔細(xì)對(duì)比官方文檔才找到問題。第三步在Build Settings里關(guān)閉Bitcode。從Xcode 14開始Bitcode默認(rèn)是關(guān)閉的但如果你用的是Xcode 13或者更早版本需要手動(dòng)在Build Settings里搜索Bitcode將Enable Bitcode設(shè)置為NO。原因是訊飛SDK目前不支持Bitcode編譯模式不關(guān)閉的話在Archive導(dǎo)出時(shí)一定會(huì)報(bào)錯(cuò)。第四步配置Other Linker Flags。在Build Settings里搜索Other Linker Flags添加-ObjC標(biāo)志。這是因?yàn)橛嶏wSDK的靜態(tài)庫里使用了Objective-C分類Category如果不加-ObjC運(yùn)行時(shí)會(huì)出現(xiàn)方法找不到的crash報(bào)錯(cuò)類似unrecognized selector sent to instance。2.3 Android端SDK配置Android端集成訊飛SDK相對(duì)簡(jiǎn)單一些主要是把SDK包里的libs目錄下的內(nèi)容拷貝到你的工程對(duì)應(yīng)目錄里。我的工程是基于Gradle構(gòu)建的所以在集成時(shí)將訊飛SDK的jar包放到了app/libs目錄下將so文件放到了app/src/main/jniLibs目錄下。如果不需要支持armeabi架構(gòu)只需要保留armeabi-v7a和arm64-v8a即可。這里有個(gè)經(jīng)驗(yàn)so文件的目錄結(jié)構(gòu)必須嚴(yán)格對(duì)照加載時(shí)的架構(gòu)目錄放錯(cuò)位置會(huì)直接導(dǎo)致運(yùn)行時(shí)報(bào)dlopen failed: library not found。接下來在app的build.gradle里添加依賴聲明dependencies { implementation files(libs/SpeechLib.jar) }如果SDK包里有多個(gè)jar文件需要逐一添加或者使用fileTree方式批量引入dependencies { implementation fileTree(include: [*.jar], dir: libs) }然后需要在AndroidManifest.xml里聲明網(wǎng)絡(luò)權(quán)限和錄音權(quán)限uses-permission android:nameandroid.permission.RECORD_AUDIO / uses-permission android:nameandroid.permission.INTERNET / uses-permission android:nameandroid.permission.ACCESS_NETWORK_STATE / uses-permission android:nameandroid.permission.ACCESS_WIFI_STATE / uses-permission android:nameandroid.permission.CHANGE_NETWORK_STATE / uses-permission android:nameandroid.permission.READ_PHONE_STATE /要注意的是從Android 6.0開始錄音權(quán)限需要在運(yùn)行時(shí)動(dòng)態(tài)申請(qǐng)光在Manifest里聲明是不夠的。這塊我會(huì)在后面細(xì)說。另外如果你的App啟用了混淆minifyEnabled true需要在proguard-rules.pro里添加對(duì)應(yīng)的keep規(guī)則否則SDK的類會(huì)被混淆掉運(yùn)行時(shí)報(bào)ClassNotFoundException。訊飛官方文檔里提供了混淆配置示例直接復(fù)制進(jìn)你的混淆文件即可。2.4 日志等級(jí)控制調(diào)試與生產(chǎn)的平衡訊飛SDK默認(rèn)會(huì)輸出日志信息等級(jí)還特別詳細(xì)。在開發(fā)調(diào)試階段這些日志很有用但到了生產(chǎn)環(huán)境詳細(xì)的日志輸出不僅會(huì)拖慢性能還有可能把敏感信息打到日志里。訊飛SDK提供了日志等級(jí)控制的接口可以在初始化時(shí)設(shè)置。在iOS端是通過SpeechUtility的屬性配置[SpeechUtility createUtility:appidxxxxxxx,log_ht0,log_level5];log_level的可選值我實(shí)測(cè)下來可以在開發(fā)階段設(shè)為7全部日志上線前調(diào)整為3僅錯(cuò)誤日志或者直接設(shè)置為0。log_ht控制的是日志的審計(jì)等級(jí)和具體業(yè)務(wù)無關(guān)保持默認(rèn)即可除非你有合規(guī)要求需要關(guān)閉行為審計(jì)。在Android端是通過SpeechUtility對(duì)象的setParameter接口來控制SpeechUtility.createUtility(context, appid appId); // 開發(fā)階段打開日志生產(chǎn)環(huán)境關(guān)閉 SpeechUtility.getUtility().setParameter(SpeechConstant.LOG_LEVEL, 5);這里我的經(jīng)驗(yàn)是日志等級(jí)不要只依賴SDK的默認(rèn)值要在初始化時(shí)顯式設(shè)置。因?yàn)镾DK的默認(rèn)日志等級(jí)在不同版本里不一致顯式設(shè)置能保證你在測(cè)試階段拿到足夠的日志量同時(shí)在上線前可以把日志徹底關(guān)掉避免日志輸出帶來的性能損耗和隱私合規(guī)風(fēng)險(xiǎn)。3. APPID設(shè)置、初始化與語音轉(zhuǎn)文字核心流程實(shí)現(xiàn)3.1 APPID的獲取與初始化原理APPID是訊飛SDK的身份憑證相當(dāng)于你的App在訊飛服務(wù)器端的通行證。在訊飛開放平臺(tái)創(chuàng)建應(yīng)用后會(huì)生成一個(gè)唯一的APPID這個(gè)ID和你在創(chuàng)建應(yīng)用時(shí)填寫的Bundle IDiOS或包名Android是綁定的。SDK初始化時(shí)會(huì)把APPID以及設(shè)備相關(guān)信息打包發(fā)送給訊飛服務(wù)器服務(wù)器校驗(yàn)通過后才會(huì)返回合法的識(shí)別服務(wù)。如果APPID和Bundle ID不匹配初始化時(shí)可能不會(huì)報(bào)錯(cuò)但第一次發(fā)起識(shí)別時(shí)一定會(huì)報(bào)錯(cuò)錯(cuò)誤碼通常是21001或21002無效的APPID或鑒權(quán)失敗。初始化是使用SDK的第一步我的建議是在App啟動(dòng)時(shí)盡早執(zhí)行。iOS端可以在didFinishLaunchingWithOptions里初始化Android端可以在Application的onCreate里初始化。這樣做的好處是用戶首次點(diǎn)擊語音按鈕時(shí)SDK已經(jīng)就緒不需要額外的等待時(shí)間。iOS端的初始化代碼// AppDelegate.m - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { NSString *initParam [NSString stringWithFormat:appid%, 你的APPID]; [SpeechUtility createUtility:initParam]; return YES; }Android端的初始化代碼// Application.class Override public void onCreate() { super.onCreate(); SpeechUtility.createUtility(this, appid 你的APPID); }這里有幾個(gè)細(xì)節(jié)值得注意。首先APPID不要硬編碼在代碼里建議通過BuildConfig字段或配置文件注入。這樣后續(xù)如果更換APPID不需要重新編譯整個(gè)App。其次初始化方法有可能失敗比如網(wǎng)絡(luò)問題雖然SDK沒有直接提供同步的初始化結(jié)果回調(diào)但你可以在第一次使用SDK時(shí)主動(dòng)檢查SpeechUtility的狀態(tài)避免在未初始化成功的狀態(tài)下直接調(diào)用識(shí)別接口。3.2 iOS端語音轉(zhuǎn)文字核心實(shí)現(xiàn)iOS端我使用的是訊飛的語音聽寫IAT功能核心類有IFlySpeechRecognizer和IFlyRecognizerView。前者是底層接口可以更精細(xì)地控制識(shí)別過程后者是封裝好的UI組件自帶語音波形動(dòng)畫和識(shí)別結(jié)果展示。我使用的是前者因?yàn)閁I層需要和產(chǎn)品的設(shè)計(jì)統(tǒng)一。先說配置音頻會(huì)話。我用的是AVAudioSession的PlayAndRecord模式并且開啟了揚(yáng)聲器路由因?yàn)椴糠諥ndroid轉(zhuǎn)iOS過來的用戶習(xí)慣聽筒播放但識(shí)別場(chǎng)景下?lián)P聲器更合適AVAudioSession *session [AVAudioSession sharedInstance]; [session setCategory:AVAudioSessionCategoryPlayAndRecord withOptions:AVAudioSessionCategoryOptionDefaultToSpeaker error:nil]; [session setActive:YES error:nil];然后初始化識(shí)別器并設(shè)置識(shí)別參數(shù)IFlySpeechRecognizer *recognizer [IFlySpeechRecognizer sharedInstance]; [recognizer setParameter: forKey:[IFlySpeechConstant PARAMS]]; [recognizer setParameter:iat forKey:[IFlySpeechConstant IFLY_DOMAIN]]; [recognizer setParameter:16000 forKey:[IFlySpeechConstant SAMPLE_RATE]]; [recognizer setParameter:zh_cn forKey:[IFlySpeechConstant LANGUAGE]]; [recognizer setParameter:mandarin forKey:[IFlySpeechConstant ACCENT]]; [recognizer setParameter:20000 forKey:[IFlySpeechConstant SPEECH_TIMEOUT]]; [recognizer setParameter:2000 forKey:[IFlySpeechConstant VAD_EOS]]; [recognizer setParameter:5000 forKey:[IFlySpeechConstant VAD_BOS]]; [recognizer setParameter:1 forKey:[IFlySpeechConstant ASR_PTT]]; recognizer.delegate self;參數(shù)里比較關(guān)鍵的是VAD_BOS和VAD_EOS。VAD_BOS是開始說話的超時(shí)時(shí)間意思是用戶點(diǎn)擊錄音按鈕后多久沒有說話就自動(dòng)結(jié)束識(shí)別VAD_EOS是說話結(jié)束后的靜默檢測(cè)時(shí)間即用戶說完話后安靜多久視為一句話結(jié)束。我們的產(chǎn)品場(chǎng)景是短句聽寫所以VAD_EOS設(shè)置的是2000毫秒如果做長(zhǎng)段語音轉(zhuǎn)寫這個(gè)值需要適當(dāng)調(diào)大。識(shí)別結(jié)果的回調(diào)在IFlySpeechRecognizerDelegate里。核心回調(diào)有兩個(gè)// 識(shí)別結(jié)果回調(diào) - (void)onResults:(NSArray *)results isLast:(BOOL)isLast { NSMutableString *resultString [NSMutableString string]; for (NSDictionary *dic in results) { NSDictionary *head [dic objectForKey:ws]; for (NSDictionary *subDic in head) { NSArray *cwArray [subDic objectForKey:cw]; for (NSDictionary *cwDic in cwArray) { NSString *word [cwDic objectForKey:w]; [resultString appendString:word]; } } } }這里的結(jié)果是增量的也就是說每次回調(diào)返回的是從開始說話到當(dāng)前時(shí)刻識(shí)別出來的文本片段需要在UI上做追加或替換展示。我在實(shí)現(xiàn)時(shí)維護(hù)了一個(gè)NSMutableString每次回調(diào)直接把新內(nèi)容追加進(jìn)去然后更新UI。注意如果設(shè)置了ASR_PTT為1開啟標(biāo)點(diǎn)預(yù)測(cè)結(jié)果里會(huì)帶有標(biāo)點(diǎn)符號(hào)需要在拼接時(shí)一并保留。結(jié)束時(shí)有一個(gè)單獨(dú)的回調(diào)- (void)onEndOfSpeech { // 用戶說話結(jié)束停止錄音等待最終結(jié)果 }需要在onEndOfSpeech里停止錄音同時(shí)處理UI狀態(tài)切換。這個(gè)回調(diào)意味著SDK已經(jīng)開始處理識(shí)別的最后一段音頻了此時(shí)不能再發(fā)送新的音頻數(shù)據(jù)。3.3 Android端語音轉(zhuǎn)文字核心實(shí)現(xiàn)Android端訊飛SDK的核心類結(jié)構(gòu)跟iOS端不一樣不能直接平移接口代碼。使用識(shí)別功能主要依賴SpeechRecognizer和RecognizerListener兩個(gè)類。初始化方式類似但參數(shù)設(shè)置走的是另一套API。我踩過一個(gè)坑Android SDK的識(shí)別參數(shù)key和iOS端不同比如采樣率的key在Android端是SpeechConstant.SAMPLE_RATE在iOS端卻是IFlySpeechConstant.SAMPLE_RATE。如果你是從iOS端平移到Android端需要特別留意這些常量差異。Android端的核心調(diào)用代碼SpeechRecognizer recognizer SpeechRecognizer.createRecognizer(context, initListener); recognizer.setParameter(SpeechConstant.DOMAIN, iat); recognizer.setParameter(SpeechConstant.LANGUAGE, zh_cn); recognizer.setParameter(SpeechConstant.ACCENT, mandarin); recognizer.setParameter(SpeechConstant.SAMPLE_RATE, 16000); recognizer.setParameter(SpeechConstant.ASR_PTT, 1); recognizer.setParameter(SpeechConstant.RESULT_TYPE, json);注意這里的RESULT_TYPE我用的是JSON因?yàn)镾DK返回的原始文本格式是JSON需要自行解析。也可以用SDK內(nèi)置的JsonParser工具類來解析訊飛SDK包里自帶了JsonParser和FucUtil兩個(gè)工具類直接拷貝到工程里用即可。監(jiān)聽器關(guān)鍵回調(diào)Override public void onResult(RecognizerResult results, boolean isLast) { String text JsonParser.parseIatResult(results.getResultString()); // 更新UI展示 }與iOS不同Android端的onResult返回的是一個(gè)完整的階段性結(jié)果而不是增量片段。也就是說每次回調(diào)返回的都是從開始到當(dāng)前的完整識(shí)別文本。在UI上你是直接替換整個(gè)文本而不是追加。這個(gè)差異如果不注意會(huì)出現(xiàn)文字重復(fù)顯示的問題。另外Android端還有一個(gè)很關(guān)鍵的點(diǎn)識(shí)別結(jié)束時(shí)需要在onEndOfSpeech回調(diào)里調(diào)用recognizer.cancel()或recognizer.stopListening()來釋放資源否則下一次識(shí)別可能無法正常啟動(dòng)。我在第一次做的時(shí)候忽略了導(dǎo)致連續(xù)識(shí)別兩次后第三次點(diǎn)擊語音按鈕沒反應(yīng)排查了很久才發(fā)現(xiàn)是SDK實(shí)例沒有正確釋放。3.4 權(quán)限請(qǐng)求與動(dòng)態(tài)處理雙平臺(tái)都需要處理麥克風(fēng)權(quán)限。iOS端在Info.plist里添加NSMicrophoneUsageDescription說明使用目的。如果缺少這個(gè)描述調(diào)用錄音接口時(shí)App會(huì)直接崩潰。Android端從6.0開始需要在運(yùn)行時(shí)動(dòng)態(tài)申請(qǐng)RECORD_AUDIO權(quán)限不能只在Manifest里聲明。我一般會(huì)封裝一個(gè)權(quán)限檢查工具在錄音前先檢查權(quán)限如果沒有授權(quán)就彈出系統(tǒng)授權(quán)框拒絕授權(quán)后引導(dǎo)用戶前往設(shè)置頁開啟。這里有一個(gè)好習(xí)慣在錄音按鈕點(diǎn)擊之前就檢查權(quán)限而不是在點(diǎn)擊之后。因?yàn)槿绻脩酎c(diǎn)了錄音按鈕才發(fā)現(xiàn)權(quán)限被拒體驗(yàn)比較突兀。更好的做法是在頁面初次展示時(shí)檢查權(quán)限如果未授權(quán)在按鈕位置提示需要麥克風(fēng)權(quán)限才能使用語音輸入引導(dǎo)用戶開啟。我還遇到過一個(gè)Android的坑在部分國產(chǎn)ROM上即使App申請(qǐng)了錄音權(quán)限也必須在系統(tǒng)設(shè)置里開啟麥克風(fēng)權(quán)限的后臺(tái)錄音開關(guān)否則息屏錄音會(huì)中斷。這讓錄音權(quán)限的檢查邏輯變得復(fù)雜我的處理方式是錄音過程中監(jiān)聽onError回調(diào)如果錯(cuò)誤碼是20021錄音權(quán)限被拒絕或10110錄音啟動(dòng)失敗就提示用戶檢查系統(tǒng)錄音權(quán)限設(shè)置。4. 常見問題與排查技巧實(shí)錄4.1 初始化失敗與鑒權(quán)錯(cuò)誤這類錯(cuò)誤是最常見的。iOS端表現(xiàn)是運(yùn)行時(shí)報(bào)Please check the network或Invalid appidAndroid端表現(xiàn)是初始化方法走fail回調(diào)錯(cuò)誤碼20001或21001。排查思路先確認(rèn)三件事APPID是否正確、APPID綁定的Bundle ID或包名是否和當(dāng)前運(yùn)行工程的Bundle ID或包名一致、SDK版本是否和創(chuàng)建應(yīng)用時(shí)選擇的SDK類型一致。有一個(gè)容易忽略的點(diǎn)如果你的App做了多環(huán)境配置比如Debug和Release使用不同的Bundle ID需要在訊飛開放平臺(tái)把每個(gè)Bundle ID都綁定到同一個(gè)APPID下或者分別創(chuàng)建不同的應(yīng)用。我曾經(jīng)因?yàn)镈ebug和Release的Bundle ID不同導(dǎo)致Debug環(huán)境下初始化正常Release環(huán)境下一直鑒權(quán)失敗排查了很久才發(fā)現(xiàn)是這個(gè)問題。4.2 Bitcode相關(guān)的編譯和打包錯(cuò)誤iOS端如果忘了關(guān)閉Bitcode在模擬器上編譯可能不會(huì)報(bào)錯(cuò)但在真機(jī)調(diào)試或Archive導(dǎo)出時(shí)必報(bào)錯(cuò)。錯(cuò)誤一般長(zhǎng)這樣Invalid Bitcode... (cannot load libiflyMSC.a)。這里注意關(guān)閉Bitcode的位置有三個(gè)Project的Build Settings、Target的Build Settings以及如果使用了CocoaPods還要檢查Pods工程的Build Settings。只改Target層面的設(shè)置有時(shí)候會(huì)被Pods工程覆蓋掉最穩(wěn)妥的辦法是同時(shí)把這三處全部設(shè)為NO。4.3 Android端so文件找不到運(yùn)行時(shí)報(bào)java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader... couldnt find libmsc.so這是典型的so文件放置或加載配置問題。檢查兩點(diǎn)一是so文件是否放在jniLibs目錄下且目錄層級(jí)正確比如arm64-v8a目錄下不能直接放一個(gè)so文件應(yīng)該在src/main/jniLibs/arm64-v8a/目錄下。二是如果使用了externalNativeBuild或其他ABI過濾配置需要在build.gradle的defaultConfig里顯式聲明ndk配置ndk { abiFilters armeabi-v7a, arm64-v8a }如果不加這個(gè)配置某些設(shè)備上可能加載不到對(duì)應(yīng)架構(gòu)的so文件。另外如果你的工程里同時(shí)集成了多個(gè)包含so文件的SDK要注意各SDK支持的ABI架構(gòu)集合取交集才不會(huì)出問題。4.4 識(shí)別結(jié)果為空或超時(shí)用戶明明說話了但SDK返回的結(jié)果為空或者一直不回調(diào)結(jié)果。這里有幾種情況需要區(qū)分。如果是在模擬器上測(cè)試那什么都說明不了——模擬器無法正常使用麥克風(fēng)錄音會(huì)導(dǎo)致識(shí)別一直超時(shí)。這個(gè)問題在Android模擬器上尤其明顯我的建議是語音識(shí)別功能一定用真機(jī)測(cè)試。是在真機(jī)上測(cè)試但識(shí)別超時(shí)先檢查網(wǎng)絡(luò)。訊飛在線識(shí)別是實(shí)時(shí)上傳音頻流到服務(wù)器網(wǎng)絡(luò)不穩(wěn)定會(huì)直接導(dǎo)致識(shí)別超時(shí)?？梢杂脼g覽器訪問訊飛開放平臺(tái)來確認(rèn)網(wǎng)絡(luò)通暢。還有一種情況SDK回調(diào)了onError錯(cuò)誤碼是10110或10112。這兩個(gè)錯(cuò)誤碼分別表示錄音失敗和錄音超時(shí)。出現(xiàn)10110時(shí)優(yōu)先檢查麥克風(fēng)權(quán)限和錄音過程中是否被其他應(yīng)用占用了音頻資源比如插了藍(lán)牙耳機(jī)、正在通話、或者有別的應(yīng)用正在使用麥克風(fēng)。出現(xiàn)10112時(shí)大概率是VAD_BOS設(shè)置得太短用戶點(diǎn)擊按鈕后猶豫了一下沒有說話就觸發(fā)了自動(dòng)結(jié)束。我把這些經(jīng)驗(yàn)整理成一張速查表方便遇到問題時(shí)對(duì)照排查錯(cuò)誤碼含義排查方向21001無效APPID檢查APPID、Bundle ID/包名綁定關(guān)系21002鑒權(quán)失敗檢查應(yīng)用是否人工審核通過網(wǎng)絡(luò)是否正常10110錄音失敗檢查麥克風(fēng)權(quán)限、音頻焦點(diǎn)沖突10112錄音超時(shí)檢查VAD_BOS參數(shù)、麥克風(fēng)設(shè)備是否正常20021網(wǎng)絡(luò)異常檢查網(wǎng)絡(luò)連接確認(rèn)無防火墻攔截20001內(nèi)部錯(cuò)誤初始化狀態(tài)、SDK版本兼容性4.5 音頻沖突與多場(chǎng)景切換語音識(shí)別功能最麻煩的不是集成本身而是和各種音頻場(chǎng)景的協(xié)作。我遇到過兩個(gè)比較典型的問題。第一個(gè)是用戶在用語音識(shí)別時(shí)App正在播放音頻。iOS端如果AVAudioSession的Category設(shè)置不當(dāng)可能導(dǎo)致錄音的聲音很小或者完全沒聲音。我的解決方法是啟動(dòng)識(shí)別前將Category設(shè)為PlayAndRecord并帶上DefaultToSpeaker選項(xiàng)識(shí)別結(jié)束時(shí)恢復(fù)原來的Category。第二個(gè)是App切到后臺(tái)再回前臺(tái)識(shí)別中斷。這種情況需要在前臺(tái)恢復(fù)時(shí)重新初始化識(shí)別器。我在實(shí)現(xiàn)時(shí)監(jiān)聽UIApplicationDidBecomeActiveNotification在重新進(jìn)入前臺(tái)時(shí)檢查當(dāng)前識(shí)別器的狀態(tài)如果識(shí)別中斷了就提示用戶重新開始。Android端也有類似問題不過是AudioFocus機(jī)制。啟動(dòng)識(shí)別前需要請(qǐng)求AudioFocus識(shí)別結(jié)束時(shí)釋放AudioFocus。如果不做這個(gè)處理微信語音等應(yīng)用播放消息時(shí)會(huì)搶占你的錄音焦點(diǎn)導(dǎo)致錄音中斷。4.6 真實(shí)項(xiàng)目中的踩坑總結(jié)做這個(gè)項(xiàng)目最大的體會(huì)是訊飛SDK的文檔很全但比較零散很多細(xì)節(jié)藏在FAQ和各種錯(cuò)誤碼解釋里。真正進(jìn)入實(shí)操時(shí)會(huì)遇到文檔沒寫清楚的邊緣情況。我把這次實(shí)踐中最有價(jià)值的幾個(gè)經(jīng)驗(yàn)記錄下來。第一是SDK的初始化盡量早但也不要在Application的onCreate里做太多事情否則會(huì)因?yàn)閱?dòng)耗時(shí)被系統(tǒng)判定為卡頓。Android端可以將初始化放到一個(gè)后臺(tái)線程里但要注意SDK的createUtility方法要求必須在主線程調(diào)用這個(gè)在官方文檔里有說明。第二是雙平臺(tái)的結(jié)果解析方式完全不同。iOS端返回的是增量片段Android端返回的是累計(jì)完整結(jié)果。如果兩端用同一套業(yè)務(wù)代碼邏輯處理一定會(huì)出問題。我建議在封裝層就把這個(gè)差異消化掉對(duì)外統(tǒng)一暴露識(shí)別文本的接口即可。第三是訊飛SDK的日志。如果你遇到一個(gè)SDK返回的錯(cuò)誤碼在文檔里查不到或者報(bào)錯(cuò)信息很抽象先把日志等級(jí)開到最高看看SDK打印的完整錯(cuò)誤信息。很多時(shí)候SDK內(nèi)部會(huì)把真正的錯(cuò)誤原因打在日志里只是錯(cuò)誤碼沒有體現(xiàn)出來。我之前遇到過一個(gè)問題SDK返回的是通用錯(cuò)誤碼20001但日志里明確寫著Invalid parameter: vad_eos30000后來發(fā)現(xiàn)是參數(shù)值的類型問題——Android端要求字符串類型的數(shù)字我傳了整數(shù)類型SDK雖然沒崩潰但校驗(yàn)失敗了。5. 雙平臺(tái)聯(lián)調(diào)與性能優(yōu)化補(bǔ)充5.1 識(shí)別的性能指標(biāo)與體驗(yàn)優(yōu)化對(duì)于語音轉(zhuǎn)文字類功能用戶體驗(yàn)很大程度上取決于識(shí)別延遲。我實(shí)測(cè)了訊飛在線識(shí)別的幾個(gè)關(guān)鍵指標(biāo)從點(diǎn)擊錄音到SDK回調(diào)出第一個(gè)中間結(jié)果穩(wěn)定網(wǎng)絡(luò)環(huán)境下大約需要400到700毫秒VAD_EOS設(shè)置為2000毫秒時(shí)一句話說完到拿到完整結(jié)果大約需要1到2秒。這個(gè)延遲對(duì)大多數(shù)交互場(chǎng)景來說是可接受的但如果你的App對(duì)實(shí)時(shí)性要求很高比如做同聲傳譯或?qū)崟r(shí)字幕有幾個(gè)優(yōu)化手段可以試試。第一是調(diào)整VAD_EOS參數(shù)。VAD_EOS設(shè)置得越短識(shí)別的完整度越低但響應(yīng)越快設(shè)置得越長(zhǎng)每條結(jié)果的完整性越高但用戶等待最終結(jié)果的時(shí)間越長(zhǎng)。我在實(shí)測(cè)中發(fā)現(xiàn)VAD_EOS從2000毫秒調(diào)到1500毫秒后完整結(jié)果的返回速度提升明顯但偶爾會(huì)把兩句話識(shí)別成一句話中間短停頓沒觸發(fā)斷句。這個(gè)閾值需要根據(jù)自己的場(chǎng)景多測(cè)幾次。第二是采樣率的選擇和結(jié)果的展示策略。訊飛SDK支持16000和8000采樣率。16000是寬頻識(shí)別效果更好推薦使用8000是窄頻適合電話語音場(chǎng)景但識(shí)別率相對(duì)較低不建議在App場(chǎng)景使用。第三是如果不需要實(shí)時(shí)展示中間結(jié)果可以在UI上做一個(gè)500毫秒的延遲刷新避免中間結(jié)果頻繁刷新導(dǎo)致界面閃爍。但如果需要實(shí)時(shí)字幕類體驗(yàn)就不要做這個(gè)延遲。5.2 內(nèi)存與電量?jī)?yōu)化移動(dòng)端的語音識(shí)別需要持續(xù)錄音并上傳音頻流這個(gè)過程會(huì)消耗一定的電量和內(nèi)存。在雙平臺(tái)聯(lián)調(diào)時(shí)我注意到iPhone會(huì)比Android設(shè)備在錄音耗電上略小但差別不大。從內(nèi)存占用角度看iOS端IFlySpeechRecognizer使用單例模式內(nèi)存占用相對(duì)穩(wěn)定。Android端每次創(chuàng)建SpeechRecognizer實(shí)例如果不正確銷毀會(huì)產(chǎn)生內(nèi)存泄漏。我在代碼里做了引用計(jì)數(shù)管理頁面onDestroy時(shí)調(diào)用destory()識(shí)別結(jié)束時(shí)調(diào)用cancel()。另外一個(gè)容易被忽略的點(diǎn)是音頻格式的默認(rèn)參數(shù)。Android端如果使用默認(rèn)的PCM格式識(shí)別過程中音頻數(shù)據(jù)量很大對(duì)流量和電量的影響都不可忽視。我建議打開SDK的音頻壓縮功能。在Android端通過setParameter(SpeechConstant.AUDIO_SOURCE, 1)開啟麥克風(fēng)音頻流壓縮可以減少約50%的數(shù)據(jù)量識(shí)別效果幾乎沒有影響。5.3 斷網(wǎng)與弱網(wǎng)環(huán)境下的降級(jí)處理在線識(shí)別引擎對(duì)網(wǎng)絡(luò)依賴很強(qiáng)。弱網(wǎng)環(huán)境下雖然SDK內(nèi)部有超時(shí)重傳機(jī)制但體驗(yàn)會(huì)明顯下降。作為使用者需要在上層做降級(jí)處理。我這邊做了兩個(gè)降級(jí)方案一是網(wǎng)絡(luò)斷開時(shí)檢測(cè)到錯(cuò)誤碼20021直接提示用戶檢查網(wǎng)絡(luò)不把用戶晾在錄音界面。二是如果產(chǎn)品后續(xù)接入離線識(shí)別可以在弱網(wǎng)環(huán)境下自動(dòng)切換到離線識(shí)別用低一點(diǎn)的成功率換取可用性。這兩種方案的成本差異較大。方案一只需要錯(cuò)誤處理邏輯方案二需要額外下載離線資源包并且離線識(shí)別效果需要測(cè)試。如果你的產(chǎn)品主要面向國內(nèi)用戶且用戶的網(wǎng)絡(luò)環(huán)境普遍穩(wěn)定方案一足夠用了。6. 寫在最后的經(jīng)驗(yàn)話科大訊飛語音識(shí)別SDK的集成本質(zhì)上沒有太高的技術(shù)難度真正的門檻在于對(duì)文檔細(xì)節(jié)的熟悉度和對(duì)平臺(tái)差異的處理。你如果準(zhǔn)備做類似的功能我的建議是不要一上來就想著把所有參數(shù)都吃透先跑通最簡(jiǎn)單的在線識(shí)別鏈路再把音頻會(huì)話、權(quán)限、生命周期、錯(cuò)誤處理這些外圍細(xì)節(jié)逐步補(bǔ)齊。我自己在集成過程中踩得最深的坑就是調(diào)試時(shí)用的模擬器和真機(jī)行為差異。很多問題在模擬器上不出現(xiàn)一上真機(jī)就出問題。尤其是在語音識(shí)別這種強(qiáng)依賴硬件和系統(tǒng)的功能上從第一天開始就堅(jiān)持在真機(jī)上調(diào)試能幫你省下大量的排查時(shí)間。另外訊飛SDK的版本更新速度不算快但每次更新都可能帶來參數(shù)或接口層面的變化。如果你在集成時(shí)發(fā)現(xiàn)官方文檔的示例代碼和你下載的SDK對(duì)不上優(yōu)先以SDK包內(nèi)的頭文件注釋和Demo工程為準(zhǔn)。我用的版本里就遇到了文檔寫的是舊接口、SDK里已經(jīng)更新為新接口的情況對(duì)照文檔寫代碼反而報(bào)錯(cuò)。語音轉(zhuǎn)文字功能做完之后后續(xù)還可以擴(kuò)展的方向不少。比如加一個(gè)語音合成功能讓識(shí)別結(jié)果可以播報(bào)出來或者把識(shí)別引擎換成離線模式做成完全本地化的語音輸入。這些擴(kuò)展都基于訊飛SDK底層的工程接入邏輯已經(jīng)打通了剩下的就是業(yè)務(wù)層面的迭代。希望這篇分享能幫你少走一些彎路。本文還有配套的精品資源點(diǎn)擊獲取