基於React-Native0.55.4的語音辨識項目全棧方案

標籤：href   人力   無法   dia   回調   怎麼   效能   code   間接   

移動端的API能力驗證方案與PC端不一樣！不一樣！！不一樣！！！

即使需要使用的API都存在，也不一定能用，這一點和PC端是有很大區別的，國內的手機系統雖然都是基於Android,但幾乎都會經過各大廠商的定製，功能與原版Android系統並不是完全一致的，在考察技術方案的時候一定要確認用demo把功能跑起來才可以，別問我怎麼知道的。

一. 移動端直接存取Web應用？

PC端基於Web API的語音辨識方案可參考《【Recorder.js+百度語音辨識】全棧方案技術細節》一文。

1. 調用Web API的多媒體採集介面需要特定的域

Web API的多媒體介面是WebRTC技術在PC端的實現，由於多媒體採集涉及到使用者隱私，所以在瀏覽器端調用這個介面需要在安全的域下才能被調起，安全的域是指以下三類：

• file:///本地區
• http://localhost本地web伺服器
• https://安全域

前兩類一般用於案頭應用和本地調試，實際網站上線部署需要以https方式部署，如何部署https及申請免費的CA認證等網上有很多文章講解，本文不再贅述。

2. 手機瀏覽器幾乎都不直接支援WebRTC 介面

將PC端的Web應用以https方式部署好之後，從手機瀏覽器直接存取時無法喚起錄音介面許可權認證，navigator.getUserMedia( )方法一隻返回permissionDenied錯誤，無論是在Android6.0以下通過編輯manifest.xml添加還是Android6.0以上通過動態擷取的方式取得RECORD_AUDIO許可權，網站都可以正常訪問，相關的Web API介面也都存在，但即使獲得使用者授權後也無法調起錄音功能。筆者測試了UC瀏覽器，百度行動瀏覽器和Android6.0(API23)內建的瀏覽器，Android8.0(API26)內建的瀏覽器,結果是都不支援。

二. 方案調研和新的坑

o(￣▽￣)d 既然從移動端直接存取Web應用時無法調起錄音介面，至少是無法相容很多系統和機型，如果不考慮直接原生開發Android的話，只有寄希望於Hybrid的方案了。

2.1 WebView

• 方案：

  在一個app中單頁面全屏放置一個WebView組件，然後載入https方式部署的web應用。

• 理由：

  手機瀏覽器無法支援的情況下，只能寄希望於WebView。WebView是Android底層用於載入網頁的組件，Android4.4版本以後已將內建的瀏覽器引擎更換為chromium，也就是chrome的核心，從Can I Use上查詢的支援度是Android5.0以上的版本的WebView都是支援WebRTC介面的getUserMedia( )方法的。

• 測試結果：

  應用編譯目標版本為API23，在支援API23（Android6.0）的虛擬機器和真機中測試，均無法通過WebAPI介面調起麥克風進行錄音。在支援API26（Android8.0）版本的虛擬機器中，功能均可實現。最終在Can I Use中對於getUserMedia( )方法支援度的統計資訊的備忘中，發現已知問題中在寫明了：

簡單地說就是這個方法在Android webview，iOS和PWA 基本都用不了。建議以後開發中可能用到一些不常用的API時完整地看一下相關資訊。

• 結論：

  Android8.0支援，Android支援度不佳，不建議使用。

2.2 crosswalk

• 方案：

  官方網址：https://crosswalk-project.org/

  利用crosswalk，在進行app打包時，將webview核心替換為xwalk(crosswalk開發的基於chromium的瀏覽器核心)，以擴充原生webview的能力。

• 理由：

  既然原生webview功能被閹割，那麼可以利用這個小型黑科技來把一個功能更強大的瀏覽器核心跟自己的應用打包在一起，筆者3年前在cordova2.0-3.0版本流行的年代使用過這個技術，好處是的確可以擴充webview的能力無疑，不好的地方在於app項目會直接增大80-90Mb的體積，當然通過幾個版本的迭代，現在crosswalk可以針對手機核心類型產生不同的包，app體積增量大約在20Mb，基本屬於可接受範圍。

• 測試結果：

  遺憾地是這個項目一年前已經停止維護了，最後一版的官方腳手架工具也無法初始化新的工程，間接使用的方式分為兩種，第一，下載crosswalk的包，手動在android工程中替換原生WebView，對Hybrid開發人員來說難度較大且與hybrid技術相容性不可控；另一種方案在下一小節說明。

• 結論：

  不建議使用，有那個精力真不如去研究一下可靠的hybrid方案。

2.3 Cordova/ionic

• 方案：

  官方網址：https://cordova.apache.org

  codova是一個很流行的hybrid方案，現在已經升級到8.0.0版本，它本身就是一個將web應用打包為app的解決方案。cordova的基本原理是將一般UI層操作和功能放在WebView裡實現，需要調用行動裝置硬體或原生介面時，均通過添加cordova外掛程式的形式來實現，每一個cordova版本都會橫跨支援若干個Android版本，例如新的cordova7.0.0在官方文檔的說明中是支援android從4.4到8.1版本的，筆者認為非常適合小型hybridTeam Dev使用。

• 理由：

  值得一提的是cordova擁有一個非常流行的移動端開發×××ionic,現在已經迭代至4.0階段，這個技術筆者是有特殊感情的，當年ionic還在alpha版本的時候，筆者就在使用了，它是基於cordova+angular這個技術組合的，擁有清新且設計感極強的UI組件，非常值得嘗試。另外，cordova是擁有crosswalk外掛程式的，可以直接以外掛程式的形式，在cordova項目打包時加入crosswalk，有相關需求的讀者可以以一試，尤其是團隊裡沒有Android開發人員也沒有專門的設計人員的時候，ionic出品的應用一定會讓別人對你另眼相看。

• 測試結果：

  筆者曾在使用cordova3.3的時候就融入過crosswalk，也通過cordova外掛程式成功調用過底層的GPS，網路攝影機及其他一些原生組件，當時是為了適配Android4.4版本。cordova7.0.0的腳手架經測試在國內是可以使用的，建立的工程無論是通過內建命令列還是import進Android Studio來進行開發都可以打包為對應的工程，官方文檔有很詳細的調用各種底層介面的說明，網上也有cordova7.0.0+crosswalk方案對應的技術貼。

  筆者由於技術協議中指定技術棧的緣故，無法中途替換解決方案，故本次未進行測試。

• 結論：

  可考慮作為整體解決方案進行嘗試。

2.4 React-Native

• 方案：

  官方網址：https://reactnative.cn

  這是筆者本次使用的方案，由於web端採用React技術棧完成的緣故，為了不增加團隊小夥伴的學習成本，移動端就選用了React-Native的方案。這個方案既可以按照混合開發的方式來進行，也可以按照單個WebView的方式來進行(已驗證這種方案無法支援WebRTC)。

  可能很多人已經聽說去年Airbnb公開宣布不再繼續使用React-Native作為移動端解決方案並做了詳細的解釋，當時也是很多人鼓吹說React-Native要涼涼了。實際上Airbnb在聲明中說的很清楚，React-Native是非常好的hybrid解決方案，他們所遇到的問題是當效能和使用者體驗最佳化到一定程度時，在hybrid技術的維護和開發上投入的人力過多了，整個項目的前端人員不僅有Web前端，還有進階的Android和IOS人員來保障hybrid項目的推進，他們認為這樣的人力成本相比於原生開發而言要高很多，所以更換了方案。聽明白了嗎？所以作為軟體技術比國外落後不知道多少年的天朝碼農，考慮實際的項目需求，儘管放心大膽地用就好了，跟風真的沒什麼價值。

• 理由：

  熱門的hybrid解決方案，和Web前端三駕馬車之一的React屬同門，文法和組件結構相似性高，社區活躍且周邊生態較好。

• 測試結果：

  React-native已經發布0.57.3版本，但經測試0.55.4在國內屬於可正常建立工程的版本(使用react-native init XXX命令建立的工程)，0.56大版本中發布的兩個小版本均在初始打包時報錯，命令列的提示連結到一個已知issue，但可惜照做以後也未能打包成功，0.57預設的Android-SDK是API27，也就是Android8.1，對於經驗不足的開發人員來說（比如我自己），太新的版本也不建議使用，除非你的項目是在指定機器上啟動並執行。

  React-native也封裝了WebView組件，但很遺憾，直接載入web應用的方式經測試也無法調起getUserMedia( )這個方法，所以最終只能通過混合開發的方案來實現（但回過頭來想，跟通過WebView來調用硬體介面相比，其實這種實現方式反而更符合邏輯）。

• 結論：

  建議未掌握多語言混合開發能力的hybrid開發人員儘可能選用熱門方案，理由很簡單，所有的前端項目都有坑，但熱門項目出了問題可以找大牛諮詢。

WebRTC技術錄音相關的navigator.getUserMedia,navigator.mediaDevices.getUserMedia,AudioContext這上面這幾個方案中都是存在的，但事實是都沒能在webview中調起麥克風進行錄音。

當然WebRTC作為獨立的標準和技術，也是可以融入Android工程的，但從前端開發人員的角度來說這條路就有點跑偏了，執著於WebRTC或者團隊裡有原生開發人員的小夥伴可以研究一下。

三. React-Native方案的整體架構

基本上只要多複用現成的組件，加上適量的定製，儘可能不使用一些奇技淫巧，產品的流暢度基本區分不出來是否是Hybrid開發還是Native開發，當然跟筆者的項目體量不是很大也有一定關係。

四. 使用外掛程式清單

• react-native-audio

  地址：https://github.com/jsierles/react-native-audio

  調用麥克風採集音頻。

• rn-fetch-blob

  地址：https://github.com/joltup/rn-fetch-blob

  在RN中從native層通過原生線程直接發送大體積位元據或檔案，通過Bridge對象從Web發請求會造成效能問題。

• Multer模組

  地址：https://github.com/expressjs/multer

  Express服務端中介軟體，用於接收用戶端發送的大體積位元據或檔案。

• FFmpeg工具

  地址：http://ffmpeg.org/

  多媒體格式轉換庫。手機端採集編碼的格式無法被百度語音辨識介面直接識別，需要先進行重編碼。node.js開發人員通過child_process模組直接從代碼中喚起命令列執行即可。

• docxtemplater模組

  地址：https://docxtemplater.readthedocs.io/en/latest/

  node.js模組語音辨識結果需要在後台產生docx格式的檔案（word文檔），可使用這個模組，使用方法和模板渲染引擎基本一致。

五. RN開發細節和遇到的坑

1. 真機調試時，需要搖晃手機，在配置菜單中填寫內網IP+連接埠號碼，否則會直接紅屏報錯。
2. 真機調試時，需要在設定中開啟應用的懸浮框許可權，否則可能白屏什麼都不顯示。
3. WebRTC在Android WebView相容性不好，IOS內建瀏覽器不支援。
4. react-native-audio進行錄音時，每一次調用Stop之後，若要再次啟動錄音功能，必須先調用AudioRecorder.prepareRecordingAtPath( )方法重新初始化，否則會紅屏報錯。
5. WebView組件必須設定ref={(webview)=>{this.webview = webview}},否則onMessage屬性無法監聽到來自WebView載入網頁通過window.postMessage發來的訊息。
6. TouchableHighlight組件必須先設定onPress屬性的回呼函數（可以為空白函數），否則觸摸變色的響應屬性UnderlayColor無法生效。
7. Modal組件在一個自訂群組件中只能有一個（如果有多個必須通過條件判斷只執行個體化一個），否則即使未顯示的Modal組件的Visible屬性設定為false，其執行個體方法也會和另一個Modal組件發生重疊覆蓋，可能出現的現象就是顯示了第一個Modal的介面，卻執行了第二個Modal的同名方法。

基於React-Native0.55.4的語音辨識項目全棧方案