一文读懂Android进程及TCP动态心跳保活

一直以来,APP进程保活都是 各软件提供商 和 个人开发者 头疼的问题。毕竟一切的商业模式都建立在用户对APP的使用上,因此保证APP进程的唤醒提升用户的使用时间,便是软件提供商和个人开发者的永恒追求。

面对国内GCM(Google Cloud Messaging)推送服务不可用,也未出现一个统一市场PUSH平台的现状。早期的第三方软件一般通过维持一个终端远端服务器之间的TCP长连接,达到PUSH拉活消息及时送达的目的。
而为了维持这个TCP长连接不断开,前提条件就是保证自己APP的后台服务进程,不会被杀死(因为只有活着的终端进程才能定期与远端服务器通信,保证长连接不断连)。
因此在Android发布的早期,各种技术论坛和GitHub出现了五花八门、各显神通App进程保活方案;如今随着Android系统的逐渐完善,各种进程保活方案不断受到限制,想要做到Android进程保活已经不太容易。

一般来说,Android进程保活主要有以下两方面工作:

  • 进程保活:保持进程不被系统杀死进程被杀后可以重新拉起
    早期Android,对于后台运行的Service服务进程限制较小,第三方软件保证自己APP后台服务进程长时间运行相对容易,但仍然是有被系统杀死的可能。
    这个阶段随着APP的不断增多,许多第三方APP开始利用系统漏洞(早期的Android系统尚不完善,可利用的漏洞较多),在APP进入后台系统准备休眠时,通过各种所谓的黑科技(实际为流氓手段)保证自己的APP进程不被杀死,甚至阻止系统休眠
    伴随随着这类软件的不断增多,最终造成的结果是,用户侧手机卡顿待机时间短耗电量增加

  • TCP保活:保证终端远端服务器之间的TCP长连接不断连。
    App进程保活的基础上,一般通过使用Android系统RCT时钟 Alarm每5~10分钟唤醒一次系统,并发送一条只有几个字节的TCP保活消息,来维持终端远端服务器之间的TCP长连接不断开。

一、Android早期进程保活

这里简单回顾一下,Android早期App进程保活的各种方案。

  • 通过Service的onStartCommand方法中返回 START_STICKY
    当Service的onStartCommand方法返回 START_STICKY 时,若当前Service因内存不足被系统清理掉,待内存再次空闲时,系统将会尝试重新创建此Service,一旦创建成功后将回调onStartCommand方法,但其中的Intent将是NULL。

  • 1像素透明Activity进程保活:
    监测到Android系统息屏时,启动一个1像素的前台透明Activity,欺骗系统,使其认为该应用为一个前台应用而不会被清理(据说淘宝早期就使用过这种方案)。

  • 开启前台服务:
    利用系统漏洞,创建一个 不包含系统通知栏 或 透明系统通知栏 的前台服务,提升App进程的系统优先级,使其不被系统清理。

  • Fork Native守护进程:
    Android 5.0 以前,App内部 fork 出来的 native进程 不受系统管控。系统在杀死 App进程时,只会杀死对应的Java进程
    因此诞生了一大批流氓软件,通过fork native进程,在 App 的 Java 进程被杀死的时候,通过 ActivityManager 重新拉起被杀死的进程,从而达到“进程永生”的目的(这个方案据说最初由360提出,后来大家纷纷效仿)。

  • 通过其他活跃App拉起:
    进程保活的后期,又出现一种进程保活的方案。
    多个App组成一个联盟,只要有一个App被用户使用,其他所有联盟内的App进程都会被拉起,以此来保证消息的及时到达。
    例如:集成个推、极光推送的App,可以通过前台活跃的App拉起不活跃的App进程,提升所有集成个推、极光推送的第三方App推送消息的到达率。

注:
当前随着Android系统的不断完善,以上方案大多不再有效。

二、Android各版本后台进程限制

Android系统源码的开放,加之早期的系统尚不完善,众多应用软件提供商通过对AOSP各版本源码的深入解读,提出了各种所谓黑科技的保活方案,保证自己的应用程序进程不被系统清理。这段时期可谓是魑魅横行、群魔乱舞;Android手机用户则是苦不堪言,Android手机卡顿、待机时间短等问题也为人所诟病。

随着Android系统的不断完善,Google和国内终端手机厂商也对Android系统做了很多的改进,如今已经基本封死了第三方应用各种所谓黑科技流氓保活方案。

  • Android后台进程限制;

  • 国内手机厂商后台进程限制;

2.1 Android后台进程限制

如今Google每年发布的AOSP(Android Open Source Project)新版本中,每个版本均不断增加后台服务进程限制的相关条款,一方面是为了限制第三方App后台服务进程的运行,节省用户手机资源与电量消耗;另一方面,增加后台服务进程限制也是在保护用户的隐私。

Android 5.0 开始,Android系统开始以uid为标识,查杀APP进程组,通过杀死整个进程组来杀死App进程,因此通过fork native 进程守护App进程这种方式从此不再有效。
Process.killProcessGroup(info.uid, pid)

Android 6.0开始,引入了Doze模式用户拔下设备的电源插头,并在屏幕关闭后的一段时间后,设备会进入Doze模式
Android 6.0 Doze模式

  • 在Doze模式下,系统会尝试通过限制应用访问网络和 占用CPU资源的措施来节省电量,阻止应用访问网络,并延迟作业与Alarm闹钟。

  • 系统会定期退出Doze模式一小段时间,让应用完成其延迟的活动。在此维护期内,系统会运行所有待处理的同步操作、Alarm闹钟,并允许应用访问网络。

  • 随着时间的推移,系统进入维护期的次数越来越少,这有助于在设备未连接至充电器的情况下长期处于Doze模式状态降低耗电量。

Android 7.0开始加强了Doze模式,进入Doze模式不再要求设备静止状态。
只要屏幕关闭了一段时间,且设备未插入电源,设备就会进入Doze模。
Android 7.0 Doze模式

Android 8.0开始,加强了应用后台执行限制:

  • 不能再通过startService创建后台服务,否则将抛出异常;但可通过 Context.startForegroundService() 方法启动一个带通知栏提醒的前台服务;

  • 应用处于后台时,会对后台应用检索用户当前位置信息的频率进行限制。应用每小时仅接收几次位置信息更新。

  • 广播限制:第三方应用将无法通过在AndroidManifest注册静态广播来接收大部分的系统隐式广播,以减少App对手机的唤醒,从而节省手机的电量;动态注册不受影响。

Android 9.0开始,进一步加强了应用后台执行限制:

  • 后台应用不再可以访问麦克风和摄像头,传感器(加速度传感器、陀螺仪);

  • 创建前台服务需要申请普通权限:FOREGROUND_SERVICE

Android 10开始,再进一步加强了应用后台执行限制:

  • 应用在后台运行时,访问手机位置需要动态申请ACCESS_BACKGROUND_LOCATION权限,用户则可以选择拒绝;

  • 应用在后台运行时,对后台应用启动Activity进行限制(运行前台服务的应用仍然会被应用看做“后台”应用)。

Android 11开始,再进一步完善了应用后台访问位置限制:

  • 在Android11设备上,对于targetSdkVersion=30(Android 11)的应用,需先申请前台位置权限,后申请后台位置权限。

  • 在Android11设备上,对于targetSdkVersion=30(Android 11)的应用,同时申请前台、后台位置权限时,系统会忽略该请求,无任何响应(需首先获取前台位置权限,再次申请后台位置权限)。

  • 在Android11设备上,对于targetSdkVersion<=29(Android 10)的应用,同时申请前台、后台位置权限时,对话框不再提示始终允许字样,而是提供了位置权限的设置入口,需要用户在设置页面选择始终允许才能获得后台位置权限。

2.2 手机厂商后台进程限制

Google新发布的各版本主要还是限制第三方App后台进程服务的运行,而国内各终端厂商则在AOSP的基础上增加了Alarm的限制。
国内手机厂商(华米OV等)在手机系统休眠后,第三方App注册的Alarm定时唤醒闹钟几乎全部无效!!!

“Google的后台进程限制” 与 “国内手机厂商Alarm限制”相叠加的双重影响是:
彻底封死了 “第三方手机软件” 利用 “Alarm闹钟” 定时唤醒手机系统,维持 “终端” 与 “远端服务器” 之间的TCP长连接。达到 远端服务器 可随时拉起 终端App,提升APP用户端使用时长(提升APP的DAU)这一方案。

  • 国内手机厂商 Alarm 限制;

  • 国内手机厂商 后台进程 限制;

2.2.1 手机厂商 Alarm 限制

国内终端手机厂商,不同厂商对应的Alarm限制方案也不相同,但目前已知的大概有以下两个方向:

  • Alarm 对齐机制:
    当手机系统黑屏休眠时,部分国内的手机品牌,会忽略 “第三方APP” 设置的 “Alarm唤醒周期”,强制将所有注册Alarm闹钟的APP,做Alarm唤醒周期对齐
    例如:假设有三款App,其设定的Alarm唤醒周期分别为1分钟、3分钟、5分钟。手机会直接忽略以上三款App的Alarm唤醒周期设定,强制将Alarm唤醒对齐为每5分钟唤醒一次。
    系统休眠时,将所有App的唤醒时间做对齐,来减少手机的唤醒次数,节省用户的待机电量消耗

  • Alarm 无效:
    当手机系统黑屏休眠时,部分国内的手机品牌,忽略 “第三方APP” 注册的全部Alarm,导致第三方应用注册的Alarm无效。

2.2.2 手机厂商 后台进程 限制

除了以上Alarm限制外,对于后台运行进程,不同终端厂商也进行了不同的限制。例如,部分终端厂商增加了后台进程耗电监测机制。

  • 后台进程耗电监测机制:
    当手机系统黑屏休眠时,部分国内的手机品牌,会启动一个耗电监测进程,若发现某个后台进程持续耗电,将直接杀死耗电进程。

三、手机厂商进程白名单

前边说道第三方App进程若在后台运行,会受到国内厂商Alarm限制、后台耗电监测等限制。但也有例外情况,比如:微信

这里可以将其归结为以下两个白名单:

  • Alarm 对齐白名单
    微信 这个体量的App 会被直接添加到,国内手机厂商的Alarm 对齐白名单中。白名单中的进程,系统休眠时的Alarm唤醒将不再受到限制。

  • 系统守护进程白名单
    若能达到微信的体量,国内手机厂商甚至可能会将其添加到 系统守护进程白名单。该白名单中的进程,若某些原因后台进程被杀,系统守护进程会在一定时间内迅速拉起该进程,从而保证进程的活跃。

四、Push推送 建议方案

前边回顾了这几年在进程保活这个问题上各软件提供商Android系统研发制造商之间互相博弈过程。

如今在“Google的后台进程限制” 与 “国内手机厂商Alarm限制”双重限制下,第三方软件希望做到App进程常驻后台已经不太可能。

但每一个第三方App,基本都存在消息Push的需求。对于消息PUSH需求,第三方APP可使用的方案是什么?

  • 接入终端手机厂商 Push通道;

  • 进程添加到厂商进程保活白名单;

4.1 接入厂商 Push通道

在当前环境下的建议实现方案:接入终端手机厂商Push通道。

接入各终端厂商的Push通道,是最简单的实现方案。
厂商的Push通道常驻内存,所有第三方App接入厂商Push后 即能保证消息及时准确的到达,又可以减少终端用户手机的常驻进程,延长用户手机的待机时长,可以说是对双方都有利。

  • 接入厂商PUSH 终端侧实现方案;

  • 接入厂商Push的 到达率上的注意点。

4.1.1 接入厂商PUSH 终端方案

接入厂商PUSH 终端方案,终端侧可通过创建与维护一个单独的推送 Module 模块,其中集成 华为、小米、VIVO、OPPO、中兴 5家厂商的Push SDK;其他终端厂商的Push到达,可通过接入 个推 或 极光推送来实现。

  • 华米OV 等头部手机厂商:
    通过接入华米OV等头部厂商PUSH通道,保证市场上大多数手机用户的PUSH到达率;

  • 其他非头部手机厂商:
    通过极光个推等第三方市场占有率较高的PUSH实现方案,来覆盖除 华米OV 等头部手机厂商外的其他终端手机,保证市场上少部分手机用户的PUSH到达率;

采用这个方案,研发人员需要开发和维护6个Push SDK组成的Module模块。因此,接入厂商PUSH,优点和缺点可归结如下。

  • 优点可以很好的保证 PUSH到达率;

  • 缺点开发与维护成本增加。
    国内头部手机终端厂商较多,研发的同学在一个App中需要同时维护 华为、小米、VIVO、OPPO、中兴、魅族 等一系列厂商的PUSH SDK,研发维护成本急剧增加。

4.1.2 接入厂商Push的注意点

  • 接入厂商Push的注意点;

  • 将来终端手机厂商 PUSH渠道 可能收费。

接入厂商Push的注意点
接入厂商PUSH,在PUSH到达上仍有不同的限制条件,这一点也需要相关研发人员仔细研究各终端厂商PUSH的接入文档
例如OPPO,存在一个PUSH配额问题:
OPPO PUSH配额是 OPPO推送消息的数量限制规则。每天的Push量 超过这个PUSH配额,OPPO将不再下发Push。
OPPO PUSH配额官方描述:
https://open.oppomobile.com/wiki/doc#id=10200
OPPO PUSH配额官方描述如下:
OPPO PUSH配额

将来终端手机厂商 PUSH渠道 可能收费。
目前终端手机厂商的PUSH渠道均是免费为开发者使用的,但随着全市场的PUSH通道均为各终端厂商把控后,第三方APP的消息PUSH也许存在收费的可能。个人认为厂商PUSH渠道 收费 在不久的将来可能性还是很大的。

4.2 添加到厂商进程保活白名单

终端手机厂商追求的还是利益,因此只要给钱或有钱赚,没什么不可谈的

与国内各终端厂商谈合作 添加到对应的进程白名单中。

这个方案,需要与各终端厂商合作 达成利益上的同盟或找到利益契合点,从而使终端厂商为您的App开放进程保活白名单。

若 您的公司与各终端厂商达成了利益同盟,恭喜您可以考虑采用维持一个终端与远端服务器的TCP长连接,实现消息及时到达终端,提升用户端App使用时长的PUSH方案了。

五、TCP 动态心跳方案

前边提到,若APP用户体量足够大 或 与各终端厂商达成了利益同盟,可以考虑维持一个终端与远端服务器的TCP长连接,实现消息及时到达终端,提升用户端App使用时长。

  • TCP心跳 相关标准;

  • 维持 TCP心跳 不断连;

  • TCP动态心跳 方案。

5.1 TCP心跳 相关标准

在Android下,通过自建 TCP长连接 来进行Push消息推送,TCP长连接若存活,消息Push才能及时送达。
而说到TCP心跳,那什么是TCP心跳,TCP消息的结构又是什么?
rfc5626 4.4.1 Keep-Alive with CRLF标准中,关于SIP消息的TCP心跳给出了标准。

  • Keep-Alive with CRLF;

  • CRLF 详细说明;

  • ping pong 心跳消息。

5.1.1 Keep-Alive with CRLF

rfc5626 4.4.1 Keep-Alive with CRLF中,SIP消息TCP心跳标准可以如下描述:

  • 终端侧需每隔一段时间(心跳间隔时间)需发送一个“ping”(double CRLF)消息,到远端服务器侧;

  • 终端发送“ping”消息后,若在10s之内未收到远端服务端的“pong”(CRLF)消息,则终端认为与服务端的连接失败。

rfc5626 TCP ping pong保活

5.1.2 CRLF 详细说明

根据rfc5626 4.4.1 Keep-Alive with CRLF标准:

  • 终端上行的ping消息为 CRLFCRLF;

  • 远端服务器下行的pong消息为 CRLF;

pong消息为CRLF ,含义是 回车+换行 符;
ping消息为double CRLF,也就是CRLFCRLF 含义是 回车换行回车换行 符。

CRLF 在ASCII表中与 16进制数据 的对应关系,如下图所示:

CRLF为回车换行符

ASCII的对应表中查看:

  • ping心跳消息CRLFCRLF,对应的16进制数据为0d0a0d0a

  • pong心跳消息CRLF,对应的16进制数据为0d0a

心跳含义缩写十六进制
ping终端上行心跳数据CRLFCRLF0d0a0d0a
pong远端服务器下行心跳数据CRLF0d0a

5.1.3 ping pong 心跳消息

这一节关于 ping pong心跳消息,从其消息发送接收流程、WireShark现网数据抓包、消息结构举例 三方面进行介绍。

  • ping pong 心跳流程;

  • ping pong 心跳WireShark抓包;

  • ping pong 心跳消息举例。

ping pong 心跳流程:

ping pong 心跳消息的发送/接收流程,如下图所示:
ping pong心跳发送接收流程

  • 终端侧需每隔一段时间(心跳间隔时间)需发送一个“ping”(double CRLF 0xd0xa0xd0xa)消息,到远端服务器侧;

  • 终端发送“ping”消息后,若在10s之内未收到远端服务端的“pong”(CRLF 0xd0xa)消息,则终端认为与服务端的连接失败。

ping pong 心跳WireShark抓包:

ping pong 心跳WireShark抓包如下图所示:

ping pong

ping pong 心跳消息举例:

ping pong 心跳消息的举例如下所示:

// 终端侧发送: TCP Ping:0d 0a 0d 0aFrame 2427: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)Linux cooked capture v1Internet Protocol Version 4, Src: 10.xxx.xxx.xxx, Dst: 183.xxx.xxx.xxxTransmission Control Protocol, Src Port: 46649, Dst Port: 5460, Seq: 21, Ack: 11, Len: 4
    Source Port: 46649
    Destination Port: 5460
    [Stream index: 3]
    [TCP Segment Len: 4]    Sequence Number: 21    (relative sequence number)
    Sequence Number (raw): 149531750
    [Next Sequence Number: 25    (relative sequence number)]    Acknowledgment Number: 11    (relative ack number)
    Acknowledgment number (raw): 3481893389
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
    Window: 65535
    [Calculated window size: 65535]
    [Window size scaling factor: -1 (unknown)]    Checksum: 0x727d [unverified]
    [Checksum Status: Unverified]    Urgent Pointer: 0
    [SEQ/ACK analysis]
    [Timestamps]    TCP payload (4 bytes)Data (4 bytes)
    Data: 0d0a0d0a
    [Length: 4]// 终端侧接收:TCP ACKFrame 2432: 56 bytes on wire (448 bits), 56 bytes captured (448 bits)Linux cooked capture v1Internet Protocol Version 4, Src: 183.xxx.xxx.xxx, Dst: 10.xxx.xxx.xxxTransmission Control Protocol, Src Port: 5460, Dst Port: 46649, Seq: 11, Ack: 25, Len: 0
    Source Port: 5460
    Destination Port: 46649
    [Stream index: 3]
    [TCP Segment Len: 0]    Sequence Number: 11    (relative sequence number)
    Sequence Number (raw): 3481893389
    [Next Sequence Number: 11    (relative sequence number)]    Acknowledgment Number: 25    (relative ack number)
    Acknowledgment number (raw): 149531754
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x010 (ACK)
    Window: 21476
    [Calculated window size: 21476]
    [Window size scaling factor: -1 (unknown)]    Checksum: 0x7279 [unverified]
    [Checksum Status: Unverified]    Urgent Pointer: 0
    [SEQ/ACK analysis]
    [Timestamps]// 终端侧接收:TCP Pong:0d 0aFrame 2433: 58 bytes on wire (464 bits), 58 bytes captured (464 bits)Linux cooked capture v1Internet Protocol Version 4, Src: 183.xxx.xxx.xxx, Dst: 10.xxx.xxx.xxxTransmission Control Protocol, Src Port: 5460, Dst Port: 46649, Seq: 11, Ack: 25, Len: 2
    Source Port: 5460
    Destination Port: 46649
    [Stream index: 3]
    [TCP Segment Len: 2]    Sequence Number: 11    (relative sequence number)
    Sequence Number (raw): 3481893389
    [Next Sequence Number: 13    (relative sequence number)]    Acknowledgment Number: 25    (relative ack number)
    Acknowledgment number (raw): 149531754
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x018 (PSH, ACK)
    Window: 21476
    [Calculated window size: 21476]
    [Window size scaling factor: -1 (unknown)]    Checksum: 0x727b [unverified]
    [Checksum Status: Unverified]    Urgent Pointer: 0
    [SEQ/ACK analysis]
    [Timestamps]    TCP payload (2 bytes)Data (2 bytes)
    Data: 0d0a
    [Length: 2]// 终端侧发送:TCP ACKFrame 2434: 56 bytes on wire (448 bits), 56 bytes captured (448 bits)Linux cooked capture v1Internet Protocol Version 4, Src: 10.xxx.xxx.xxx, Dst: 183.xxx.xxx.xxxTransmission Control Protocol, Src Port: 46649, Dst Port: 5460, Seq: 25, Ack: 13, Len: 0
    Source Port: 46649
    Destination Port: 5460
    [Stream index: 3]
    [TCP Segment Len: 0]    Sequence Number: 25    (relative sequence number)
    Sequence Number (raw): 149531754
    [Next Sequence Number: 25    (relative sequence number)]    Acknowledgment Number: 13    (relative ack number)
    Acknowledgment number (raw): 3481893391
    0101 .... = Header Length: 20 bytes (5)
    Flags: 0x010 (ACK)
    Window: 65535
    [Calculated window size: 65535]
    [Window size scaling factor: -1 (unknown)]    Checksum: 0x7279 [unverified]
    [Checksum Status: Unverified]    Urgent Pointer: 0
    [SEQ/ACK analysis]
    [Timestamps]

5.2 维持 TCP心跳 不断连

TCP长连接的存活且有效,终端才能维持与远端服务器的TCP心跳,保证消息及时准确的到达。
因此影响TCP长连接稳定状态的因素,值得研发人员重点关注:

  • 运营商 NAT超时;

  • 终端 网络状态变化。

5.2.1 运营商 NAT超时

NAT(Network Address Translation) 是运营商的一个地址转换网关。生活中最常见的NAT设备,是我们家中使用的路由器

国内运行商网络下,因为 IP v4 的 IP 数量有限,运营商分配给手机终端的 IP 是运营商内网的 IP,手机要连接 Internet,需要通过运营商的网关做一个网络地址转换(Network Address Translation,NAT)。

NAT 功能由图中的 GGSN 模块实现

简单的说运营商的网关需要维护一个外网 IP、端口到内网 IP、端口的对应关系,以确保内网的手机可以跟 Internet 的服务器通讯。

内网地址外网地址
192.168.0.3:8888120.132.92.21:9202
192.168.0.2:5566120.132.92.21:9200

如上表所示:

  • NAT设备会根据NAT表对 发送 和 接收 的数据做修改, 比如将192.168.0.3:8888发出去的数据封包改成120.132.92.21:9202,外部就认为他们是在和120.132.92.21:9202通信。

  • NAT设备会将120.132.92.21:9202收到的封包数据 IP和端口改成192.168.0.3:8888 再发给内网的主机,这样内部和外部就能互相通信了。

  • 但如果192.168.0.3:8888 == 120.132.92.21:9202这一映射因为某些原因被NAT设备淘汰了,那么外部设备就无法与192.168.0.3:8888通信了。

为了节省资源,大部分国内移动网络运营商 在链路一段时间没有数据通讯时,会淘汰 NAT 表中的对应项,造成通信双方链路的中断。
因此,为了应对运营商NAT超时,终端每隔一段时间向 远端服务器 发送一个 TCP保活消息,也就是TCP保活心跳

以上也就是为什么终端与远端服务器,需要维持TCP心跳的原因。

5.2.2 终端 网络状态变化

终端网络状态变化,也会使TCP长连接断连,比如:终端移动网络与WIFI网络切换、网络断开与重新连 等
因此,终端 APP 需监听相应网络状态变化事件:若发现终端网络状态发生变化,需重新建立TCP长连接

5.3 TCP 动态心跳方案

  • 跟随手机状态变化 调整心跳状态;

  • TCP 动态心跳周期的计算;

  • 冗余心跳。

5.3.1 动态调整 心跳状态

这里我们可以将手机不同状态划进行划分,比如:
应用处于前台时为活跃态,刚刚进入后台或息屏时为次活跃态,应用进入后台一段时间后为后台状态,手机断网或关机后为IDEL状态。
可根据用户手机不同状态变化,动态调整应用的TCP心跳周期。

  • 若应用处于前台活跃态:固定心跳。
    当应用处于前台活跃状态时,为了保证消息及时准确的达到,使用固定心跳,保证用户体验。

  • 应用刚进入后台(或息屏)的次活跃态:使用几次固定心跳。
    应用进入后台(或息屏)时,先用几次固定跳维持长链接,保证用户刚刚息屏或应用刚刚进入后台,消息的及时与准确到达,然后进入后台自适应心跳计算。

  • 应用进入后台(或息屏)一段时间后:使用动态心跳。
    应用进入后台(或息屏)一段时间后,采用动态心跳,减少因心跳引起的空中信道资源消耗,以及因心跳引起的终端唤醒与电量消耗。

  • 用户切换网络或重新联网:重新建立TCP长连接。
    用户断网后,直接进入IDEL状态,此时需检测用户网络状态变化,若用户联网后,则重建TCP长连接;
    用户切换网络状态(WIFI、移动网络互相切换),也需要重新建立TCP连接;

  • 应用重新进入前台活跃态:固定心跳。
    应用重新进入前台活跃状态,重新采用固定心跳,保证用户消息及时准确到达。

根据用户手机不同状态变化 调整应用的TCP心跳周期

注:应用进入后台(或者息屏)时,先用几次最小心跳维持长链接,然后采用动态心跳。这样做的目的是 尽量选择用户不活跃的时间段,来减少因动态心跳可能产生的 消息送达不及时,从而对用户体验产生影响。

5.3.2 动态计算 心跳周期

动态计算心跳前,假设预定义定义几个数据常量:

  • MinHeart 最小心跳间隔时间;

  • MaxHeart 最大心跳间隔时间;

  • HeartStep 心跳增加时间步长;

预定义几个数据变量:

  • successHeart 动态探测 稳定后的心跳间隔时间;

  • curHeart 当前成功心跳 初始为MinHeart;

注:
MinHeart、MaxHeart、HeartStep为预先定义的固定数据常量。
successHeart、curHeart为我们要探测的数据变量。

TCP 动态心跳计算

如上图所示:

  • 应用进入后台(或者息屏)时,先用最小心跳间隔 MinHeart 维持心跳长链接;

  • 若连续三次MinHeart心跳均成功,则认为下一次相同时间间隔的心跳大概率也会成功;此时下次心跳,可以尝试增加一次心跳步进HeartStep;

  • 增加TCP心跳步进后,再次进行三次心跳探测,若连续三次均成功,则继续增加HeartStep步进,向上探测;

  • 若出现失败,则同一个curHeart累计出现3次失败时,则认为这个时间为NAT超时时间;
    同一个 curHeart 需要累计3次失败,才认定为失败,是为了排除用户处于弱网环境的情况下,比如地铁快速行进中。

  • 同一个 curHeart 累计3次失败时,则认为找到了NAT超时时间。
    下次心跳使用 successHeart = curHeart- HeartStep 作为心跳时间周期。

  • 使用 successHeart 作为心跳周期,若连续成功,则一直使用 successHeart 作为心跳周期;

  • 使用 successHeart 作为心跳周期,若连续出现3次失败,则认为探测数据失败,或者用户更换了网络环境,需重新探测。

5.3.2 冗余心跳

在用户对手机的的一些主动操作时,需增加冗余心跳,确保及时收到消息。

  • 当用户点亮屏幕(或熄灭屏幕)时,立刻做一次心跳;

  • 当应用切换到前台(或切换到后台)时,立刻做一次心跳;

  • 当用户切换网络状态时,重新建立TCP长连接;


版权声明

本文仅代表作者观点,不代表本站立场。
本文系作者授权发表,未经许可,不得转载。

评论