请选择 进入手机版 | 继续访问电脑版

默认
发表评论 26
请问有人知道语音留言聊天的主流实现方式吗?

大家好,请问有人知道语音聊天的主流实现方式吗?就是类似微信那种,按住说话,录一段,发送那种。

这语音文件录好之后是直接转成二进制发送。还是说当成一个文件上传到服务器,然后发送一个消息给对方,对方收到后下载?

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

点评

JackJiang  说:
实现思路请着重查看2、4、8楼的回复哦  (1 年前)
上一篇:即时通信的消息ID,有什么好的不重复的生成方法吗?下一篇:架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]

本帖已收录至以下技术专辑

推荐方案
评论 26
移动网络因为网络不稳定的客观因素存在,不适合实时发送较大的2进制文件(像电脑上的实时文件发送的那种),因为这涉及3方:客户端A、服务端、客户端B,任何两方的通讯因网络的不稳定而导致的重传等,都是个很不好处理的事情。

现在多数情况下都是通过http先上传到中转文件服务器,成功后再通知接收方,这种情况下,因上传的过程只限于客户端A和服务端,只涉及两方,网络的不稳定,也只影响了发送者(而不涉及接收者,因为对方还不知道你正在发送文件呢),所以无论是从可靠性、复杂性,还是用户体验的处理上,这种方式都要简单的多。而这么多年的移动应用也证明,这种云中转暂存的方式是比较适合于当前的移动网络和移动应用体验的。
签名: 《 WebSocket详解(六):刨根问底WebSocket与Socket的关系》http://www.52im.net/thread-1273-1-1.html
如果使用中转服务器,就有一个问题,, 就是收到音频信息后是直接显示那条音频消息,还是下载完再显示音频,如果直接显示音频,那用户点击的时候可能没有下载完成,点击没有声音。如果 下载完音频再显示消息的话,那么在下载过程中可能收到普通消息,普通消息不需要下载直接显示,这时候音频下载完成后显示在普通消息的后面的话顺序就乱了,显示在普通消息之前的话会有界面跳动的情况,,用户体验不太好,,这个问题怎么解决
引用:jerrychan 发表于 2016-03-25 09:08
如果使用中转服务器,就有一个问题,, 就是收到音频信息后是直接显示那条音频消息,还是下载完再显示音频 ...

应该是发送方把语音文件上传到服务器成功后,同时发一条语音消息(只是一个包含了音频下载地址信息,可能是个文件名或url)发给接收方,接收方只在点击时才下载。

这就完全不存在你说的会乱序的问题。而且你仔细体验一下微信或其它主流im,都是这么玩的。你如果做过技术研究,就可以知道,微信最长60秒的语音留言大约50KB左右,你自已实现的话也差不多可以到90KB,而通常情况下没有人会说这么长的话,通常都是15秒左右,10几20kb的文件大小,上传或下载都是非常轻松和快速的事情,所以,实际情况下的实用性,不需要怀疑。你可以去体验下RainbowChat:http://www.52im.net/forum-90-1.html,即使是在很差的网络,比如在地铁行驶时使用,也同样体验很好。
签名: 《 WebSocket详解(六):刨根问底WebSocket与Socket的关系》http://www.52im.net/thread-1273-1-1.html
引用:JackJiang 发表于 2016-03-25 17:16
应该是发送方把语音文件上传到服务器成功后,同时发一条语音消息(只是一个包含了音频下载地址信息,可能 ...

是的,我研究过易信的,60秒大概200KB左右,
不过高清音质是它的卖点之一,用的是AAC格式,所以大了不少。
但实际用的时候,体验都没啥问题。
引用:JackJiang 发表于 2016-03-25 17:16
应该是发送方把语音文件上传到服务器成功后,同时发一条语音消息(只是一个包含了音频下载地址信息,可能 ...

不错,学习了
签名: 该会员没有填写今日想说内容.
引用:JackJiang 发表于 2016-03-25 17:16
应该是发送方把语音文件上传到服务器成功后,同时发一条语音消息(只是一个包含了音频下载地址信息,可能 ...

我研究了一下微信,好像不是点击的时候才下载的,我收到语音消息之后,把网络断开了,然后点击依然能播放。这个群主怎么看?
引用:jerrychan 发表于 2016-03-25 09:37
我研究了一下微信,好像不是点击的时候才下载的,我收到语音消息之后,把网络断开了,然后点击依然能播放 ...

* 先回答你的问题:
微信的语音留言网络表现我没有注意过,但微信的所有技术实现,都是为了两个字服务:“体验”!我不知你是否确信你的测试结果是准确的,我暂且假设你的结果是准确的,那么我猜测的原因有两种可能:
1)微信可能会为了提升体验,默认当你处于wifi时,主动下载了收到语音消息;
2)可能你当前正处于与对方的聊天界面时,微信会主动下载,以便提升体验。
当然,这只是猜想,你也可以把可能性都覆盖到。


针对前面我说的图片和语音留言是通过服务器中转暂存、只在接收方点击时下载的说法,我给出两个图,证明实我的说法:
* 图1(某版本手机QQ上查看语音留言时):
QQ截图20160326093808.png

* 图2(某版本微信上查看图片消息时):
QQ截图20160326093952.png

图1是qq某个版本的语音留言读取方式,注意那个进度条(能明白吗)!当前的这个截图实际是我的RainbowChat里的,而Rainbowchat里的就是从qq里扒出来的(我没有美工)。
图2看起来很熟悉吧,是微信的某个版本的图片消息读取方式,同样注意进度条(能明白吗)!如果你注意过以前的微信,你应该还记得,当过了一段时间没有看查收图片消息,你再点击,微信会告诉你“该图片已失效”,这明显决味着为了防止中转服务器图片消息积压,而主动被清理了。

综上两图,不需要更多说明了吧(总而言之:除去即时通讯以外,语音、图片就是纯http上传和下载了)。
签名: 《 WebSocket详解(六):刨根问底WebSocket与Socket的关系》http://www.52im.net/thread-1273-1-1.html
引用:JackJiang 发表于 2016-03-26 09:49
先回答你的问题:
微信的语音留言网络表现我没有注意过,但微信的所有技术实现,都是为了两个字服务:“ ...

再次感谢
送图片,录音,录像的思路是,先通过http上传图片,录音,录像到服务端,然后要求服务端返回图片录音录像的地址到客户端,然后客户端发送json,发送图片地址录音录像的地址给IM,IM通过推送给另外的客户端,客户端收到以后,通过解析json,然后通过http下载视频图片,语音,,图片的话要进行缩放,录音的华,要有特定的图标标示,录像的话,下载以后截取第一帧的图片,不过建议这样,在展示图片的时候,缩放,在展示录像录音的时候,直接用图标替代展示的录像录音,然后通过用户点击图标通过http下载录音视频得到这种效果,此类功能需要一个ftp服务器,进行处理
引用:疯华整猫 发表于 2016-04-13 10:11
送图片,录音,录像的思路是,先通过http上传图片,录音,录像到服务端,然后要求服务端返回图片录音录像的 ...

说的很具体了,这一看就能明白该怎么做了,你应该做过IM,学习了
引用:DavidChang 发表于 2016-04-13 11:23
说的很具体了,这一看就能明白该怎么做了,你应该做过IM,学习了

我做过伪聊天工具,也做过TCP,UDP,也做过MIMA
引用:疯华整猫 发表于 2016-04-13 14:32
我做过伪聊天工具,也做过TCP,UDP,也做过MIMA

弱弱的问一句,MIMA是个啥?
签名: 星期六,那又怎样,还是得上班
引用:只是路过 发表于 2016-04-13 15:36
弱弱的问一句,MIMA是个啥?

IBM出品的一个聊天引擎
引用:疯华整猫 发表于 2016-04-13 16:10
IBM出品的一个聊天引擎

能否简单介绍一下这玩意有啥用处?为啥要选它?我也学习一下。
签名: 星期六,那又怎样,还是得上班
引用:只是路过 发表于 2016-04-13 16:27
能否简单介绍一下这玩意有啥用处?为啥要选它?我也学习一下。

参照 http://www.52im.net/thread-113-1-1.html
引用:JackJiang 发表于 2016-03-25 16:44
移动网络因为网络不稳定的客观因素存在,不适合实时发送较大的2进制文件(像电脑上的实时文件发送的那种) ...

https://github.com/pangzaifei/zfIMDemo  如果想参照案例推荐,有的全有,如果把52im的里面的框架,和这个框架里面的思路结合,那么就可以直接使用了
引用:疯华整猫 发表于 2016-06-30 08:55
https://github.com/pangzaifei/zfIMDemo  如果想参照案例推荐,有的全有,如果把52im的里面的框架,和这 ...

看样子,这哥们是用百度push来实现下层的即时通讯数据交互的。此工程已收藏,主要就是界面的代码了,改天整理一下看有没有人用的上。多谢
签名: 《 WebSocket详解(六):刨根问底WebSocket与Socket的关系》http://www.52im.net/thread-1273-1-1.html
确实还不知道
请问各位群聊怎么实现的?
签名: 生如夏花般绚烂
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

Processed in 0.203127 second(s), 40 queries , Gzip On.

返回顶部