移动端IM实践：实现Android版微信的智能心跳机制

本文由微信开发团队人员编写，转自 WeMobileDev，感谢。

一 引言

在2013年11月中旬时，因为基础组件组人手紧张，Leo安排我和春哥去广州轮岗支援。

刚到广州的时候，Ray让我和春哥对Line和WhatsApp的心跳机制进行分析。我和春哥抓包测试了差不多两个多礼拜，在我们基本上摸清了Line和WhatsApp的心跳机制后，Ray才告诉我们真正的任务——对微信的固定心跳进行优化，并告诉我们这不是一件容易的事情。

于是我和春哥开始构思第一个方案，我们开始想用统计的方法来解决问题，当我们拿着第一个方案和Ray讨论时，发现不能优雅应对Ray的所有提问：

• 1、测试环境的准确性，失败到底是因为网络的特性导致还是因为用户当前的环境变化导致的暂时失败。
• 2、临界值界定，如果方案选中的心跳值是临界值，我们该怎么办。
  

Ray和组件组同事在网络方面有极其丰富的经验，虽然他没有给我们指出明确的方向，但提出的问题帮助我们更快的补齐需要面对的核心问题。这两个问题让我和春哥意识到如果能很好的解决，就可以给出一个比较好的心跳方案。第一个问题我和春哥开始就意识到，第二个问题我们确实在一开始时疏忽了。但直接解决这两个问题确实不容易，这着实让我和春哥迷茫了几天，有两三天在纺园我都没怎么睡着，因为想不到更好的方法。

直到有一天思路发生了一些转变，既然最优解比较复杂，为什么不绕过去，使用有损服务理念找次优解呢。让复杂的事情简单化，好了，想到这里突然有一种拨开云雾的感觉。

二 大体思路

• a）延迟心跳测试法：这是测试结果准确的前提保障，我们认为长连接建立后连续三次成功的短心跳就可以很大程度的保证下一次心跳环境是正常的。
• b）成功一次认定，失败连续累积认定：成功是绝对的，连续失败多次才可能是失败。
• c）临界值避免：我们使用比计算出的心跳稍微小一点的值做为稳定心跳避免临界值。
• d）动态调整：即使在一次完整的智能心跳计算过程中，我们没有找到最好的值，我们还有机会来进行校正。
  

三 拍板方案

当我和春哥想出第二个简单易行的方案后，我们心里就很有底了，去找Ray讨论，Ray听完后一次通过，然后Ray约了Harvey，给Harvey讲完后，Harvey说听起来可以，可以试试。

然后就开始动手，分析竞品加确定方案花了差不多两个月。写心跳的主要代码，只花了一天时间，我记得那天是年会后的一天。回过头来再看这个方案花费的时间还是值得的，后来灰度的统计数据显示，70%用户都可以达到我们的心跳上限。

搞完智能心跳后一段时间在广州没事干，我就跟Ray商量，Ray让我去测试下WebView的性能瓶颈。然后我跟周斯基一起来做这件事，搞完了安卓客户端WebView性能瓶颈测试后，因为怀孕的老婆一个人在深圳，领导就安排我先回深圳了。春哥坚守着把GCM部分完成后才回深圳。

等我们的心跳版本正式发布后，一年前我在公司km上分享了智能心跳方案，吸引不少做push的同事加入了讨论，感觉这方面的交流还是很有必要的。

四 方案目标

设计此方案的主要目标是，在尽量不影响用户收消息及时性的前提下，根据网络类型自适应的找出保活信令TCP连接的尽可能大的心跳间隔，从而达到减少安卓微信因心跳引起的空中信道资源消耗，减少心跳Server的负载，以及减少部分因心跳引起的耗电。

主要方法是参考WhatsApp和Line中有价值的做法，结合影响TCP连接寿命的因素，实现Android微信后台自适应心跳算法。

* 有关WhatsApp、Lin的消息推送策略请参考文章《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》；
* 有关GCM的研究结论请参考文章《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信团队）》。

五 方案需考虑到影响连接寿命的思素

在Android下，不管是GCM，还是微信，都是通过TCP长连接来进行消息收发的，TCP长连接存活，消息收发就及时，所以要对影响TCP连接寿命的因素进行研究。

1、NAT超时

大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断（NAT超时的更多描述见附录9.1）。NAT超时是影响TCP连接寿命的一个重要因素(尤其是国内)，所以客户端自动测算NAT超时时间，来动态调整心跳间隔，是一个重要的优化点。

2、DHCP的租期（lease time）

目前测试发现安卓系统对DHCP的处理有Bug，DHCP租期到了不会主动续约并且会继续使用过期IP，这个问题会造成TCP长连接偶然的断连。（租期问题的具体描述见附录9.2）。

3、网络状态变化

手机网络和WIFI网络切换、网络断开和连上等情况有网络状态的变化，也会使长连接变为无效连接，需要监听响应的网络状态变化事件，重新建立Push长连接。

六 心跳范围选择

1、前后台区分处理：
为了保证微信收消息及时性的体验，当微信处于前台活跃状态时，使用固定心跳。微信进入后台（或者前台关屏）时，先用几次最小心跳维持长链接。然后进入后台自适应心跳计算。这样做的目的是尽量选择用户不活跃的时间段，来减少心跳计算可能产生的消息不及时收取影响。

2、后台自适应心跳选择区间：
可根据自身产品的特点选择合适的心跳范围。

以下是状态转换示意图：

七 自适应心跳算法量化描述

因为每个网络的NAT时间可能不一致。所以需要区分计算，数据网络按subType做关键字，WIFI按WIFI名做关键字。对稳定的网络，因为NAT老化时间的存在，在自适应计算态的时候，暂设计以下步骤在当前心跳区间逼近出最大可用的心跳。

a）变量说明：

• [MinHeart，MaxHeart]——心跳可选区间。
• successHeart——当前成功心跳，初始为MinHeart
• curHeart——当前心跳初始值为successHeart
• heartStep——心跳增加步长
• successStep——稳定期后的探测步长
  

b）最大值探测步骤（自适应心跳计算流程）：



自适应心跳计算流程如上图所示，经过该流程，会找到必然使心跳失败的curHeart（或者MaxHeart），为了保险起见，我们选择比前一个成功值稍微小一点的值作为后台稳定期的心跳间隔。

影响手机网络测试的因素太多，为了尽量保证测试结果的可靠性，我们使用延迟心跳测试法。在我们重新建立TCP连接后，先使用  短心跳连续成功三次，我们才认为网络相对稳定，可以使用curHeart进行一次心跳测试。图4-2显示了一次有效心跳测试过程。图4-3显示了在没有达到稳定网络环境时，我们会一直使用固定短心跳直到满足三次连续短心跳成功。

使用延迟心跳测试的好处是，可以剔除偶然失败，和网络变化较大的情况（如地铁），使测试结果相对可靠（五次延迟测试确定结论）。同时在网络波动较大的情况，使用短心跳，保证收取消息相对及时。

c）运行时的动态调整策略(已经按测算心跳稳定值后)

NAT超时值算出来后，在维持心跳的过程中的策略。

-  无网络、网络时好时坏、偶然失败、NAT超时变小：
   在后台稳定期发生心跳发生失败后，我们使用延迟心跳测试法测试五次。如果有一次成功，则保持当前心跳值不变；如果五次测试全失败，重新计算合理心跳值。该过程如图4-4所示，有一点需要注意，每个新建的长连接需要先用短心跳成功维持3次后才用successHeart进行心跳。后台稳定态动态调整心跳策略如下图：


-  NAT超时变大：
   以周为周期，每周三将后台稳定态调至自适应计算态，使用心跳延迟法往后探测心跳间隔。

-  successHeart是NAT超时临界值：
   因为我们现在选择的是一个比successHeart稍小的值作为稳定值，所以在计算过程中可以避开临界值。当运营商在我们后台稳定期将NAT超时调整为我们当前计算值，那么由于我们每周会去向下探索，所以下一周探测时也可以及时调整正确。

d）冗余Sync和心跳

在用户的一些主动操作以及联网状态改变时，增加冗余Sync和心跳，确保及时收到消息。

• 1、当用户点亮屏幕的时候，做一次心跳。
• 2、当微信切换到前台时，做一次Sync。
• 3、联网时重建信令TCP，做一次Sync。
  

八 可能存在的风险及预防措施

DHCP租期因素：

• 1、问题：根据目前的测试结果显示，安卓不续约到期的IP Bug，会导致TCP连接在不确定的时间点失效，从而会导致一次心跳失败。
• 2、预防：统计后台稳定期的心跳成功率，上报给后台。后台可以按地区分网络监控这个指标的波动，并且后台可以根据不同的波动，动态调整某区域特定网络下可选的心跳区间。
  

9 附录

1附录A：NAT超时介绍

因为 IP v4 的 IP 量有限，运营商分配给手机终端的 IP 是运营商内网的 IP，手机要连接 Internet，就需要通过运营商的网关做一个网络地址转换(Network Address Translation，NAT)。简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系，以确保内网的手机可以跟 Internet 的服务器通讯。



大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰 NAT 表中的对应项，造成链路中断。

下表列出一些已测试过的网络的NAT超时时间(更多数据由于测试条件所限没有测到)：

地区/网络	NAT超时时间
中国移动3G和2G	5分钟
中国联通2G	5分钟
中国电信3G	大于28分钟
美国3G	大于28分钟
台湾3G	大于28分钟

长连接心跳间隔必须要小于NAT超时时间(aging-time)，如果超过aging-time不做心跳，TCP长连接链路就会中断，Server就无法发送Push给手机，只能等到客户端下次心跳失败后，重建连接才能取到消息。

2附录B：安卓DHCP的租期（lease time）问题

目前测试发现安卓系统对DHCP的处理有Bug：

• 1、DHCP租期到了不会主动续约并且会继续使用过期IP：
       详细描述见 http://www.net.princeton.edu/android/android-stops-renewing-lease-keeps-using-IP-address-11236.html。这个问题导致的问题表象是，在超过租期的某个时间点（没有规律）会导致IP过期，老的TCP连接不能正常收发数据。并且系统没有网络变化事件，只有等应用判断主动建立新的TCP连接才引起安卓设备重新向DHCP Server申请IP租用。
• 2、未到租期的一半时间，安卓设备重新向DHCP Server申请IP租用。从目前测试结果来看，这种现象恢复的比较快。
• 3、移动2G/3G，联通2G没有抓到DHCP。
• 4、美国3G下抓取24小时，没有抓到DHCP。
  

附录1：IM/推送的进程/网络保活文章汇总

《应用保活终极总结(一)：Android6.0以下的双进程守护保活实践》
《应用保活终极总结(二)：Android6.0及以上的保活实践(进程防杀篇)》
《应用保活终极总结(三)：Android6.0及以上的保活实践(被杀复活篇)》
《Android进程保活详解：一篇文章解决你的所有疑问》
《Android端消息推送总结：实现原理、心跳保活、遇到的问题等》
《深入的聊聊Android消息推送这件小事》
《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》
《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《Android P正式版即将到来：后台应用保活、消息推送的真正噩梦》
《全面盘点当前Android后台保活方案的真实运行效果（截止2019年前）》
《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》
《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
《跟着源码学IM(一)：手把手教你用Netty实现心跳机制、断线重连机制》
《跟着源码学IM(五)：正确理解IM长连接、心跳及重连机制，并动手实现》
《2020年了，Android后台保活还有戏吗？看我如何优雅的实现！》
《史上最强Android保活思路：深入剖析腾讯TIM的进程永生技术》
《Android进程永生技术终极揭密：进程被杀底层原理、APP应对被杀技巧》
《Android保活从入门到放弃：乖乖引导用户加白名单吧(附7大机型加白示例)》
《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》
>> 更多同类文章 ……

附录2：有关QQ、微信的文章汇总

[1] 有关QQ、微信的技术文章：
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《让互联网更快：新一代QUIC协议在腾讯的技术实践分享》
《iOS后台唤醒实战：微信收款到账语音提醒技术总结》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享：手机QQ中的人脸识别酷炫动画效果实现详解》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《IM全文检索技术专题(一)：微信移动端的全文检索优化之路》
《企业微信客户端中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《以手机QQ为例探讨移动端IM中的“轻应用”》
《一篇文章get微信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各种“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯信鸽技术分享：百亿级实时消息推送的实战经验》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践》
《微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》
《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》
《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践》
>> 更多同类文章 ……

[2] 有关QQ、微信的技术故事：
《技术往事：微信估值已超5千亿，雷军曾有机会收编张小龙及其Foxmail》
《QQ和微信凶猛成长的背后：腾讯网络基础架构的这些年》
《闲话即时通讯：腾讯的成长史本质就是一部QQ成长史》
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《技术往事：“QQ群”和“微信红包”是怎么来的？》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
《首次揭秘：QQ实时视频聊天背后的神秘组织》
《为什么说即时通讯社交APP创业就是一个坑？》
《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》
《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》
《QQ的成功，远没有你想象的那么顺利和轻松》
《QQ现状深度剖析：你还认为QQ已经被微信打败了吗？》
《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》
《QQ和微信止步不前，意味着即时通讯社交应用创业的第2春已来？ 》
《那些年微信开发过的鸡肋功能，及其带给我们的思考》
《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》
《同为IM社交产品中的王者，QQ与微信到底有什么区别》
《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
《社交应用教父级人物的张小龙和马化腾的同与不同》
《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》
《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》
>> 更多同类文章 ……

微信团队的这帮开发人员，确实挺钻的，文章里的一些数据，理论上应该也都是黑盒分析出来的，虽不足够准确，但做为参考还是有一定的价值。
即时通讯开发时这样的资料确实非常少，赞一个！

这文章虽然写的稍显混乱，但确实挺有钻研精神的，
在移动端即时通讯开发资料这么匮乏的情况下，这样的资料已经非常珍贵了。

这里面的一些数据，在实现类似IM时，确实有一定的参考价值。

好文，先收藏了

写的挺细，感谢分享

很少看到这么有钻研精神的了,值得学习. 现在遇到问题都是百度,谷歌的

引用：Alexwong 发表于 2017-06-04 23:38
很少看到这么有钻研精神的了,值得学习. 现在遇到问题都是百度,谷歌的

微信团队的人很有工匠精神

cool!!

膜拜吧

没学会啊。

学习一下！

为啥国内外NAT超时时间差那么多

引用：微信进入后台（或者前台关屏）时，先用几次最小心跳维持长链接。然后进入后台自适应心跳计算

不知道微信此智能心跳机制在Android 6.0的低电耗模式与应用待机模式推出后是否有所调整，因为在设备「前台关屏」且非充电状态下进入此模式后，
Android系统是会阻止应用的网络访问和延迟JobScheduler、AlarmManager的，这种情况下以最小心跳维持长链接的做法估计会失效。

当然很多厂商会赋予微信许多特权，比如华为手机上应用的自启动管理，默认的自动管理下，微信是被开放了「自启动权限」、「关联启动权限」及「后台启动权限」的，
而其他应用默认这三项都是禁止的，当把微信的这三项权限都关掉后，也是会有消息收取可能不及时的提示的。

不过可以肯定的是，其他应用肯定是无法把微信的智能心跳机制直接套用的，还是需要另外针对后面Android系统的几个变化进行适配，不过文章也提供了许多不错的思路，值得借鉴。

引用：椎锋陷陈 发表于 2021-09-08 09:52
不知道微信此智能心跳机制在Android 6.0的低电耗模式与应用待机模式推出后是否有所调整，因为在设备「 ...

微信是app中的高富帅，厂商都会跪舔，不能按常理去理解的。。。