作为一个横跨通信与互联网两大行业的从业者，前四年的核心网经验和后五年的互联网经验让我不得不感慨一个非常遗憾的现实：通信与互联网两大行业本来可以有珠联璧合的技术协同，为移动互联网提供近乎零耗电零流量的PUSH机制，但由于两个行业之间长期以来的价值观隔阂和互防心态，导致如今的手机PUSH技术不仅为用户增加了显著的电量消耗，还对移动运营商的基础设施造成了完全不必要的信令压力。微信与运营商的纷争正是这种冲突集中爆发的结果。

   看到不少来自两个行业的专业分析，通信行业的专家谴责微信过于频繁的心跳和短包导致“信令风暴”，而互联网人士则往往站在用户与道德的制高点上对移动运营商挖苦讥讽，双方都很少探究这个问题的深层次技术和利益矛盾。这里我不妨提一提有些大家没有真正重视的技术细节。

   为什么使用同样PUSH技术的Apple和Google等巨头，没有被运营商卯上，唯独单单拿微信下手？大家也许会认为这是运营商欺软怕硬，拿Apple和Google没办法。其实从实际数据上来看（下面将提到），微信确确实实产生了远超Apple和Google的信令需求。难道是因为腾讯技不如人，被逮着了尾巴？其实不然，我们曾经也在PUSH技术上投入了较多的分析研究，其中一项发现或许可以解释各种原委。根据分析，一般当基带空闲超过一定时间后，运营商的IP网关会自动释放（关闭）连接。目前各家所使用PUSH通道的实现原理虽然同为『长连接慢心跳』，但这个『慢』字却有很大的文章。Google在Android系统中使用蜂窝（2G/3G）网络连接GCM的PUSH通道时，默认采用的心跳周期是28分钟，这才是所谓“慢”的含义 —— 尽可能降低心跳的频度，从而达到尽量省电的目的。但这个放诸全球绝大部分地区借行得通的规则，到了中国大陆，就出现了问题。以中移动的2.5G网络为例，经过粗略测试，大约5分钟左右的基带空闲，连接就会被释放，这就是为什么微信Android版本选择以『5分钟』为周期发送连接心跳。可能有人会有疑问了，『那Google以28分钟发送心跳，岂不是在中移动的2.5G网络下无法保持PUSH长连接？』事实上，确实如此，这也是为什么Google的PUSH通道经常『迟到』。当我们活跃使用手机时，由于基带往往并不会闲置，所以部分掩盖了问题的本质。另外，当连接到Wi-Fi时，宽带的网关一般没有空闲释放机制，所以长连接会得到保持，这也进一步减少了我们平时遭遇的PUSH迟到。

   『5分钟』的心跳周期到底是什么概念？可以理解为，每部安装了微信的Android设备每天发送近300条短信（其实占用的信令资源还远超这个数量）；还意味着每天你的手机将被从待机省电状态唤醒近300次，每次相当于打一个几秒钟的电话。粗略测算，一般的Android手机每天有超过15-20%的电量被消耗在发送过度频繁的心跳上。其实，这都还远不是最糟糕的事情。由于众所周知的原因，大陆行货渠道发售的Android手机都无法使用Google的PUSH通道，原本每个手机中只需要建立的唯一共享的PUSH通道，被人为分裂，以至于每一个声称为用户提供实时通知的国内App，基本都在重复上面微信所做的行为。当你的手机中同时安装了多个这类App时，无论手机的耗电，还是运营商的信令负担，都要数倍于上述情形。

   虽然我向来不惮以最坏的恶意揣测国内的垄断巨头，但在这个事情上，中移动或许确有它的苦衷。正如很多技术文章中所言，2G网络的基础结构和协议并未针对IP传输优化，其服务IP链路的信令承载能力相对较弱，而TD-SCDMA又长期得不到真正的发展，导致中移动的2.5G网络承受了超龄超载的负荷。刻意缩短空闲连接的释放超时，可能原本是期望能起到节省信道资源的目的，没想到聪明反被聪明误，这一限制性的举措让互联网应用不得不以远高于正常的频率发送心跳以维持PUSH长连接，结果大大加重的信令负担，给本就脆弱的2.5G网络雪上加霜，而且更给用户的手机造成了远超常规PUSH技术的电量消耗，造成了如今这一『三输』的格局。

   其实，不光是微信，整个移动互联网行业都在努力解决PUSH机制目前所面对的各方面问题。包括Google、Apple这样在整个行业举足轻重的巨头，都仅仅在OSI通信协议的4层以上作各种努力，目前几乎所有的PUSH机制都基于『TCP长连接慢心跳』方式实现。虽然『慢心跳』如果得以正常工作，可以在一定程度上降低手机基带模块的工作频度，但无论互联网行业在技术上再如何标榜“PUSH”相比“PULL”的流量优势，但在OSI的下三层来看，基带模块所承受的负担和“PULL”仍然没有本质差别。这就决定了耗电问题不可能从互联网技术层面彻底解决。事实上，在移动通信网络中，信令是一种天然的最佳PUSH载体，它不需要任何IP层的收发包（也就不需要TCP连接）就能实现秒级的实时性，最重要的是它没有任何额外的电量负担，手机完全只需处于正常的待机状态。可惜移动运营商只会将其运用在一本万利的SMS（及WAP PUSH）服务，压根不可能无偿提供给互联网产业使用。结果，互联网行业选择了虽然不用付费，但却代价高昂的『TCP长连接』，只为让用户享受到免费的通知服务。这种两大行业置用户体验于不顾的分庭抗礼，已经相持近10年，而当互联网终究开始以免费服务反噬移动运营商的SMS甚至语音业务时，运营商再也坐不住了…… 但与其饱受信令风暴的折磨，不如主动免费开放信令通道作为更高效的PUSH通道给互联网产业使用，再以『免费增值』的思路构建有QoS保障的VIP PUSH服务。不仅可以大幅度节约信令资源，更能以用户体验的提升打造核心竞争优势和增值空间。能否走出这样一条转折的道路，就看运营商是否愿意转变思维了。

   注：由于iOS系统的相对封闭性，暂时未能测定Apple的Push通道APNS在2.5G网络下的长连接心跳周期。欢迎了解的朋友补充测试数据。

UPDATE：更正微信Android版在中移动2.5G网络下的心跳周期为5分钟（此前测定的2.5分钟存在偏差）

建议继续学习：

1. 消息系统该Push/Pull模式分析    (阅读：4984)
2. Push Or Pull?    (阅读：3781)
3. iOS push服务    (阅读：3554)
4. APP的推送是咋回事    (阅读：3315)
5. Array的push与unshift方法性能分析    (阅读：2593)
6. 中庸之道的newsfeed的设计    (阅读：2431)
7. Android最方便的推送框架    (阅读：2531)
8. 苹果iOS系统下的推送机制及实现    (阅读：2476)
9. 苹果信息推送服务（Apple Push Notification Service）使用总结    (阅读：1656)