大学 cs 专业学生，应该绝大多数人都写过 im 聊天软件吧

你可以把声音用 opus 之类的编码器进行编码，然后传二进制报文过去

作业级别的语音消息真的可以这么做，以前没有 4g 网的时候要各种考虑压缩，现在的网速发个 mp3 问题也不大

一般都用云服务了啦，接入 sdk ，消息云同步啥的都替你做好，云平台还能加审核过滤功能，你需要做的只是维护用户间的关系。全部自己实现的话就要维护太多东西了

“ps： 语音消息，问了一个大佬，他说发语音消息的时候，先录音成.mp3 文件到本地，然后发送到另一端，另一端接收播放这个.mp3 ，这....”

难道不是这样吗？
当然发送到另一端的可以是 mp3 文件，也可以是把文件存服务器，只发个播放地址过去。

@cutepeer 就是要自己做 SDK

忽然想起了 ‘像寻’公众号事件 ， “”程序员都知道， 自己实现一套 IM 至少 2 个月以上“”

@murmur 不是作业级别的语音有什么传输更好一点呢

语音消息就是录制好的 mp3 上传到服务器，发链接给对方，这个思路没毛病啊

@pubby
@darkengine

我没说有毛病，只是在想优质的 IM 做的这个功能，也是.mp3 文件嘛，就像 2 楼说的是不是 可以编辑为 2 进制传输，这效率不是高太多了

@godleon #10 有没有一种可能，mp3 也是一种高效率编码二进制文件呢

语音消息可以用电信的标准，一般用 AMR 。

0-1 难度不大 1-100 难度非常大

这种宽泛的问题肯定看实际情况啊，毕业设计和商业产品不一样，服务端和客户端不一样，包含功能的多少也可以有变化（比如撤回、引用回复、发语音、表情包、视频、文件等）
你什么都没说我只能当成 “找外包 1000 做一个微信” 来看待了

语音消息这么做也没啥问题，不过一般来说会有专门的格式编码——不需要多余的元数据，压缩算法专门针对（非即时的）语音场景
（另外二进制比文本效率高这说法槽点多到不知道从哪里开始说比较好（（（（

@godleon

就像 2 楼说的是不是 可以编辑为 2 进制传输，这效率不是高太多了

-------------

不要一开始就考虑优化。而且 2 楼提到的 opus 一般用在实时语音领域，需求里一条条的语音消息，完全没必要上这个增加复杂度。

@lizy0329 认同，只实现功能应该问题不大，但是主要是要看你的期望是做到什么样，这就是无上线的了。

@yukiww233 mp3 的问题不是在于授权协议吗

语音不用 mp3 ，用 amr ，体积小。语音消息有损压缩也没事。
还有长链接存储问题：
长链接无法存到数据库 /redis 中。那服务器 1 的用户给服务器 2 的用户发送信息，1 是找不到 2 下用户的 channel ，故无法直接发送信息。

我的理解啊 做个能用的不难, 但是做个好用的 就是没有上限的了, 也就是挺难的

看承载量，10 个人用跟 10 亿人用的难度差别还是很大的

https://github.com/OpenIMSDK
用开源的吧，感觉完整的 IM 不是一个人就能搞定的项目

@XiLingHost #18 mp3 的专利不是已经过期了么

可以看看 https://github.com/stream-stack/store-operator 云原生消息中间件
基于此实现 IM 很简单

opus 调用不麻烦，能压缩到原音频的十分之一

实现一套不难，最最简单的 websocket 就能搞一套，难得是集群扩展承载力。

可以把语音数据部分和传输部分解耦，不管啥格式的数据都可以在传输通道里走，这样你可以先上 MVP 方案用现成的编码格式，比如 mp3 ，等核心部分都搞定了，再看看是不是要替换语音编码。

除非你现在已经把 IM 核心功能都搞定了，就剩语音了。

计算机上，除开算法问题， 其他问题不难， 难的是如何落地。

做一个能简单互相发消息的 IM 系统不难，假设这个难度是 1 。

在这个基础上做出一个不但要能发消息，还要用起来比较顺手的，已经非常困难了，非常多的细节需要考虑。关于这个我就举个例子：发送者可以自由发送五花八门各种格式的视频，接受者要能直接点看。这个别看就一句话，实际上做起来非常非常非常困难，基本上你需要集成一整套视频编码、解码、播放系统进去。这一步难度大约是 100 。

然后再在用起来比较顺手的基础上，做一套能支持海量用户的系统，这个就不是普通公司能完成的事情了，这个难度大约是 10000 。

可是一套 IM 不止是发语音。

做出来的 IM 是给一个人用的还是给一百万人用的，不是同一个级别的难度。

玩具你随便弄弄，弄成点对点都可以说是 IM 吧。

正儿八经的 IM ，服务端要考虑服务的拓展性、性能、灾备、安全性、合规。

落到移动客户端，这个问题可能还涉及客户端的耗电、内存使用、流量使用、数据状态的同步、各类错误处理。

别问，问就是 上传+下载

关键问题是满足多大用户量。
如果只是几个人发发消息，用 ajax 轮询服务端也做了是吧

@xiangyuecn 正解。

一个 IM 系统的讨论，偏离到语音消息的传送细节了。
有空去看看 GSMA 国际规范 RCS ，里面讲述的内容大于 IM ， 但是能更好的帮助你了解 IM 系统

这么说吧，当年学校机房里写了个 im ，可以同学之间聊天，类似飞鸽传书，同一年，qq 第一版面市。

- 前些天, 用 B 站 毛剑大佬开源的 goim 改了一个 客服聊天

https://github.com/poembro/goim-demo

答：自己写个 IM 难度几乎为 0 ，重点是有人用。

不难啊，就像现有的卖 IM 服务的企业根本不是卖技术本身，而是卖数据存储的，流量带宽大了贼贵。

功能做出来不难，难的是优化和用户体验，还有承载用户量

感觉会这么问的，不像是程序员

IM 可能没做过，但商城每个工作了的程序员都做过吧？

自己做的商城和淘宝比，工作量和难度不都心里有数了吗？

ps：商品详情，问了一个大佬，他说编辑商品详情的时候，先编辑成.doc 文件存在本地，然后在商品详情编辑框粘贴上去，页面显示这个内容，这...

以我的经验给你几点建议吧
1. 格式用 amr ，amr 的好处是对人声处理的特别好，压缩比特别高，基本上每秒小于 1KB 。
2. 发送语音有 2 个种办法，一种是上传到一个服务器，把链接发送给对方，对方播放再下载；另外一种是直接放到消息体内直接发送给对方。如果是对讲语音，用第二种方式。
3. 对接的话不需要考虑存储，对方不在就直接丢掉。如果只有对讲可以不用考虑离线消息和消息存储。当然如果有其它类型的消息则必须实现了。
4. 不要从 0 开始写，现在有开源的 MQTT 服务和客户端，一个频道就是一个 topic 就行，再加上抢麦的功能，这种网上有很多抢红包的例子，比较类似。
5. 要逐步实现，不要贪大求全，上来就高并发微服务。先功能再优化。

另外感觉你问得太笼统了，如果做好一个通用型的 IM 是非常困难的，你基本上在这里得不到答案。你可以详细说一下问题和需求。

有一段时间做 IM 的扎堆，基本上都挂了，从头到尾自己做意义不大，直接上 XMPP 之类的就行了

建议做一个用户体验好的 xmpp 客户端

大，而且大到坑爹。
你举例的那个操作，要坑死你
1. 网络不好的带宽有限，移动网络的容易不在网，丢包网络的切换的时候丢了几个包，怎么办？实时性做到哪个程度？没听到的能不能回溯？
2. 一个频道要承载多少人？网络协议走可靠的还是不可靠的？服务器要预备多少带宽？有没有 fallback 到 p2p 功能？如果 fallback 怎么打洞？
3. 客户端要多少个平台？ Android 底下的设备要适配多少？ Apple 的呢？桌面的呢？
4. 你这个系统准备有多少容灾，是不是个人部署，要不要考虑部署的合规性？
还有具体的技术细节一箩筐……

1.作业级别的一点都不难，语音视频什么的无脑开源协议，甚至 mp4 、rtmp 等等。

2.如果要自己设计音频视频协议，那就麻烦很多，需要从数学原理开始进行优化，不然未压缩的 raw 音频与视频数据量，尺寸会大到离谱。

3.最麻烦的是给所有人用的量级，这就不是技术问题了。你需要有足够的资金，拿来买带宽、服务器、甚至机房。

不考虑语音视频通话，用户量，

用 mqtt 两三天，去年搞过，

没搞过语音视频场景，跟着上面大佬学习一波

有没有一种可能，不需要把文件写到外存上，录在内存里直接发出去就可以了

市面上挺多 IM 都是把音频录好，上传到云存储，然后发一个 音频类型的消息，里面带了音频文件的 URL 。 融云、云信、腾讯都有 SDK ，可以参考看看

可以直接集成 firebase 来实现

WebRTC ？

一直挺想写 IM ，最近学了 Rust ，想拿 Rust 试试。

文件信息肯定是传播放地址啊，把文件上传到云存储，把地址当做语音消息传过去，另一端直接播放这个在线 MP3

@documentzhangx66 自己设计音视频协议。。光这一项你一年都做不完，就算是生产环境 rtmp 也能用