ios开发IM与音视频

IM

一、传输协议的选择

结论：对于小公司或者技术不那么成熟的公司，IM一定要用TCP来实现，因为如果你要用UDP的话，需要做的事太多。当然QQ就是用的UDP协议，当然不仅仅是UDP，腾讯还用了自己的私有协议，来保证了传输的可靠性，杜绝了UDP下各种数据丢包，乱序等等一系列问题。
总之一句话，如果你觉得团队技术很成熟，那么你用UDP也行，否则还是用TCP为好。

二、各种聊天协议

首先我们以实现方式来切入，基本上有以下四种实现方式：

1. 基于Scoket原生：代表框架 CocoaAsyncSocket。
2. 基于WebScoket：代表框架 SocketRocket。
3. 基于MQTT：代表框架 MQTTKit。
4. 基于XMPP：代表框架 XMPPFramework。

注意：

MQTT和XMPP为聊天协议，它们是最上层的协议，

WebScoket是传输通讯协议，它是基于Socket封装的一个协议。

通常我们所说的腾讯IM的私有协议，就是基于WebScoket或者Scoket原生进行封装的一个聊天协议。

为什么说基于TCP的移动端IM仍然需要心跳保活？

在使用 TCP 长连接的 IM 服务设计中，往往都会涉及到心跳。心跳一般是指某端(绝大多数情况下是客户端)每隔一定时间向对端发送自定义指令，以判断双方是否存活，因其按照一定间隔发送，类似于心跳，故被称为心跳指令。

TCP KeepAlive 是用于检测连接的死活，而心跳机制则附带一个额外的功能：检测通讯双方的存活状态。

真正需要心跳机制的原因其实主要是在于国内运营商NAT超时。

三、序列化与反序列化

常见的二进制序列化库有Protocol Buffers和MessagePack，当然你也可以自己实现自己的二进制协议序列化和反序列的过程，比如蘑菇街的TeamTalk。但是前面二者无论是可拓展性还是可读性都完爆TeamTalk(TeamTalk连Variant都不支持，一个int传输时固定占用4个字节)，所以大部分情况下还是不推荐自己去实现二进制协议的序列化和反序列化过程。

一条消息数据用Protobuf序列化后的大小是 JSON 的1/10、XML格式的1/20、是二进制序列化的1/10。同 XML 相比， Protobuf 性能优势明显。它以高效的二进制方式存储，比 XML 小 3 到 10 倍，快 20 到 100 倍。

选择传输格式的时候：ProtocolBuffer > JSON > XML

音视频

一、一个直播APP的整体框架

1、一个完整直播app原理

直播原理：把主播录制的视频，推送到服务器，在由服务器分发给观众观看。

直播环节：推流端（采集、美颜处理、编码、推流）、服务端处理（转码、录制、截图、鉴黄）、播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）。

2、一个完整直播app实现流程

1.采集、2.滤镜处理、3.编码、4.推流、5.CDN分发、6.拉流、7.解码、8.播放、9.聊天互动

3、一个完整直播app架构

4、一个完整直播app技术点

• 

二、了解流媒体（直播需要用到流媒体）

流媒体开发:

网络层(socket或st)负责传输，协议层(rtmp或hls)负责网络打包，封装层(flv、ts)负责编解码数据的封装，编码层(h.264和aac)负责图像，音频压缩。

帧:

每帧代表一幅静止的图像。

GOP:

（Group of Pictures）画面组，一个GOP就是一组连续的画面，每个画面都是一帧，一个GOP就是很多帧的集合。

直播的数据，其实是一组图片，包括I帧、P帧、B帧，当用户第一次观看的时候，会寻找I帧，而播放器会到服务器寻找到最近的I帧反馈给用户。因此，GOP Cache增加了端到端延迟，因为它必须要拿到最近的I帧。GOP Cache的长度越长，画面质量越好。

码率：

图片进行压缩后每秒显示的数据量。

帧率：

每秒显示的图片数。影响画面流畅度，与画面流畅度成正比：帧率越大，画面越流畅；帧率越小，画面越有跳动感。

由于人类眼睛的特殊生理结构，如果所看画面之帧率高于16的时候，就会认为是连贯的，此现象称之为视觉暂留。并且当帧速达到一定数值后，再增长的话，人眼也不容易察觉到有明显的流畅度提升