Android&iOS推送

1.推送的由来:

推送兴起于Email,用于提醒用户邮件的更新.  后续由于移动互联网的迅速发展,推送被广泛应用.

2.推送的原理:

推送的本质原理是客户端与服务器之间的长连接.  基于长连接,服务器可以主动向客户端推送消息, 客户端收到推送消息来展示给用户.

3.推送的实现方式:

方案1-push: 客户端与服务器维护一个TCP/IP的长连接,当有推送消息时,直接向客户端push.

方案2-pull: 客户端定时向服务器pull请求.  

两种方式相比较而言, 方案1更合理更有效, 方案2会存在客户端不能长久在后台存活以及消耗电量以及消耗流量等问题.

4.iOS推送:

苹果官方推送: APNS.  APNS是由苹果官方维护的, 属于系统级别,所以推送消息比较稳定.

iOS的所有推送信息, 都会发送到苹果服务器,然后由苹果服务器下发到客户端.

5.Android推送:

谷歌官方推送: FCM.   FCM是由谷歌官方维护的,同iOS一样, 所有推送信息都会发送到谷歌服务器,再由谷歌下发到客户端.

由于谷歌推送不能在国内使用, 所以需要Android开发者自己去维护长连接.

6.Android推送开发:

方案1:  MQTT推送,  此推送是由IBM提出的轻量级的推送, 客户端与服务器之间通过心跳包来监测对方是否存在,然后通过订阅&发布来实现消息的推送.但是缺点也很明显,当客户端被杀死后会无法收到推送.

方案2: 第三方推送, 如腾讯信鸽, 友盟+, 极光推送,小米推送等.目前很多Android的APP在国内都是使用第三方的推送.

方案3: 公司基于XMPP协议开发. 谷歌的推送也是基于XMPP协议开发的.

iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器

所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。

然后，系统根据该 IM 消息识别告诉哪个 App 具体发生了什么事。

然后，系统分别通知这些 App

而 Android每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。

其实 Android 也有类似 APNS 的 GCM（Google Cloud Message）的服务，如果一个应用的推送采用这种模式的话，就和iOS推送一个样了。

GCM相关的程序应该是集成在所谓的Gapps中，但国内的 Android 手机上 GCM 处于基本不可用的状态，而且Android 因为后台可以长驻，所以，App们各显神通。

聊天类应用的话，大多数直接借用 XMPP 规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与 APNs / GCM 没有本质的区别，但有一定的技术门槛。

而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现，就是定时去服务器上查询数据，也叫Polling，还有一种手机跟服务器之间维护一个 TCP 长连接，当服务器有数据时，实时推送到客户端，也就是我们说的 Push。

轮询的方式不论怎么优化都比较费电费流量，长连接的方式在网络不稳定的情况下，Socket比较容易断开推送数据失败，

安卓推送可以考虑使用第三方推送工具，比如极光推送

iOS

的推送iOS

在系统级别有一个推送服务程序使用

5223

端口。使用这个端口的协议源于

Jabber

后来发展为

XMPP

，被用于

Gtalk

等

IM

软件中。所以，

iOS

的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个

...iOS

的推送

iOS

在系统级别有一个推送服务程序使用

5223

端口。使用这个端口的协议源于

Jabber

后来发展为

XMPP

，被用于

Gtalk

等

IM

软件中。所以，

iOS

的推送，可以不严谨的理解为：

苹果服务器朝手机后台挂的一个

IM

服务程序发送的消息。

然后，系统根据该

IM

消息识别告诉哪个

Apps

具体发生了什么事。

然后，系统分别通知这些

Apps

。应该说，苹果这种方式在技术上没有什么创新。但是，整个架构是很了不起的。

因为：

1

使用久经考验的协议，技术风险小。

2

苹果勇于承担责任：

他需要维护一个代价不小的服务器集群，而且要为服务器的

down

机负责。

选择低风险的技术方案

Bug

更少，减轻了用户的痛苦，这是构架师的功劳。

苹果承担责任，尽可能的减少了不可控的意外，保证了用户体验。

这，只能说是公司决策者的功劳。

（从侧面说明有个懂技术的

VP

是多重要。。。而

Scott

走人了。。）

他们带给用户的好处也是实实在在的。

1

安全。

只有登录过的开发者可以通过苹果的服务器推送。

2

快速，稳定，可靠。

苹果掌控推送服务器和

OS

。

3

更省电。

4

让整个系统的体验更统一和简单。

不会出现杀后台这种脑残事。（不用大量

Apps

/

Apps

的服务为了推送挂后台）。

也不会出现

Apps

被杀就收不到推送这种脑残事（早一点的新浪微博

Android

版仍然如此）。

5

开发容易。

当然，开发者还是要做些事情，比如维护个服务器什么的

。但是复杂度无疑降低很多了。

Android

的推送

Apps

挂后台一直是

Android

引以为豪的特性（虽然我真的不知道是好处多还是坏处多。。）。。。大家挂后台等待推送就成为技术选择。

当然，

Google

事后也提供类似苹果的推送方式了。倒也谈不上抄袭，毕竟苹果的整个技术实现也没有什么特别创新之处。

用户的电池？

Apps

的开发者不会站在系统层面考虑的。他会假设其他

Apps

没有那么“不自觉”。而

Google

不强制的结果就是：没人真正为用户的电池负责。

但是，

Google

的方案也并非全是悲剧：

也因为整个技术方案非强制，

Android

的

Apps

在接收到推送后的表现更为灵活。

像

Line

的

Android

版本可以在推送通知的

Popup

上直接回复，

iOS

就需要越狱才能做到了。

最后的话

强制和封闭，有时候并非坏事。他意味着做出这个决定的人，要为此负责。

所以，如果说苹果的推送方案有何创新？

我以为是超越技术，不惜让公司承担更多风险和责任的解决方案。（类似的还有

BB

的专用网络，

Kindle

的全球

3G

）

---