iOS做IM程序，怎么保持长连接？

[solar]

iOS上的IM类应用，通行的做法是建立长连接吗？还是使用apns服务？
由于iOS不支持真后台，保持长链接有什么好的方法？

[ReyZhang]

可以先去了解一下移动端的IM使用的通讯协议，iOS上的IM应用开发使用通讯协议一般常见的就是XMPP, 它通过xml格式来传递消息。在github可以找一下oc下的XMPP库。 当然如果图省事，也可以去集成一些提供这方面服务的第三方，如环信

[zhu410289616]

app在前台的时候，使用tcp，自定义协议。 在后台的时候，断开连接，使用apn提示用户，唤醒app到前台后，重新连接，拉取离线消息。 im类的都是需要考虑消息到达速度，到达率，流量控制的。 消息数据越小，在相同网络情况下，耗时就少，速度就快。 xmpp在商用的时候，其实无效数据还是太多了，太费流量，不太好。

[solar]

引用 2 楼 zhu410289616 的回复:

app在前台的时候，使用tcp，自定义协议。 在后台的时候，断开连接，使用apn提示用户，唤醒app到前台后，重新连接，拉取离线消息。 im类的都是需要考虑消息到达速度，到达率，流量控制的。 消息数据越小，在相同网络情况下，耗时就少，速度就快。 xmpp在商用的时候，其实无效数据还是太多了，太费流量，不太好。

iOS上一般用长连接还是短连接？比如http之类

[zhu410289616]

推荐tcp长链接，支持双通道。 如果是http协议，那就是长短结合了。 一个长链接只能维持一个下行消息通道。 上行消息，还是需要用多个短链接的。

[utstar]

简单的即时消息使用xmpp好，还是mqtt更合适？

[zhu410289616]

引用 5 楼 utstar 的回复:

简单的即时消息使用xmpp好，还是mqtt更合适？

xmpp标签比mqtt多，单从节省流量方面考虑的话，推荐使用mqtt。 mqtt比较适合订阅推送类型的业务，看具体的场景吧，哈哈。

[不担心]

你也知道ios不支持真后台,所以在应用中保持长连接也不能保证你关闭应用后还能收到消息 目前想在关闭应用后还能收到通知只有apns比较靠谱

[solar]

这方面有什么好的实践经验啊？

[mikelibra]

第一通讯协议像腾讯 陌陌这种都是自己设计的协议，但肯定是按照某个基础框架进行改造的。第二、IM类APP基本不在前台的情况下不会长连接 ，后台以后就都是APN推送了，前台运行的时候都是有很完整的设计架构，能够随时监控网络状态并reset网络如 wifi 3G 4G切换 ，移动设备的网络状态是很不稳定的，比如在3G网络状态下可能会因为基站的切换导致连接失败等，所以长连接一般做不到的，只能中断后自动连接，一般客户端每次成功登陆以后都有一个 session token,然后重连的时候以此作为令牌进行验证避免用户因掉线而重复登陆，这些都是很复杂的协议，根本没有必要去从头自己设计，也不是随便谁能搞出来的，如果你正写一个IM的app一般可以使用通用协议如XMMP，但是这些都是很基础的，你不光要做客户端你还要兼顾服务端的后台设计，必须对服务端做轻量化的改造。还有一种办法是采用云服务，如leancloud，这些云服务已经把服务端做好了，并且会提供你一个sdk 你只要pod install或者用REST API就好了，其他底层的他都可以完成，你只需会用 node.js写服务器端的业务逻辑和hook函数，这样做的好处是节省开发时间更专注于于和用户打交道的客服端开发上，缺点是你的云服务商掐着你的喉咙，云服务出问题你也完蛋，而且有依赖性因为太方便了。当然你可以用REST API调用云服务，这样你就可以在后期设计自己的服务端和后台业务逻辑，最终从云服务上迁移出来。

[solar]

我现在试着在mosquitto基础上改造