为何微信、QQ这样的IM工具不使用GCM服务推送消息？

因缺少移动端即时通讯工具开发经验，对目前主流的移动端IM的消息推送机制有很大疑问，不知有没有人知道。

GCM全称是：Google Cloud Messaging for Android，是Google为android手机开发的类似于iOS的APNS后台消息推送机制。

使用GCM推送服务的whatsapp即使后台程序和服务都关闭掉，也依然可以在第一时间接收到新消息的推送（实测在国内whatsapp也的确可以在后台关闭的情况下正常通过GCM接受实时消息）。

同样是IM软件，为什么微信不使用GCM的机制而要自己开启一个Service常驻后台轮询，并且还要使用多种方式触发该Service导致无法关闭，这种机制既耗电又浪费网络资源，微信放弃成熟的GCM推送机制而使用自身后台服务的软件是否有其他自身目的性？还是说微信某些功能必须自身常驻呢？

有人说考虑到某些网络运营商的问题，GCM可能有不稳定性，但开发APP的时候就在网络连接这里增加一个用户可选的通过GCM进行推送的选项（默认可以使用程序自身Service），我想这样对于大多数3G网络用户来说更人性化一点吧。

我的设备上安装的IM和社交工具及带推送的服务软件十来款，都在后台以Service运行，现在手机感觉越用越费电，查看后台CPU唤醒发现几乎每个APP的后台Service都会每隔几分钟唤醒一次系统联网轮询，由于各个软件的轮询设置和服务设置不一，手机在不使用的待机状态下，几乎有一半以上额时间都是处于被各种服务唤醒状态而非进入休眠，待机状态下1小时都要掉电近10%，这很伤不起，腾讯的微信作为国内IM的老大，应该更为用户体验做考虑才对。

谢谢分享

懂了

全站即时通讯技术资料分类

[1] 网络编程基础资料：
《TCP/IP详解 - 第11章·UDP：用户数据报协议》
《TCP/IP详解 - 第17章·TCP：传输控制协议》
《TCP/IP详解 - 第18章·TCP连接的建立与终止》
《TCP/IP详解 - 第21章·TCP的超时与重传》
《理论经典：TCP协议的3次握手与4次挥手过程详解》
《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》
《计算机网络通讯协议关系图（中文珍藏版）》
《NAT详解：基本原理、穿越技术(P2P打洞)、端口老化等》
《UDP中一个包的大小最大能多大？》
《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》
《NIO框架入门(三)：iOS与MINA2、Netty4的跨平台UDP双向通信实战》
《NIO框架入门(四)：Android与MINA2、Netty4的跨平台UDP双向通信实战》
>> 更多同类文章 ……

[2] 有关IM/推送的通信格式、协议的选择：
《为什么QQ用的是UDP协议而不是TCP协议？》
《移动端即时通讯协议选择：UDP还是TCP？》
《如何选择即时通讯应用的数据传输格式》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《移动端IM开发需要面对的技术问题（含通信协议选择）》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《理论联系实际：一套典型的IM通信协议设计详解》
《58到家实时消息系统的协议设计等技术实践分享》
>> 更多同类文章 ……

[3] 有关IM/推送的心跳保活处理：
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
>> 更多同类文章 ……

[4] 有关WEB端即时通讯开发：
《新手入门贴：史上最全Web端即时通讯技术原理详解》
《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE技术详解：一种全新的HTML5服务器推送事件技术》
《Comet技术详解：基于HTTP长连接的Web端实时通信技术》
《WebSocket详解（一）：初步认识WebSocket技术》
《socket.io实现消息推送的一点实践及思路》
>> 更多同类文章 ……

[5] 有关IM架构设计：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
>> 更多同类文章 ……

[6] 有关IM安全的文章：
《即时通讯安全篇（一）：正确地理解和使用Android端加密算法》
《即时通讯安全篇（二）：探讨组合加密算法在IM中的应用》
《即时通讯安全篇（三）：常用加解密算法与通讯安全讲解》
《即时通讯安全篇（四）：实例分析Android中密钥硬编码的风险》
《传输层安全协议SSL/TLS的Java平台实现简介和Demo演示》
《理论联系实际：一套典型的IM通信协议设计详解（含安全层设计）》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
>> 更多同类文章 ……

[7] 有关实时音视频开发：
《即时通讯音视频开发（一）：视频编解码之理论概述》
《即时通讯音视频开发（二）：视频编解码之数字视频介绍》
《即时通讯音视频开发（三）：视频编解码之编码基础》
《即时通讯音视频开发（四）：视频编解码之预测技术介绍》
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（六）：如何开始音频编解码技术的学习》
《即时通讯音视频开发（七）：音频基础及编码原理入门》
《即时通讯音视频开发（八）：常见的实时语音通讯编码标准》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十二）：多人实时音视频聊天架构探讨》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十四）：实时音视频数据传输协议介绍》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、V8的前世今生》
《简述开源实时音视频技术WebRTC的优缺点》
《良心分享：WebRTC 零基础开发者教程（中文）》
>> 更多同类文章 ……

[8] IM开发综合文章：
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM系统中如何保证消息的可靠投递（即QoS机制）》
《谈谈移动端 IM 开发中登录请求的优化》
《完全自已开发的IM该如何设计“失败重试”机制？》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
>> 更多同类文章 ……

[9] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
《开源移动端IM技术框架MobileIMSDK：Android版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Java版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：iOS版Demo使用帮助》
《开源移动端IM技术框架MobileIMSDK：Android客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Java客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：iOS客户端开发指南》
《开源移动端IM技术框架MobileIMSDK：Server端开发指南》
>> 更多同类文章 ……

[10] 有关推送技术的文章：
《iOS的推送服务APNs详解：设计思路、技术原理及缺陷等》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《扫盲贴：认识MQTT通信协议》
《一个基于MQTT通信协议的完整Android推送Demo》
《求教android消息推送：GCM、XMPP、MQTT三种方案的优劣》
《移动端实时消息推送技术浅析》
《扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别》
《绝对干货：基于Netty实现海量接入的推送服务技术要点》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《为何微信、QQ这样的IM工具不使用GCM服务推送消息？》
>> 更多同类文章 ……

[11] 更多即时通讯技术好文分类：
http://www.52im.net/forum.php?mod=collection&op=all

引用：yuanqixun1 发表于 2016-07-13 11:41
据我自己使用经验，国外用gcm的基本占90%以上(我手机里80%的日语、英语app)

要是国内能支持GCM，ANdroid上的IM和推送就要好写多了，这蛋疼的进程保活和网络保活真是费劲

引用：徐杨清 发表于 2016-03-02 16:40
GCM对开发者而言很不好用，国外用的也没你想象的多，这是android开源导致的硬伤，除了国内没推送服务器导致 ...

据我自己使用经验，国外用gcm的基本占90%以上(我手机里80%的日语、英语app)

看看这篇文章：http://www.52im.net/thread-122-1-1.html

引用：段马x 发表于 2016-03-02 16:26
我是某公司的Android程序开发。

一般情况下讨论用不用GCM，首先需要明确GCM的适用范围，然后我就去查GCM ...

看完你的回答，秒懂。

引用：徐杨清 发表于 2016-03-02 16:42
话说回来，为什么苹果推送就可以无问题的push呢？

iOS有个东西叫APNS，不得不说苹果当初设计iOS时对体验和耗电量这些的考虑，真是周全。

话说回来，为什么苹果推送就可以无问题的push呢？

GCM对开发者而言很不好用，国外用的也没你想象的多，这是android开源导致的硬伤，除了国内没推送服务器导致被墙等网络原因，大部分的手机系统都不是google原生的，不是原生意味着被定制意，味着底层jar包被阉割，而GCM依赖的google play service相关接口必阉割导致没法使用。

为什么？很好理解，有野心定制系统的手机厂商为的是打造自己的生态圈，假设你是生产商，你会允许你的手机使用google store么？恰恰这些机型正好是市场占有率极高的机型。以三星提供的操作系统为例，用的是三星商店，推送用的是他自己的推送服务器不走GCM。

不过话说回来GCM不好用不能成为我们容忍微信使用长连接的理由，他完全可以自己搭建一个推送服务器实现推送。

先说Whats App，绿色守护休眠后（捐赠版里开启GCM推送），新消息的GCM推送基本上实时到达，在WIFI和联通3G网络下。
官网下载版本都不支持GCM，后台会有2个进程，其中一个是Push服务。

最近还流出个5.4.0.96，支持GCM，绿色守护休眠后，有几个问题：
1：电信WIFI下，GCM推送延时可接收（实测延误4-5秒），但联通3G网络下，延误时间多些。
2：网络状况改变后，消息会重复提醒。比如从没信号无网络切换到有网络。这个很烦人，不知道是不是GCM和Push进程产生的bug，不间歇的出现这种问题。
3：后台还是有2个服务进程，其中一个是Push。

企鹅码农团队那么强大，现在一门心思掉进钱坑了。什么时候要能在Google Play出个纯粹的GCM推送，及时又省电的微信啊？？

再看看人家Whats App，真是良心企业啊！！

其实问题描述的问题，我了解到的是都考虑过的，在反问楼主几个问题：
1、国内支持GCM的机型占比多少？
2、不支持的是否需要兼容模式？
3、主动关闭了GCM机器有多少？
4、全国各地网络GCM的响应时间和成功率是多少？
5、GCM服务器自身可靠程度多少？国内的布点是否OK？

所以至少来看，兼容模式需要长期存在。

GCM在国内可用性不高，原因有：
1、  Android很多被手机厂商定制化，厂商可能会去掉GCM服务。
2、  Android 2.2到3.0之间需要安装Google Store并设置Google帐号。
3、  由于国内2G和移动3G的NAT超时时间都小于GCM心跳时间(28分钟)，TCP长连接必然无法保活，每次都要等28分钟心跳失败重连后才能收到Push。
4、  某些运营商可能限制了5228端口，移动3G/2G下，发现几乎无法连接上GCM服务器，也就无法获得GCM通知，WhatsApp放后台10分钟后，经常很长时间都收不到Push消息。

先不提4.0之前必须登录google账户才能用，gcm容易撞墙，容易被rom删掉。到达率50%还是80%还是90%又如何？不是100%就没法用。即使是100%的android手机都有，偶尔墙一下也受不了，G。F。W的行为你是未知的，没必要赌这个。同时维护两套消息推送机制也很麻烦，只选一个必然要自己搞，有人提到的WHATSAPP、LINE、Gmail等等，这些app国内没多少人用，用这些东西的人应该也很少用被深度定制了的系统。纯国内大厂的app有谁用gcm？没必要针对微信吐槽腾讯如何如何。

另外，gcm的网络机制不是很适合国内的网络。之前有人写过一篇文章讲为何微信导致移动的基站负载变高之类的。大概是说移动的数据通信会把长时间不传数据的长连接关掉，避免这个的办法就是降低心跳间隔，gcm的默认心跳间隔不清楚是多少，但绝对比微信自己的长。导致gcm的连接容易被断掉从而收消息有延迟。我之前用android上的gtalk感触很大，用固定宽带的wifi聊天，收到消息很及时，换数据流量上网，经常会出现一两分钟没收到消息然后一下收到好几条的情况。

耗电量和即时性确实是个折衷的东西，你可能认为微信晚一分钟收到消息但省电1%挺好，但未必所有人都这么认为。

引用：段马x 发表于 2016-03-02 16:26
我是某公司的Android程序开发。

一般情况下讨论用不用GCM，首先需要明确GCM的适用范围，然后我就去查GCM ...

GCM确实基本不能落地，主要原因在于国内厂商阉割了Google Play Services。如果有条件，还是GCM/Other Push一起使用的好。

楼上正解，谷歌的服务在国内容易被 禁 应该是主要原因。

少年，google的东西再牛逼，在伟大的GFW面前，都得显原型，哈哈

我是某公司的Android程序开发。

一般情况下讨论用不用GCM，首先需要明确GCM的适用范围，然后我就去查GCM的详细信息，链接如下：Google Cloud Messaging for Android

看到了下面这么一段：

- Here are the requirements for running a GCM Android client:At a bare minimum, GCM requires devices running Android 2.2 or higher that also have the Google Play Store application installed, or an emulator running Android 2.2 with Google APIs. Note that you are not limited to deploying your Android applications through Google Play Store.

- However, if you want to continue to use new GCM features that are distributed through Google Play Services, the device must be running Android 2.3 or higher, or you can use an emulator running Android 2.3 with Google APIs.

- On Android devices, GCM uses an existing connection for Google services. For pre-3.0 devices, this requires users to set up their Google accounts on their mobile devices. A Google account is not a requirement on devices running Android 4.0.4 or higher.

翻译：

以下是Android客户端能运行GCM的条件：
1.  最低配置，Android系统2.2及以上并且同时安装有Google Play应用商店，或者是使用了GoogleAPIs，系统在2.2及以上的Android模拟器。请注意你不会被限制需要适用Google Play应用商店来下载App；

2.  然而，如果你想继续通过Google Play Services使用后续的GCM的新特性，设备系统必须等于或高于Android2.3（偷懒，模拟器相关支持就不翻译了）；
  
3.  在Android设备上，GCM使用Google Services上存在的一个连接。对于3.0之前的设备，需要用户在移动设备上设置好谷歌账号。在Android4.0.4及以上版本则不需要谷歌账号。

我不要新服务我对账号没要求我只要最低配置，即使只看完第一条我也就Oh shit了，2.2系统完全没问题，问题是国内的手机能有几台安装了Google Play呢（包括后期自己装的）？！这时不是很Geek又懒（买国行Android还不刷机）的我还抱着点希望，打开我买的某国外品牌Android机的国行版本，下载了一个Google Services（Google Play依赖Google Services，没Services时Google Play无法正常使用），然后这个Services就不停地循环报崩溃...崩溃...崩溃...崩溃...然后我就崩溃了（卸掉）！


－－－－－－－－－－－－－－－补充分割－－－－－－－－－－－－－－－
有人提议双推送机制，有GCM用GCM，没有的时候再用Service。
答：对于绝大多数Android程序员来说（包括我），这是很无聊的一件事，需求有不少，还有好多BUG等着解，除非特别有必要，否则才懒得搞两套机制。