说说Android端与服务端实现的个人经验，供参考：

发送方:
  1. 我们的语音文件是C/S模式：语音收录完毕马上上传，上传过程中，语音消息体异步构建;  2. 发送方用户无论上传成败，都能播放，因为本地已经有语音文件；
  3. 等到Server Ack语音文件，预构建好的消息体内的文件本体url会被Server响应的文件url替换；
  4. 替换的消息体发送出去，发送方的流程就基本完成；
  5. 如果语音发送失败，重试一次。又失败则参考微信的红色感叹号，以后仅用户点击时才重试；

接收方：
  1. 接收好友发来的消息，里面已经包含了语音文件的url，马上下载，保证体验；
  2. 下载语音可能会出现速度慢、短线等问题，自动重试一次，用户不点语音就不给提示。
  3. 如果用户在重试失败后点击语音，就提示用户下载失败，同时再一次触发重试。如果马上下载成功就直接播放，等很久才成功不需播放；

技术点：
  1. 语音文件一定要限制长度，用长度约束体积；尽量把语音的压缩等级提高，保留语义不影响听者的理解即可，这点也是屈服于体积的，因为不是所有公司都有大厂的音视频研发能力；
  2. 没有做边收音边上传的优化，能力不足的原因；
  3. 如果做两个移动端，从通用型的角度来说，建议选择amr音频；

说说Android端与服务端实现的个人经验，供参考：

发送方:
  1. 我们的语音文件是C/S模式：语音收录完毕马上上传，上传过程中，语音消息体异步构建;  2. 发送方用户无论上传成败，都能播放，因为本地已经有语音文件；
  3. 等到Server Ack语音文件，预构建好的消息体内的文件本体url会被Server响应的文件url替换；
  4. 替换的消息体发送出去，发送方的流程就基本完成；
  5. 如果语音发送失败，重试一次。又失败则参考微信的红色感叹号，以后仅用户点击时才重试；

接收方：
  1. 接收好友发来的消息，里面已经包含了语音文件的url，马上下载，保证体验；
  2. 下载语音可能会出现速度慢、短线等问题，自动重试一次，用户不点语音就不给提示。
  3. 如果用户在重试失败后点击语音，就提示用户下载失败，同时再一次触发重试。如果马上下载成功就直接播放，等很久才成功不需播放；

技术点：
  1. 语音文件一定要限制长度，用长度约束体积；尽量把语音的压缩等级提高，保留语义不影响听者的理解即可，这点也是屈服于体积的，因为不是所有公司都有大厂的音视频研发能力；
  2. 没有做边收音边上传的优化，能力不足的原因；
  3. 如果做两个移动端，从通用型的角度来说，建议选择amr音频；