首页 > 代码库 > 【转】推送怎么玩

【转】推送怎么玩

推送和移动互联的关系,已经密不可分。每天你收到的推送是各大app的强有力的吸引用户黏住用户的工具。

那我们来具体了解下推送吧。目前的两大平台ios和安卓的推送的实现是有很大差异的。以下分开描述。

 

IOS&android简要对比

IOS推送即APNS - Apple Push Notification Service,依托一个或几个系统常驻进程,是全局的(接管所有应用的消息推送)的独立于应用之外,是设备和苹果服务器之间的通讯,而非应用的提供商服务器。

比如,网易云课堂的服务器(Provider)给苹果公司对应的服务器(APNS)发出通知,然后再中转传送到设备(Devices)上。当你接收到通知,打开应用,才开始从云课堂服务器接收数据。

而android的推送是各应用有各自的单独后台进程和各自的服务器通讯,交换数据,来达到推送的目的。比如云课堂有自己单独的推送进程:com.netease.edu.study.enterprise:pushservice。

 技术分享
    当该进程被kill掉之后,则无法收到推送。IOS则不存在类似问题。 另外其实 Android 也有类似 APNS 的 GCM(Google Cloud Message),属于开发者可选,非强制。而 Google 不强制的结果就是:没人真正为用户的电池负责。也因为整个技术方案非强制, Android 的 Apps 在接收到推送后的表现更为灵活。

 

所以iOS 的消息推送机制使得应用本身不能有常驻的后台进程,系统的开销少,内存使用更少,而 Android 则开销更大。

 

推送的一般技术原理

要理解推送的实现原理,首先要了解device_token。

UDID - iOS Unique Device ID,是每个iphone的标识符,可以通过连接XCode查看到,如下图中的identifier就是该设备的UDID。

技术分享
 

 

 

Bundle ID(Bundle Identifier):一款iOS应用的唯一标识,应用与Bundle ID之间是唯一对应关系。应用新建成功后,Bundle ID将不可修改,如必须修改只能创建一个新的应用,届时App ID、App Key和App Secret也将重新分配,旧版用户将无法收到针对新Bundle ID的推送。

苹果服务器根据我们这一台设备的UDID和app的bundleID混编而成的deviceToken,我们需要将这个deviceToken传送给我们的服务器端,或者登陆用户的时候作为参数传给服务器.这样一个用户对象就绑定了一个deviceToken.当需要给这个用户推送消息的时候,我们自己的后台服务器,就会找这个用户对应的deviceToken和要发送的推送内容,直接发送到苹果的apns服务器,然后由苹果的apns服务器将消息推送到该deviceToekn对应的手机上。

 

deviceToken是ios设备在APNS上的标识(苹果服务器根据我们这一台设备的UDID和app的bundleID混编而成的deviceToken)用于推送服务。每个设备上的每个app有两个deviceToken,一个用于开发测试,一个用于生产环境。应用需要每次启动的时候都去注册远程通知,注册成功, APNs 会返回一个设备的标识符即deviceToken 给 App,一个用户对象就绑定了一个deviceToken.当需要给这个用户推送消息的时候,我们自己的后台服务器,就会找这个用户对应的deviceToken和要发送的推送内容,直接发送到苹果的apns服务器,然后由苹果的apns服务器将消息推送到该deviceToekn对应的手机上。

 

 

在需要发送push时,我们的服务端就会取出要发送的设备的device token,然后以下图所示的结构,组成字符串,然后将其发送到的APNs 

 

技术分享

 

第一个部分是命令标示符,第二个部分是我们的deviceToken的长度,第三部分是我们的deviceToken字符串,第四部分是推送消息体(Payload)的长度,最后一部分也就是真正的消息内容了,里面包含了推送消息的基本信息,比如消息内容,应用Icon右上角显示多少数字以及推送消息到达时所播放的声音等。

 

 

整个过程是这样:

首先,设备安装了具有推送功能的应用, iOS设备在有网络的情况下会连接APNs推送服务器,连接过程中,APNS 服务器会验证device_token,连接成功后维持一个基于TCP 的长连接;Provider(我们自己的应用服务器)收到需要被推送的消息并结合被推送的 iOS设备的device_token一起打包发送给APNS服务器;APNS服务器将推送信息推送给指定device_token的iOS设备,iOS设备收到推送消息后通知我们的应用程序并显示和提示用户(声音、弹出框)。

技术分享

技术分享
 

 

安卓推送

GCM 

Google Cloud Messaging是 Google 自己的一套推送服务,也是系统级别的,但是众所周知,Google 的服务在国内根本没法使用,只能放弃。

轮询

轮询是最简单的与服务器保持通信的方式,即循环向服务器通信。这个方案的特点就是通信由客户端主动发起,你需要自己实现轮询消息队列、频率等等参数,在功耗和效果间做权衡,类似于TCP的短连接。

SMS

这个其实就是借助短信来实现信息的展示,只不过把短信内容展示到了Notification中,这个方案,到达率确实高,毕竟短信是比较可靠、稳定的,但劣势也很明显,就是成本很高,而且在Android平台上,短信的权限比较开放,容易被劫持。

长连接

长连接和前面提到的短连接,都是基于Socket连接的方式,他们的区别在与,短连接是每次数据传输完毕后就断开连接,而长连接不会。所以,基于轮询的方式,每次都要进行链路的连接,性能消耗更大,基于长连接的方式,就是对这点的改进。应用一旦与服务器连接成功,并不会主动断开连接,后面的通信都基于这个通道。目前大部分的推送服务都是基于长连接的推送,在后台维护一个Service,维持应用与服务端之间的TCP长连接。目前基本上是最多选择的方案。

但是目前基于成本上的考虑,大多数中小型公司都会选择使用第三方推送服务。

 

第三方推送服务

目前来说做的比较好的推送服务大概有小米推送、腾讯信鸽推送、百度推送、极光推送、友盟推送等。这些推送服务大都有以下特点:

免费

当然部分公司也有收费的,号称更稳定、推送到达率更高,但大部分都还是用的免费版。

服务会被杀死

由于 Android 系统的机制,后台推送 Service 会被各种主动的或是被动的行为给杀死,而服务一旦被杀死,意味着就接收不到推送消息。

多个 app 共用一条推送通道

什么意思呢?就是如果有多个 app 都使用了同一家推送服务,那么这些 app 共用一条消息通道,即使你家的 app 推送服务被杀死了,那么只要用户打开了其他集成该推送服务的 app ,你家的推送就能接受到消息。比如云课堂企业版现在使用的小米推送服务,云课堂企业版被杀死了,但是手机上只要其它也使用小米推送的app的进程还在,云课堂企业版还是能接收到推送消息。

 

每家的推送服务都号称推送到达率很高,号称自己家的推送服务更不容易被杀死,号称自己的推送更稳定更有保证,然而我要说的是,各家都差不多,技术上你能实现的,别家一样能实现,到达率也都差不多,据我观察平均推送到达率能达到 70% 左右都算不错的了,那么到底该怎么选择呢?

 

有一点比较特殊的是有些推送服务有自己家品牌的手机,比如小米有自己的手机,而在 MIUI 系统上小米推送是作为系统级的服务,不会被杀死,毕竟一家人,总不至于傻到把自己家的服务给干掉吧?所以这就是一个巨大的优势了。类似的华为推送服务在自己家的手机系统上也不会被杀死。

 

各大手机厂商都宣传自己家的手机市场份额第一,然而我要说的是如今市场上的 Android 手机只分小米手机跟其他手机,什么意思?就是小米手机是目前市场份额第一,而且远远领先其他手机,这个在我们自己家 app 的数据上看就是这样,而这里有一份友盟发布的 Android 设备活跃的排名数据,地址在这里:http://www.umindex.com

以小米手机的市场份额,加上小米推送在 MIUI 上不被杀死这一大特性,致使选择小米推送是第一选择。目前云课堂企业版安卓也选择了小米推送服务(哈哈)。

所以,你可以选择直接集成某个第三方推送,如果你想要把推送更优化下,那么可以集成多个推送服务,针对不同的渠道用不同的推送,比如小米渠道用小米推送,华为渠道用华为推送,其他渠道用信鸽推送等,但是这种也比较麻烦,具体怎么做看自己利弊权衡。

【转】推送怎么玩