徐珂航 宋曦 吴红 张庆 李建兵
(1国网眉山供电公司,四川眉山 511402)
(2四川省电力公司,四川成都 610041)
统一通信Android客户端语音消息的实现
徐珂航1宋曦2吴红1张庆1李建兵1
(1国网眉山供电公司,四川眉山 511402)
(2四川省电力公司,四川成都 610041)
为了实现统一通信Android客户端语音消息功能并减少网络传输量,在使用XMPP的基础之上,通过分析Smack 和Speex等关键技术,结合移动设备自身的特性,设计了移动端语音消息的收发机制,高效地实现了Android客户端的语音消息功能,并充分考虑用户体验,提供重发机制,通过移植Speex到Android平台,使用其完成编解码工作,极大地降低了压缩后输出文件的体积,减少了移动端的网络传输量。最后说明了实现效果,指出了未来的研究方向。
语音消息Smack减少传输量XMPP Speex
统一通信(Unified Communication,UC)是一种将传统的通信技术和飞速发展的计算机技术融合起来的新型通信模式。统一通信系统将语音电话、视频、即时消息、数据文件、传真和电子邮件等多种信息类型融为一体,从而增加办公的灵活性,提高办公效率[1]。
即时通信(Instant Messaging,IM)是统一通信的基本业务功能,通过即时通信发送文字、图片、语音、文件等多媒体数据,使得用户能方便灵活的沟通,而不必局限于必须要强实时的通话才能完成信息的交换。IM系统中的语音消息更是提供了死板的文本交流之外的另一种更为丰富的选择。可扩展通讯和表示协议(Extensible Messaging and Presence Protocol,XMPP)作为一种基于XML的开放式标准,已经广泛的被即时通信系统所应用[2],但是XMPP协议并没有具体的规定语音消息的收发。当前主流的移动操作系统有Android和iOS,语音文件的格式需要通过一定的转换才能在2种客户端之间互通,并且移动端的文件传输在2G/3G网络下对文件大小相当敏感,传输操作必须要考虑如何节省网络流量的消耗[3]。
文在XMPP的基础上,制订语音消息收发的流程,实现语音消息的收发,并且利用Speex技术来完成语音的压缩,解决不同移动客户端之间的语音互通,从而提供了一种较好的统一通信Android客户端语音消息的解决方案。
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也很适合网络应用,在网络应用上有着自己独特的优势。
语音传输类似文件数据的传输,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.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输出文件对比
用户通过以上介绍的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