統一通信Android客戶端語音消息的實現

徐珂航 宋曦 吳紅 張慶 李建兵

（1國網眉山供電公司，四川眉山 511402）

（2四川省電力公司，四川成都 610041）

統一通信Android客戶端語音消息的實現

徐珂航1宋曦2吳紅1張慶1李建兵1

（1國網眉山供電公司，四川眉山 511402）

（2四川省電力公司，四川成都 610041）

為了實現統一通信Android客戶端語音消息功能并減少網絡傳輸量，在使用XMPP的基礎之上，通過分析Smack 和Speex等關鍵技術，結合移動設備自身的特性，設計了移動端語音消息的收發機制，高效地實現了Android客戶端的語音消息功能，并充分考慮用戶體驗，提供重發機制，通過移植Speex到Android平臺，使用其完成編解碼工作，極大地降低了壓縮后輸出文件的體積，減少了移動端的網絡傳輸量。最后說明了實現效果，指出了未來的研究方向。

語音消息Smack減少傳輸量XMPP Speex

1 引言

統一通信（Unified Communication，UC）是一種將傳統的通信技術和飛速發展的計算機技術融合起來的新型通信模式。統一通信系統將語音電話、視頻、即時消息、數據文件、傳真和電子郵件等多種信息類型融為一體，從而增加辦公的靈活性，提高辦公效率[1]。

即時通信（Instant Messaging，IM）是統一通信的基本業務功能，通過即時通信發送文字、圖片、語音、文件等多媒體數據，使得用戶能方便靈活的溝通，而不必局限于必須要強實時的通話才能完成信息的交換。IM系統中的語音消息更是提供了死板的文本交流之外的另一種更為豐富的選擇?？蓴U展通訊和表示協議（Extensible Messaging and Presence Protocol，XMPP）作為一種基于XML的開放式標準，已經廣泛的被即時通信系統所應用[2]，但是XMPP協議并沒有具體的規定語音消息的收發。當前主流的移動操作系統有Android和iOS，語音文件的格式需要通過一定的轉換才能在2種客戶端之間互通，并且移動端的文件傳輸在2G/3G網絡下對文件大小相當敏感，傳輸操作必須要考慮如何節省網絡流量的消耗[3]。

文在XMPP的基礎上，制訂語音消息收發的流程，實現語音消息的收發，并且利用Speex技術來完成語音的壓縮，解決不同移動客戶端之間的語音互通，從而提供了一種較好的統一通信Android客戶端語音消息的解決方案。

2 關鍵技術

2.1 XMPP

XMPP是一個可擴展標記語言XML應用，它讓任何2個或多個網絡實體之間進行結構化和可擴展的準實時信息交流。XMPP的目標是允許2個（或多個）實體通過網絡來交換相關的結構化數據[4]。XMPP典型地使用分布式的“客戶端-服務器”體系結構來實現，客戶端需要連接到服務器來獲得對網絡的訪問，之后才被允許和其他實體交換XML節。這樣XMPP就提供一種異步的端到端的結構化數據交換技術，使得客戶端和服務器在一個分布式的可全球尋址的網絡中直接使用持久的XML流。

2.2 Smack on Android

Smack是一個XMPP協議的Java實現，提供一套可擴展的API，aSmack是Smack在Android端的構建。Smack使用Provider機制允許以定制XML的方式來增加新的功能。在開發過程中，XMPP服務器使用開源的OpenFire服務器，Smack位于客戶端，其作用是將客戶端服務器的信息交換和客戶端的的界面呈現連接起來，整個結構如圖1所示。

圖1 Smack在系統中的地位

Smack中一個重要的機制是Provider，簡單來說Provider 是Packet的解析器，Packet是Smack與服務器之間通信的消息包，具體的XMPP實現就是由多個Packet來完成的。對于擴充的功能需要自定義客戶端與服務器通信的消息方式，這時只需要編寫自定義的Packet以及對應的Provider，并注冊Provider，之后，Smack會將對應的Packet分發給指定的Provider，整個擴充工作是以插件的形式完成，不需要修改Smack原有代碼。

2.3 Speex

Speex是一套開源、無專利保護的音頻壓縮格式，Speex工程著力于提供一個高性能語音編解碼方案來降低語音應用的門檻。Speex具有多采樣率、多位率、高質量等特性，而且對于丟包有一定的魯棒性，非常適合在移動設備上應用[5]。另外，相對于其它編解碼器，Speex也很適合網絡應用，在網絡應用上有著自己獨特的優勢。

3 語音消息的收發

語音傳輸類似文件數據的傳輸，XMPP中規定了3種數據傳輸方式：Out-of-Band Data、In-Band Bytestream、Socks5[6]。其中第1種方式適合傳輸第三方服務器上的資源，第2種方式適合傳輸較小的數據，通過直接攜帶在XML中進行傳輸，第3種方式通過建立點對點的連接或者使用服務器代理的方式，實現2個節點之間的直接傳輸。只要實現了基本的消息傳輸就能支持前2種方式，此外Smack提供了Socks5方式收發文件的支持。

3.1 在線語音的傳輸

根據用戶是否在線，語音消息的收發又有所不同，首先介紹在線語音消息的實現。

發送語音文件時，首先要解決的一個問題就是客戶端如何分辨發送方發送的是語音消息。為了解決這個問題，使用一個預先發送的文本消息來通知接收方，此消息包含了語音文件名和語音時長，客戶端收到此消息后就準備接收之后發送的語音文件。因為此文本消息只是對語音消息的描述，客戶端不需要真正的將此語音消息顯示給用戶，而是首先將此消息放入接收隊列中，等語音文件接收完成之后，客戶端通知用戶有新消息送達。

文本消息的發送與接收使用Smack提供的Chat類，此類已經實現了文本消息的收發，Smack中廣泛的使用了觀察者模式，Chat類就是一個很好的例子，對于接收文本消息的處理，只需要一個實現了MessageListener接口的觀察者，并將觀察者添加到Chat對象中。當事件發生后，被觀察者Chat對象會自動通知觀察者MessageListener，觸發相應的處理函數。具體的步驟如下：

①根據聊天對象的JID從對話緩存中獲取對應的Chat對象，如果緩存中沒有此JID的Chat對象，則創建Chat對象，并將其保存到對話緩存中；

于給Chat對象添加實現了MessageListener的觀察者，在觀察者的processMessage函數中完成消息接收的處理操作；

③調用Chat對象的消息發送函數發送形如“/～#〉filename&10〈V%～”的消息，“/～#〉”前綴表示此消息不是實際的文本消息，“〈V%～”后綴表示此消息是一條語音消息的描述，中間的內容為文件名稱與語音時長（秒），二者由“&”符號連接。

整體來看，在線語音的發送流程如圖2所示。

圖2 在線語音傳輸流程

以上的流程是在每一步驟都能成功完成的預想下，實際的生產環境中有可能出現發送失敗的情況，本文將每一步都歸為一個狀態，根據各個狀態來實現消息的重發，判斷是否需要顯示重發提示的流程如圖3所示。

圖3 判斷是否需要重發流程圖

3.2 離線語音的實現

上一節介紹了接收方在線時語音消息的接收與發送，當接收方不在線時，點對點的連接就無法建立，因此不能繼續使用之前的方式發送消息。為了解決離線時的文件傳輸問題，采用將離線語音文件保存在服務器上的實現方式，當接收方登錄之后，根據接收到的離線消息再從服務器以FTP的形式下載語音文件。

以Client A作為發送方，Client B作為接收方來描述問題，Client A發送離線語音消息的第一步同發送在線語音消息一致，客戶端首先發送語音描述消息，Smack已經提供了文本消息的離線支持，所以直接發送即可。之后的操作就有所差異，完成第一步的操作之后，如果接收方Client B登錄，就會收到服務器發送來的離線文本消息，這時要解決的問題就是Client B如何得到實際的語音文件，前文已經說過離線語音文件將會上傳到FTP服務器上，因此需要完成的操作就是Client A上傳語音文件到FTP服務器，而Client B登錄之后在適當的時刻下載語音文件。

關于語音文件的上傳，如果使用直接連接FTP服務器并上傳文件的方式，服務器首先要通知Client A FTP服務器的地址以及用戶名密碼，由于語音消息一般會頻繁發送，每次發送都需要獲知服務器通知的FTP服務器信息，無疑增加了移動端的網絡傳輸量；并且語音文件的大小一般也不是很大（100 K以下），基于這2點，本文采用的方式是先將語音文件轉換成base64格式的文本，以In-Band Bytestream的形式將文本發送到服務器。

離線語音的接收需要在服務器端增加操作，服務器在收到離線文本后，將文本保存到FTP服務器上，在Client B登錄之后，服務器給Client B發送下載文件的消息，加上之前發送的描述消息，Client B就能組成一條完整的語音離線消息，并呈現給用戶。離線語音的過程如圖4所示。

圖4 離線語音傳輸流程

4 音頻處理

4.1 Speex的Android移植

Speex是由C語言編寫的，目前已有Java的實現版本JSpeex，但是JSpeex在Android端的表現不夠理想，尤其是移動端的開發必須要提供良好的用戶體驗。因此本文使用本地調用的方法將Speex移植到Android端。具體的方式為：

①創建項目，在其中建立jni文件夾；

于將Speex源代碼中libspeex和include文件夾拷貝到jni目錄中；

③在jni目錄中建立Android.mk，內容為編譯源文件列表；

④在jni目錄中添加Application.mk，內容為APP_ABI:= armeabi armeabi-v7a；

⑤在目錄jni/include/speex/下創建配置類型頭文件speex_config_types.h，內容如下：

#endif

⑥在命令行中切換到jni目錄下輸入ndk-build命令，生成libs/armeabi目錄和libs/armeabi-v7a目錄；

⑦編寫調用本地方法的Speex工具類。

4.2 音頻捕獲與播放

編寫好的Speex工具類，使用本地方法encode編碼，使用本地方法decode解碼。當錄音事件被觸發后，錄音的具體步驟如下：

①首先啟動SpeexRecorder線程；

于SpeexRecorder使用Android提供的AudioRecorder開始錄音；

③SpeexRecorder啟動SpeexEncoder線程開始編碼；

④錄音過程中，SpeexRecorder不斷將音頻數據放入緩沖區tempBuffer；

⑤SpeexEncoder不斷從緩沖區中取出音頻數據進行編碼，并存入spx文件中；

⑥不斷重復④和⑤操作，直到錄音結束。

播放的步驟與錄音正好相反，播放時SpeexDncoder不斷將編碼文件解碼放入緩沖區，再使用Android提供的AudioTrack播放音頻。

Android中的MediaRecorder也提供了音頻壓縮功能，輸出格式為amr，表1是在音頻質量類似情況下使用Speex與使用MediaRecorder輸出文件大小的對比，可以看出使用Speex能在不降低音頻質量的情況下減少網絡的傳輸量。

表1 MediaRecorder與Speex輸出文件對比

5 結束語

用戶通過以上介紹的Android端語音消息功能即可完成語音消息的收發，從而能以符合人類交流習慣的方式隨時隨地的進行弱實時性的溝通。實踐表明，本文提供的語音消息解決方案使通信雙發都獲得了比較好的用戶體驗。但是，在語音消息功能的實現過程中仍存在一些值得改進的地方。例如，從一個對應用產品要求的角度來看，移動端的開發要更充分的分析用戶的使用習慣，提供更為合理以及人性化的UI與操作流程；播放語音時采用文件讀取與解碼播放同時進行的方式降低了客戶端的性能。這些都將是未來的研究方向。

[1]劉啟勝.統一通信的現狀及其發展前景分析[J].廣東通信技術,2010,30(11):71-73.

[2]潘鳳,王華軍,苗放,等.基于XMPP協議和Openfire的即時通信系統的開發[J].計算機時代,2008(3):15-16,19.

[3]庾志成.移動互聯網的發展現狀和發展趨勢[J].移動通信, 2008(9):22-24.

[4]張彥,夏清國.Jabber/XMPP技術的研究與應用[J].科學技術與工程,2007(6):1032-1035,1039.

[5]謝曉鋼,蔡駿,陳奇川,等.基于Speex語音引擎的VoIP系統設計與實現[J].計算機應用研究,2007（12）:320-323.

[6]李鯤鵬.基于Android的即時通訊平臺研究與實現[D].華南理工大學,2013.

Implementation of Voice Message on UC Android Client

XU Ke-hang1,SONG Xi2,WU Hong1,ZHANG Qing1,LI Jian-bing1
（1 State Grid Meishan Power Supply Company,Meishan Sichuan 511402,China）
（2 Sichuan Electronic Power Corporation,Chengdu Sichuan 610041,China）

In order to implement the voice message function on the UC Android client and to reduce the network transmission traffic, the Rx/Tx mechanism of voice message on mobile client is designed by analyzing on key technologies such as Smack and Speex based on XMPP application and considering the characteristics of mobile equipment.This design implements efficiently the voice message functions on Android client and provides the resend mechanism by fully considering user experience.By migrating Speex to Android platform and making it complete CODEC,the size of output file is greatly decreased and the network transmission traffic of the mobile client is reduced.Finally,the implantation effect is presented,and the future research direction is pointed out.

voice message;Smack;reduce transmission traffic;XMPP;Speex

TN919.3

A

1008-1739（2015）06-59-4

定稿日期：2015-02-26