基於React-Native0.55.4的語音識別專案全棧方案

摘要： 移動端的 API 能力驗證方案與PC端不一樣！不一樣！！不一樣！！！ 即使需要使用的 API 都存在，也不一定能用，這一點和PC端是有很大區別的，國內的手機系統雖然都是基於 Android ,但幾乎都會經過各大廠商的定製，功能與原版 Android 系統並不是完全一致的，在...

一. 移動端直接訪問Web應用？

PC端基於 Web API 的語音識別方案可參考 ofollow,noindex" target="_blank">《【Recorder.js+百度語音識別】全棧方案技術細節》 一文。

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

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

file:///
http://localhost
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年前在 cordova 2.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 出品的應用一定會讓別人對你另眼相看。

• 測試結果：

  筆者曾在使用 cordova 3.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 的同名方法。