你这是IM是吧
如果你这本身就是个IM，有稳定长连接的情况下，就不需要使用第3方通道来推送。但如果你Im处于后台或被系统杀死的情况下，可以用第3方推送，因为第3方可以通过其它方式进行进程保活和通道拉活，否则你自已就得折腾网络和进程保活这些，这是很烦人的（具体你可以看看这里的文章就知道了：http://www.52im.net/forum.php?mo ... &ctid=17&fromop=all）。

总之，在你的IM长连接处于“活”着的状态时，肯定用你自已的长连接通道，你的app处于后台（比如ios上）或被杀死的情况下才考虑用第3方。

其实第3方推送还有一个问题就是：它的产品目标定位是“推送”，推送的实时性跟IM本身的实时性要求是不一样的——推送里最重要的指标是送达率，而实时性并不是首要指标。就像你手机上的一个普通APP，它的广告推送这些信息，什么时候推给你的（是1分钟前、10 分钟前还是1个小时前并不重要），对你而言或对于运营方而言只要能推送到就行了，而IM肯定是一刻都不能等，试想你跟朋友两个人正在聊天的时候，让你一条消息等个半天或者毫无时间节奏规律可循，你这im的体验就可想而知了。

你这是IM是吧
如果你这本身就是个IM，有稳定长连接的情况下，就不需要使用第3方通道来推送。但如果你Im处于后台或被系统杀死的情况下，可以用第3方推送，因为第3方可以通过其它方式进行进程保活和通道拉活，否则你自已就得折腾网络和进程保活这些，这是很烦人的（具体你可以看看这里的文章就知道了：http://www.52im.net/forum.php?mo ... &ctid=17&fromop=all）。

总之，在你的IM长连接处于“活”着的状态时，肯定用你自已的长连接通道，你的app处于后台（比如ios上）或被杀死的情况下才考虑用第3方。

其实第3方推送还有一个问题就是：它的产品目标定位是“推送”，推送的实时性跟IM本身的实时性要求是不一样的——推送里最重要的指标是送达率，而实时性并不是首要指标。就像你手机上的一个普通APP，它的广告推送这些信息，什么时候推给你的（是1分钟前、10 分钟前还是1个小时前并不重要），对你而言或对于运营方而言只要能推送到就行了，而IM肯定是一刻都不能等，试想你跟朋友两个人正在聊天的时候，让你一条消息等个半天或者毫无时间节奏规律可循，你这im的体验就可想而知了。