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

移動端的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版本的，筆者認為非常適合小型hybrid開發團隊使用。

• 理由：

  值得一提的是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的同名方法。