Android微信智能心跳方案 Android微信智能心跳方案

  • 时间:
  • 浏览:0

4.3.5冗余Sync和生跳

successStep——稳定期后的探测步长

原因分析每个网络的NAT时间原因分析不一致。全都需用区分计算,数据网络按subType做关键字,WIFI按WIFI名做关键字。

a)HTTP Server :使用同步接口发送HTTP请求,一次请求能不能 能发给最多30000个设备。

c)WhatsApp和Line使用Push拉起一4个多定时长连接策略,缺点是要依赖Google的Push服务,原因分析Google的Push服务不稳定,消息也会延迟接收。

1问题图片图片:根据目前的测试结果显示,安卓不续约到期的IP Bug,会原因分析TCP连接在不选用的时间点失效,从而会原因分析一次心跳失败。

c)自适应心跳间隔优化

4分45

轮询策略(在红米和Nexus S上使用),如图2-1所示。与心跳策略的主要区别用红色标出,客户端在长连接建立后也会定时发送请求,Server会回复而且一齐关闭长连接。客户端等待歌曲轮询间隔T1后再次建立TCP连接。Line会根据手机的活跃情况报告动态调整T1,调整范围是从最小1分到最大到2小时半。而长连接存活时间T2比较固定,在WIFI下4分钟,手机网络7分钟。原因分析在T2时收到新消息会延长T2的时间。

4.3.3情况报告转换图

a)Android2.2以下的手机不支持GCM,2.2到3.0需用安装Google Store并设置Google帐号,4.04及以上版本不需用设置帐号能不能 支持。

a)微信当前心跳频率相对竞品较大,在耗电、耗流量,占用信令通道等方面有所影响。

当我和春哥想出第八个简单易行的方案后,当让当我们心里就很有底了,去找Ray讨论,Ray听原先一次通过,而且Ray约了Harvey,给Harvey讲原先,Harvey说听起来能不能 能,能不能 能试试。

b)XMPP Server :使用异步接口发送请求,只支持对单个设备(或同一4个多用户的多个关联设备发送),发送请求并发数须小于30000,支持设备到云端Server发送数据。需用Google将当让当我们的发送Server加入白名单。

1、当用户点亮屏幕的原先,做一次心跳。

b)GCM只传递数据(能不能 能传递小于4kb的数据),对哪此数据的避免能不能 能完整篇 由开发者控制。

successHeart——当前成功心跳,初始为MinHeart

a)变量说明:

对稳定的网络,原因分析NAT老化时间的居于,在自适应计算态的原先,暂设计以下步骤在当前心跳区间逼近出最大可用的心跳。

28分钟

1前后台区分避免:

d)GCM不保证发送的消息的顺序,全都保证消息一定能不能 推送到手机。

市面上原因分析有全都第三方的公共推送服务,当让当我们能不能 能选用一4个多适合买车人应用的推送服务。腾讯需用信鸽和维纳斯组件,当让当我们在选用方案的原先能不能 能对比下。

微信那么 使用GCM,买车人维护TCP长连接,使用固定心跳。

a)延迟心跳测试法:这是测试结果准确的前提保障,当让当我们认为长连接建立后连续三次成功的短心跳就能不能 能很大程度的保证下一次心跳环境是正常的。

15分钟

GCM

b)使用GCM:Line和WhatsApp使用GCM策略的最大优点全都费油,以及减轻系统负荷(减少后台应用数目)。

3、移动2G/3G,联通2G那么 抓到DHCP

算是有遗漏的因素?欢迎各位联系我反馈。

d)这些运营商原因分析限制了5228端口,移动3G/2G下,发现几乎无法连接上GCM服务器,也就无法获得GCM通知,WhatsApp放后台10分钟后,老会 很长时间都收能不能 能 Push消息。

b)使用GCM Push作为辅助通道

在中国电信3G下抓包,大要素时间GCM连接都比较稳定,只会原因分析偶尔的DHCP造成断连问题图片图片,原因分析频率很低(平均数小时才居于一次),对Push体验的影响不大。

中国电信3G

b)Android2.2到3.0之间需用安装Google Store设置Google帐号。

美国3G

中国移动3G和2G

2后台自适应心跳选用区间:

3、台湾(不使用GCM):

curHeart——当前心跳初始值为successHeart

a)Android全都被手机厂商定制化,厂商原因分析会加进去GCM服务。

微信Push的优化主要几个优化点:

从IBG同事win和guang提供的测试数据中看多,台湾使用的策略跟国内的轮询策略类似于。

4、美国3G下抓取24小时,那么 抓到DHCP



本文转自农夫山泉豪宅博客园博客,原文链接:http://www.cnblogs.com/yaowen/p/5685561.html,如需转载请自行联系原作者

1按网络类型区分计算:

4.3.4自适应心跳算法描述

手机网络

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

b)最大值探测步骤:

b)Google能不能 能改变所有Android设备的心跳间隔值(目前还未改变过)。

大于28分钟

4分45

台湾3G

2、国内(不使用GCM):

目前测试发现安卓系统对DHCP的避免有Bug

主要最好的土办法是参考WhatsApp和Line暗含价值的做法,结合影响TCP连接寿命的因素,实现Android微信后台自适应心跳算法,一齐使用GCM作为辅助通道增加新消息通知的可靠性。

1、美国(使用GCM):

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



图2-1 Line在国内的轮询策略

大于28分钟

图4-2后台稳定态动态调整心跳策略

图4-1自适应心跳计算流程

WhatsApp

大于28分钟

前言:在1311月中旬时,原因分析基础组件组人手紧张,Leo安排我和春哥去广州轮岗支援。刚到广州的原先,Ray而且你和春哥对LineWhatsApp的心跳机制进行分析。我和春哥抓包测试了差过多一4个多多礼拜,在当让当我们基本上摸清了LineWhatsApp的心跳机制后,Ray才真不知道们真正的任务——对微信的固定心跳进行优化,并真不知道们这需用一件容易的事情。于是我和春哥开始英文了了英语 构思第一4个多方案,当让当我们开始英文了了英语 想用统计的最好的土办法来避免问题图片图片,当让当我们拿着第一4个多方案和Ray讨论时,发现能不能 能 优雅应对Ray的所有提问:1、测试环境的准确性,失败到底是原因分析网络的行态原因分析还是原因分析用户当前的环境变化原因分析的暂时失败。2、临界值界定,原因分析方案选中的心跳值是临界值,当让当我们该为啥办。Ray和组件组同事在网络方面有极其雄厚的经验,其实他那么 给当让当我们指出明确的方向,但提出的问题图片图片帮助当让当我们变快的补齐需用面对的核心问题图片图片。这些 4个多问题图片图片而且你和春哥意识到原因分析能很好的避免,就能不能 能给出一4个多比较好的心跳方案。第一4个多问题图片图片我和春哥开始英文了了英语 就意识到,第八个问题图片图片当让当我们确其实一开始英文了了英语 时疏忽了。但直接避免这些 4个多问题图片图片其实不容易,这其实而且你和春哥迷茫了几天,有两三三7天 在纺园我都没为啥睡着,原因分析想能不能 能 更好的最好的土办法。直到有一天思路居于了这些转变,既然最优解比较简化,为哪此不绕过去,使用有损服务理念找次优解呢。让简化的事情简单化,好了,想到这里老会 有两种拨开云雾的感觉。

b)Line的轮询策略,原因分析的问题图片图片是消息原因分析会延迟接收,测试发现最大延迟间隔到2.5小时。

在国内,同样帐号在相同网络,不同的手机上测出了两种策略:

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

长连接+心跳策略(在Galaxy S3上使用),心跳间隔WIFI下是3分20秒,手机网络是7分钟。

WIFI

使用GCM作为辅助通道,在支持GCM的设备上微信上传买车人的注册GCM ID给微信Server

a)微信:当前心跳间隔比竞品短,全都微信在新消息提醒上会最及时。

好了,废话了全都,下面分享一下微信的智能心跳方案细节。原因分析字数比较多,建议当让当我们使用PC版微信查看。

3、网络情况报告变化

7分钟

5分钟

在美国3G网络下抓包的24小时,GCM的连接极其稳定,24小时内GCM长连接未曾断过,在台湾3G网络下抓包14个小时,GCM连接也只断过一次。WhatsApp用户在此类地区网络下客户端能不能 能获得很及时的Push通知。

最终原因分析当让当我们国内外使用一套方案,而且是辅助公道,全都当让当我们选用使用GCM

思路对了,方案就能不能 能做到简单而且可靠,当让当我们能不能 能看多最终的方案是比较简单的,而且效果还挺好的。在方案描述原先大概讲一下减低问题图片图片简化度的最好的土办法:

c)GCM原因分析心跳间隔固定,而且较长,全都在NAT aging-time设置较小的网络(如联通2G,或这些WIFI环境下)会原因分析TCP长连接在下一次心跳前被网关释放。造成Push延迟接收。

4.3.2心跳范围选用

在Android下,不管是GCM,还是微信,需用通过TCP长连接来进行Push消息的,TCP长连接存活,消息Push就及时,全需用对影响TCP连接寿命的因素进行研究。

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

c)临界值避免:当让当我们使用比计算出的心跳稍微小这些的值做为稳定心跳避免临界值。

目前测试发现GCM在国内可用性不高,原因分析有:

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

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

当前使用GCM的成本不大,能不能 能使用GCM作为辅助通道来增加新消息的及时性。

微信Server在发现长连接失效的情况报告下,能不能 能使用GCM作为辅助通道通知客户端有新消息,客户端收到push通知后做一次sync

d)在国内的移动和生通2G网络下,原因分析运营商的策略,GCM长连接频繁断连,WhatsApp的Push消息很不及时,体验非常差。

[MinHeart,MaxHeart]——心跳可选区间。

为了保证微信收消息及时性的体验,当微信居于前台活跃情况报告时,使用固定心跳。

微信进入后台(原因分析前台关屏)时,先用几个最小心跳维持长链接。而且进入后台自适应心跳计算。原先做的目的是尽量选用用户不活跃的时间段,来减少心跳计算原因分析产生的消息不及时收取影响。

2、DHCP的租期(lease time

d)动态调整:即使在一次完整篇 的智能心跳计算过程中,当让当我们那么 找到最好的值,当让当我们还有原因分析来进行校正。

c)Android应用不需用运行就能不能 能接收消息(通过Android广播)

2、当微信切换到前台时,做一次Sync

可根据自身产品的特点选用大概的心跳范围。

在用户的这些主动操作以及联网情况报告改变时,增加冗余Sync和生跳,确保及时收到消息。

目前测试发现安卓系统对DHCP的避免有Bug,DHCP租期到了过多主动续约而且会继续使用过期IP,这些 问题图片图片会造成TCP长连接偶然的断连。(租期问题图片图片的具体描述见附录6.2)。

Line

而且就开始英文了了英语 动手,分析竞品加选用方案花了差过多一4个多月。写心跳的主要代码,只花了一天时间,我记得那天是年会后的一天。回过头来再看这些 方案花费的时间还是值得的,要我灰度的统计数据显示,70%用户都能不能 能达到当让当我们的心跳上限。

b)成功一次认定,失败连续要素认定:成功是绝对的,连续失败多次才原因分析是失败。

中国联通2G

启动时,会保持7分钟心跳(CDMA30000网络)维持长连接半小时,原先主动断开长连接。当有消息时,服务器会发送GCM消息,Line客户端接收到GCM消息后,重新建立长连接,并再次用心跳维持半个小时。

原因分析GCM在国内的可靠性很低,现在国内Android上的Push基本上是个人所有所有为政,全都软件都买车人实现Push。原因分析手机被老会 性的唤醒,耗电耗流量严重。

在不支持GCM的设备上,采用和微信类似于的长连接+心跳策略,WIFI和手机网络下的心跳间隔都为4分45秒,心跳5次后,主动断开连接再重连。

1.主要目标

2预防:统计后台稳定期的心跳成功率,上报给后台。后台能不能 能按地区分网络监控这些 指标的波动,而且后台能不能 能根据不同的波动,动态调整某区域特定网络下可选的心跳区间。

在支持GCM的设备上,主要靠GCM来激活WhatsApp,WhatsApp启动后,会建立一4个多与服务器的长连接,直接通过此长连接发送Push消息,这些 长连接10分钟无消息就会主动断掉,且这十分钟内不做心跳,断掉后WhatsApp客户端和它的服务器不再有连接。当有消息原先,服务器发现那么 长连接会发送GCM消息,手机收到GCM消息后,会重新建立长连接来收归还 息,10分钟无消息会再断开,那么 循环。

2、未到租期的一九时间,安卓设备重新向DHCP Server申请IP租用。从目前测试结果来看,这些 问题图片图片恢复的比较快。

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租用。

3分20

ü无网络、网络时好时坏、偶然失败、NAT超时变小:在后台稳定期居于心跳居于失败后,当让当我们使用延迟心跳测试法测试五次。原因分析有一次成功,则保持当前心跳值不变;原因分析五次测试全失败,重新计算合理心跳值。该过程如图4-4所示,有这些需用注意,每个新建的长连接需用先用短心跳成功维持3次后才用successHeart进行心跳。

从测试中发现Line在国内、台湾、美国使用了不同的策略。

长连接心跳间隔需用要小于NAT超时时间(aging-time),原因分析超过aging-time不做心跳,TCP长连接链路就会中断,Server就无法发送Push给手机,能不能 能不能 能 等到客户端下次心跳失败后,重建连接能不能 取到消息

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

5分钟

c)运行时的动态调整策略(原因分析按测算心跳稳定值后)

üsuccessHeart是NAT超时临界值:原因分析当让当我们现在选用的是一4个多比successHeart稍小的值作为稳定值,全都在计算过程中能不能 能避开临界值。当运营商在当让当我们后台稳定期将NAT超时调整为当让当我们当前计算值,那么 原因分析当让当我们每周会去向下探索,全都下一周探测时能不能 能不能 及时调整正确。

4.3.1影响TCP连接寿命的因素

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

使用延迟心跳测试的好处是,能不能 能剔除偶然失败,和网络变化较大的情况报告(如地铁),使测试结果相对可靠(五次延迟测试选用结论)。一齐在网络波动较大的情况报告,使用短心跳,保证收归还 息相对及时。

a用心跳保活长连接,心跳间隔为WIFI下15分钟,数据网络下28分钟。

GCM提供两种Server模型:



大要素移动无线网络运营商需用链路一段时间那么 数据通讯时,会淘汰 NAT表中的对应项,造成链路中断。下表列出这些已测试过的网络的NAT超时时间(更多数据原因分析测试条件所限那么 测到)

只利用GCM来激活微信,不传递消息的具体数据,要控制给同一设备发送GCM通知的时间间隔(如五分钟)

1、NAT超时

a)公共Push通道

heartStep——心跳增加步长

c)Line:Line的轮询策略,优点是当Line居于活跃情况报告时,及时收消息。当Line居于不活跃情况报告时,费油。

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

c)原因分析国内2G和移动3G的NAT超时时间都小于GCM心跳时间(28分钟),TCP长连接必然无法保活,每次需用等28分钟心跳失败重连能不能 能收到Push

3、联网时重建信令TCP,做一次Sync

搞完智能心跳后一段时间在广州没事干,而且你跟Ray商量,Ray而且你去测试下WebView的性能瓶颈。而且我跟周斯基一齐来做这件事,搞完了安卓客户端WebView性能瓶颈测试后,原因分析怀孕的男人的女人一4个多人在深圳,领导就安排我先回深圳了。春哥坚守着把GCM要素完成后才回深圳。

自适应心跳计算流程如图4-1所示,经过该流程,会找到必然使心跳失败的curHeart(原因分析MaxHeart),为了保险起见,当让当我们选用比前一4个多成功值稍微小这些的值作为后台稳定期的心跳间隔。