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 的认识都是错的 」。
不言而喻，当然是尽早升级 >客户机/服务器应用模式:由客户机(client)、服务器(server)、中间件三部分组成。客户机的主要功能是执行用户一方的应用程序，提供GUI或OOUI，供用户与数据进行交互。服务器的功能主要是执行共享资源的管理应用程序，主要承担连接和管理功能。中间件是支持客户机/服务器进行对话、实施分布式应用的各种软件的总称。它是Client/Server实施中难度最大也是最重要的环节，其作用是透明地连接客户机和服务器。
基于Web的客户机/服务器应用模式:基本思想:把目前常驻在PC机上的许多功能转移到网上，对用户而言可减轻负担，大大降低维护和升级等方面的费用。实现:基于Web的客户机/服务器模型可提供“多层次连接”的新的应用模式，即客户机可与相互配合的多个服务器组相连以支持各种应用服务，而不必关心这些服务器的物理位置在何处。本质:可将整个全球网络提供的应用服务连接到一起，让用户所需的所有应用服务都集成在一个客户/网络环境之中。
把Internet技术运用到企业组织内部即成为Intranet，其服务对象原则上以企业内部员工为主，以联系公司内部各部门、促进公司内部沟通、提高工作效率、增加企业竞争力为目的客户机/服务器应用模式涉及到三项新技术:WEB信息服务、Java语言、NC(用来访问网络资源的设备)。