iOS 必知必会 - APNs篇

导语：

由于移动设备内存、CPU、电量的局限性，iOS 不允许 APP 的进程常驻后台（事实上可以申请后台运行一段时间，最长约 10 分钟），这样当用户主动杀掉 APP，或者 APP 进入后台超过约定时长时，就意味着该 APP 进程的结束。这在很大程度上保障了前台 APP 的流畅性，也延长了手机的使用时长，获得了较好的用户体验。但是这也意味着，服务器无法主动和用户交互（如推送实时消息等）。为了解决这个限制，苹果推出了 APNs，允许设备和服务器分别与苹果的推送通知服务器保持长连接状态。

iOS 的通知分为本地通知和远程通知。本地通知是由本地应用触发的，一般是基于时间的一种通知形式，如闹钟、待办事件等的提醒。远程通知是由开发商通过自己的服务器推送的一种通知形式，而 APNs 就是远程通知功能的核心。

关于远程推送，记住以下两点就够了：

这里就很清楚了，其实 APNs 的本质就是 服务器和客户端之间的中介 。当服务器需要给客户端推送消息时，先将消息发送给苹果服务器，再由苹果服务器找到对应设备推送下去。

那为什么还要走中介，不直接发送呢？因为这样做一个设备（即所有 APP ）只需要和苹果的服务器建立一条长连接，而不需要每个 APP 都和服务器建立一条长连接。

可能有些人还是不太明白 APNs 的意义，觉得也只是将多个长连接变成了统一的一个长连接而已，有必要那么做吗？

很有必要！

我们来看下 Android 的推送现状就明白了。

Android 事实上也有类似于 APNs 的一套用于推送的服务，简称 GCM，即 Google Cloud Messaging。但由于 GCM 需要谷歌服务器的支持，在国内由于「墙」的原因基本不能使用。这下就热闹了，国内出现了一大堆第三方推送服务商，如华为推送、小米推送、极光推送等。APP 通过集成这些推送服务来实现推送功能，而这些推送服务为了保持自己的长连接不被杀死，采用了各种保活、唤醒手段，这也是 Android 手机使用不流畅的真凶。之前也有看到「 工信部要求国内安卓统一消息推送标准 」的新闻，工信部都这么重视，可见统一推送的意义非凡。

想要了解具体区别，可以参考这篇文章 「 国内 90%以上的 iOS 开发者，对 APNs 的认识都是错的 」。

不言而喻，当然是尽早升级 HTTP/2 协议了。

参考:

（完）

实际上安卓也就是google是有像苹果APNS的推送服务器的，但是在国内没有服务器。

如果你的应用走后台进程一直连接服务器，将会非常耗电，如果还非常耗流量，那你的应用会被用户咔嚓掉。

安卓现在缺少一个整合的推送服务。像ios一样，专门的推送进程与苹果官方推送服务器连接。如果安卓各个应用都连接各自自己的推送服务器，不好管控，也非常费流量，实际上都是伪推送。

哦对你说的极光推送是个第三方，口碑还不错，你可以试一试，也可以减轻自己的研发负担。

推送系统最早其实是黑莓的专利，后来ios非常聪明的学去了，而且学的很好。在推送之前很多智能系统只能通过轮询的方式不断定期向服务器询问是否有新信息，往往费电和费流量。

ios建立了一个统一的服务器，APNS（Apple Push Notification Service），简单的说，我们在手机上接收到的所有推送信息都来源于这个服务器，每一台ios设备都有一个独立的识别码相当于。那么当你用这个登录了某个软件（比如米聊）后，就连接到了米聊的服务器上，在推送体系中这个目标服务器被称作Provider。接着你看完消息，退出米聊后，进程结束，但是此时你这个的登录状态并没有在Provider里注销，而是保留了。因此如果有人给你的米聊发送了信息，就会触发Provider的行为，但是由于你关闭了米聊，所以它无法直接向你的手机发送消息，于是它转而向APNS发送信息，顺便带着你的。然后万能的APNS就顺着找到你，然后把消息塞到你的手机里。只要你ios设备的推送不关闭，流量不关闭，那么你的设备就会一直和APNS保持连接，从而达到24小时接受推送信息的目的。有人应该已经明白了这样做的好处，因为你只和一个服务器产生连接，省电省流量。另外由于APNS服务器的广域和强大的稳定性，以及该服务在ios属于固定的API接口，使得整个推送系统稳定而健壮。不过顺便一提ios的邮件推送是另一套完整的PushMail系统，和这个无关。

那么为什么安卓的推送没有ios给力？其实在Android2.2之后，谷歌也建立了类似ios一样的推送系统——Android Cloud to Device Messaging（C2DM），但是为什么这个系统没有APNS给力呢？主要是C2DM的服务器对于国内来说是外面的东西，由于谷歌在国内受到了一些格外的照顾，这个服务器也就显得不那么给力，这是国内厂商多不选择C2DM的重要原因。另外Android开源和API的开放提供了其它推送的选择。在C2DM不给力的情况下，一些软件选回了老的轮询方式的（凡是软件里需要你自己选择多长时间检查一次有没有更新的软件都是轮询方式）来提供消息，这种方式有相当的不稳定因素，在机器内存紧张的情况下驻留的http服务容易被回收，还更费电费流量。更多软件厂商则选择了利用Android的自由的XML的API接口自己搭建XMPP服务器来直接向用户推送消息，缺点同样是驻留的服务容易被回收，尤其对于小内存机器和在内存管理上时常有技术性溢出（回收机制缺陷）的MIUI来说如果不锁定服务的内存那么就可能出现收不到推送的情况。总体看来由于安卓推送机制的缺陷和进程的不统一（你装米聊微信微博就等于后台有了三个推送进程），整体上的健壮性得不到保证，也更加费电和费流量，与ios统一而健壮的推送服务有了很大的差距。

综上所述安卓系统的推送问题是并不是MIUI小组可以企及的，就算MIUI强势到能够建立一个墙内的推送服务器，也需要说服众多的软件厂商去使用他们的服务器，这就意味着需要有“米聊MIUI版”“微博MIUI版”，更加加剧了安卓生态圈的分裂。

至于在Android4.0时代安卓能否改变这个现状我只能持谨慎乐观态度，因为其开源性和向下兼容的API整合使得这种现状更有可能延续下去而不是改善。

---