IM的App的Push推送和长连接的关系

IM的App本身会建立一个长连接，用于消息收发，那进入后台一段时间后，如果没有心跳，长连接就会变得不可用，这个时候直接使用push不就可以了吗？App本身还有必要通过心跳机制去维护长连接吗？还是说我们维护的长连接是给push推送用的（即App本身的长连接和Push的长连接是同一个吗）？保活是维护的App本身的长连接吗？作为新人的我有点区分不出这两者的关系了。

从IM的角度讲，IM的长连接其实包含了这个Push能力，没有必要再单开Push通道。但凡事都有例外。

在移动端的IM里，很多时候Push和IM本身的长连接是两回事，尤其在iOS端，那必须是两回事，因为当程序处于前台运行时，IM的长连接可以正常运行时就不需要的iOS的Push通道，而当程序退到后台，自身的IM长连接不可用时，就要切到iOS的Push通道。所以，在iOS的IM上，这两个连接和通道的分工是很明确的。

但在Android端就有点特殊，因为Android各厂商Room的差异性，进程保活和网络保活很困难，很难保证IM自身的长连接能正常工作，所以很多IM会在自已的IM退至后台时切到第3方的Push通道， 因为自已的技术水平和实践经验还无法匹配第3方厂商的适配和实践经验，所以取长补短，就这么干了。但是，单开Push通道并非必须项，如果你的IM自已的长连接就能解决进程和网络保活，那还有什么必要单开Push通道呢？两者的切换和协调技术实现上本身变很烦，能用一条连接解决的，为何要用两条？你说呢。

归根结底，IM的“即时通讯”能力的本质，就是解决“实时”问题，对而IM自身的长连接是IM能被称为“即时通讯”的根本所在。而对于传统的APP来说，没有“即时”能力，所以为了实现一些实时的交互，就挂载了第3方的Push系统，而这个Push实际上就是IM里自身即时通讯长连接的简化版。所以，Push实际上是专门用于非IM的特殊场景下，它的技术就是IM即时通讯技术的一种衍生或者说是借用了IM的部分技术能力来达到这种“实时”的体验。

“即时”对于很多应用来说，都是梦寐已求的，但在普通应用里，造一个IM的即时通讯通道，还是很困难的（而且第3方应用所需的Push通道，确实不需要真正IM的即时性以及其它更复杂的性能），所以第3方Push就应运而生了，也可以说Push技术是对这种“即时”通讯能力的一个提炼和产品化的结果。

你可能会奇怪，很多非iOS的IM里为何使用了Push？原因是Push是据IM的技术简化和提炼而来，而很多开发人员并非能完全驾驭好IM技术的方方面面（要真正开发出产品级的IM技术还是很困难的），所以很多人会用Push技术来反哺IM，这其实是有点“凑”技术的嫌疑了，但无论如何，至少能整出一个差不多可以用的IM了，有何不可？

不知我有没有回答好你的问题。

引用：JackJiang 发表于 2016-11-21 19:48
从IM的角度讲，IM的长连接其实包含了这个Push能力，没有必要再单开Push通道。但凡事都有例外。

在移动端 ...

那对于小米和华为的一部分机型，在后台一段时间后会断开网络但是不杀进程，App自己的长连接通道始终会被断开的，这个时候心跳机制也没有用了，这种情况如果不转入小米或华为本身的push，IM的“即时通信”不就无法保证了吗（除非可以加入他们的白名单）？是不是对于这类的机型Push和IM的长连接同时存在就是必须的了呢？

引用：张小驰 发表于 2016-11-22 11:01
那对于小米和华为的一部分机型，在后台一段时间后会断开网络但是不杀进程，App自己的长连接通道始终会被 ...

基本上是的，因为小米的推送、华为推送实际上就是学iOS的APNS推送，目的就是不想让同一台手机上的各种应用都去自已搞长连接，那样太费电。也就是说小米和华为的手机，最好还是得用它的推送，除非你的应用能跟手q、微信一样牛逼，进入它们的白名单就不会杀了。

以前PC端IM时代没人提什么Push，都是现在搞移动端了之后，才整出这么些复杂的技术概念

用不用Push主要是Android上的区别，Android平台分化太严重

回答的通熟易懂，赞

新人路过~~

支持一下