ios 8.0 下载并安装 iOS Push的前世今生

网上介绍iOS Push的文章有很多，但是大部分都总结得非常零散，加上之前也一直没好好总结过，对某些地方也不求甚解。于是抽空把苹果这套复杂而有趣的推送机制总结了一遍，终有此文！

注意：本文大部分内容基于iOS10新增通知框架UserNotifications。

目录版iOS Push的前世今生

全文导图

对Push的理解

苹果对Push的所有优化最终目的都是为了提升用户体验。这一点上不得不佩服Apple！

在讲Push之前先谈谈为什么需要推送。对用户而言大部分就是为了获得最新的信息，感兴趣的资讯；对app开发者而言大部分是为了通过推送让用户打开app增加日活（别喷我），其次是为了向用户提供更好的资讯；对苹果而言因为iOS系统给app在后台最多存活的时间最多三分钟（后来新增后台模式后增加到十分钟），为了保证这个iOS平台能够给用户良好的体验（对推送可控），app可以主动和用户沟通。

对APNS（Remote Push）的理解

可以通俗的把APNS理解为iOS系统为每个app提供的长连接通道。只是这个通道需要通过苹果中转，为什么苹果要设计这么一套服务呢。上面也提到了过，下面在针对用户体验详细一点介绍。

提升用户体验：苹果限制了每个app在后台存活的时间，最重要的目的是为了省电，其次优化内存这些。如果彻彻底底的将app杀死了，服务端永远不能主动和客户端建立联系。所以需要一种机制来保证在必要的时候让用户知道服务端所做的改变。技术上只要只有长连接可以做到。

便于苹果、用户控制：如果直接让app和服务端建立长连接（比如iOS8之前的voip，就是app在后台保持长连接），苹果是不能控制的。所以通过在app和服务端中间加一个APNS可以有效的进行拦截处理。比如可以由用户开启是否接受远程推送。退一万步讲，如果哪天苹果对你上架的app进行了下架处理。即使有用户安装了你的app，切掉你的APNS，用户也无法收到推送，除非用户自己点开app否则你的app永远不会存活。

APNS缺点也很明显

可靠性、稳定性。一般情况下，Apple会保证这个通道的Qaulity of Service，也就是推送的消息能及时稳定到达设备。不过一旦用户的设备处于offline状态，Apple只会存储发送给用户的最新一条push，之前发送的push会被直接丢掉。而且这最后一条离线push也是有过期时间的。一些用户应该有过这种经历，在使用某些的时候，明明对方发送了多条消息，却只收到了一条push。

消息大小限制：由于苹果APNS服务于以万计的app，所以对消息内容大小有严格限制。只能传递一些文本信息。Apple在文档里清楚的说明，push只应该用来通知用户有新的内容，而不应该用来承载内容本身。理论上payload size越小，push到达设备的概率就越高。苹果一直在改善，在iOS8之前max payload size是256字节，到iOS8发布这个最大值被调整到了2048字节，再到的iOS9发布，引入了HTTP2.0，payload size又被设为4KB（4 * 1024字节）了。

对Local Push的理解

有了APNS（Remote Push）为什么苹果还搞了一套Local Push呢。从笔者的角度能做出如下猜测:

苹果开发者中，有很大一部分是个人开发者。对于个人开发者而言，做一款小型的app，很多时候用APNS需要搭建服务，成本太高。

APNS前提条件是必须在联网的状态下，这样一些不需要联网的app，比如日程提醒类，就和Push彻底告别了。但是对于这种小型app，Local Push非常适合。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/shouji/article-74387-1.html