GCM(Google Cloud Messaging) 推送流程分析

GCM 就是Google 为开发者提供的一种云推送服务，前身为C2DM （Cloud to Device Message ） 。开发者可以注册Google账号后开通该服务，可以配置自己的Server 和 Android App 来完成业务所需的云推送服务。

如果对GCM不太了解的话，可以通过下边链接去瞅瞅 Google cloud Messaging简介

接下来介绍一下GCM 使用的一些弊端：

  • 安全问题，既然用别人的东西肯定就避免不了这样的问题.
  • Google 服务器自从被搬走之后，关于Google的各项服务基本上与中国大陆的使用者无缘了。
  • 当然GCM 也包括在内，去年在没有搬走之前，在公司测试消息推送也是时灵时不灵，连接到台湾服务器之后信息发送完全正常。
  • 国内厂商部分没有GMS包（GoogleMobile Service），应该说是缺失系统组件。

为什么要写这样的文章：

  • 珍惜每一粒收获的种子。觉得当时辛辛苦苦学习出来的技术，如果长时间不用或者不把技术精华记录下来，时间久了就真的淡忘了。
  • 因为GCM是成熟的推送机制 有值得我们学习的地方，包括整个推送架构的设计思路以及源码的设计思路都值得我们去学习。
  • 国内大部分推送公司推送架构基本类似。

我们如何开始:

考虑了一下，GCM一个成熟的推送机制，也并不是三言两语能够说清楚，况且我觉得我自己了解到的也只是一部分。所以我决定记录一下几个部分 由于整个过程是倾向于流程性的，所以账号注册，开启Service， 部署使用，等等我就不做为详细记录内容。 如果想尝试学习如何使用GCM GCM教程

GCM 整体简单流程简介

先上一张官网图片，看一下： gcm （图1）

整个流程非常的简单， 就是通过自己搭建的Server，请求推送给GCM Server， GCM Server 接收到请求，然后通过长连接的方式推送消息给Android app device 。 同时 GCM Server返回消息给 自己搭建的Server(LibService) 看一下整个Sequence 图，整个过程非常明显：

gcm-push-sequence

（图2）

GCM LibService 流程分析

gcm_libservice_deploy （图3）

GCM Android 流程分析

gcm-android-process

（图4）

GCM+LibService+Android 流程分析

devloper-seq

（图5）

国内常用的推送平台以及信息安全

** 常见推送平台 **

各种功能总是伴随着需求产生的，推送方案的公认评价采取4s标准:

  • Safe(安全)
  • Stable(稳定)
  • Save(省电省流量省成本)
  • Slim(体积小，便捷)

具体标准，

  1. Safe (安全)

  • 推送方案应支持透传及各种加密方案,保障信息传递安全。

  • 推送方案的ID系统应该独立于已有的网站或服务的ID系统,这样保障用户在不同手机上登录后的信息投递准确性,避免因为取消绑定事件失败因网络传输而造成的信息误投送。

  1. Stable(稳定)

稳定包括两个部分一个是服务器端的稳定性,一个是手机端的稳定性。

服务端稳定性,因为使用长连接方案,对服务器的开销和要求很大,推送方案对服务器开发要求很高,海量线程连接下的服务器稳定性是非常具有挑战性的。

一般的评判标准包括:

  • 同时在线时峰值 (一般按照百万并发连接时服务器稳定性评测)

  • 高并发时消息平均延迟时间(一般按照1分钟处理1百万条信息评测)

  • 服务稳定性 (一般要求全年99.9%以上可用,有备份,有负载均衡等)

鉴于服务器稳定的开发难度很大,小团队不建议自己开发,建议使用稳定的第三方推送方案,如个推,友盟,极光,百度云推送等。

手机端的稳定性,主要是因为中国的复杂网络状况及手机型号适配情况造成手机长时间稳定联网较困难,所以稳定性非常重要,一般的评判标准包括:

  • 每日联网23.5小时以上用户比例 (表征联网稳定性)

  • 消息发送后9小时内收到率 (表征到达率)

一般来说,推送方案要做网络的分运营商,分省,分机型适配,自己开发工作量较大。

  1. Save(节省)

  • 省电应注意CPU休眠,一般用服务缩短待机时间百分比评判。

  • 省流量应注意协议的修改和冗余数据包的处理,一般用空载待机月流量评判。

  • 省成本应考虑单服务器承载同时连接数,可承载同时连接数越多成本越低,业内顶尖水平为个推的单服务器300万连接。

  1. Slim(体积小)

客户端推送服务SDK应该体积尽量小，使用起来便捷,不影响主程序的大小和复杂度,一般以小于或等于300K为宜。

我们看一下国内关注度比较高的几种推送平台：

compare

（图6）

这是引用百度经验的图。里边对比了国内常用的几种推送。当然现在随着小米MIUI的用户群不断的增加，小米推送也逐步走进舞台中心。

个人觉得小米推送伴随着他自身逐步强大的MIUI用户，小米推送依赖系统框架推送的优势也越来越明显，据我了解的，比几个常见的应用，例如淘宝，58，爱奇艺，金山词霸…

手机流量用的比较快，我就通过数据流量控制将淘宝数据网络给禁用掉， 神奇的事情发生了， 一条推送最新活动信息 竟然从服务器端push过来了, 这大概就是依赖系统框架推送的优势吧。

** 信息安全**

上面评估的4s标准，第一条就是安全，下边主要说一下安全的意识与防范。

信息安全很重要，要不然自己推送的信息，全部给第三方平台获取了，特别是牵涉到验证信息，付款信息等用户敏感信息时。

当然这些都可以进行服务器端，客户端进行约定加密。现在发布的app 可逆性也很高，如果被反编译了呢? 等等因素。

防范方法也很多， 使用与服务器交互产生动态密码，将敏感信息用短信方式通知用户等等。

如何搭建设计适合自己的推送平台

第三方推送，再好也是第三方的，其中间的三方环节不可控， 得不到保障。

如果是在公司内网，要求内外网通吃呢？显然第三方推送就有点相形见绌了。

如果条件允许的话为什么不自己搭建一个推送平台呢？

如何适合自己的推送平台

总结

以上就是整个GCM推送平台的推送流程研究，以及其他方面内容。 整个文章写得比较仓促， 如有不足之处请及时拍砖， 评估四条标准引用了网络上其他的资源未来及告知请见谅。

Table of Contents