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