前言：在13年11月中旬時，因為基礎(chǔ)組件組人手緊張，Leo安排我和春哥去廣州輪崗支援。剛到廣州的時候，Ray讓我和春哥對Line和WhatsApp的心跳機制進行分析。我和春哥抓包測試了差不多兩個多禮拜，在我們基本上摸清了Line和WhatsApp的心跳機制后，Ray才告訴我們真正的任務(wù)——對微信的固定心跳進行優(yōu)化，并告訴我們這不是一件容易的事情。于是我和春哥開始構(gòu)思第一個方案，我們開始想用統(tǒng)計的方法來解決問題，當(dāng)我們拿著第一個方案和Ray討論時，發(fā)現(xiàn)不能優(yōu)雅應(yīng)對Ray的所有提問：1、測試環(huán)境的準(zhǔn)確性，失敗到底是因為網(wǎng)絡(luò)的特性導(dǎo)致還是因為用戶當(dāng)前的環(huán)境變化導(dǎo)致的暫時失敗。2、臨界值界定，如果方案選中的心跳值是臨界值，我們該怎么辦。Ray和組件組同事在網(wǎng)絡(luò)方面有極其豐富的經(jīng)驗，雖然他沒有給我們指出明確的方向，但提出的問題幫助我們更快的補齊需要面對的核心問題。這兩個問題讓我和春哥意識到如果能很好的解決，就可以給出一個比較好的心跳方案。第一個問題我和春哥開始就意識到，第二個問題我們確實在一開始時疏忽了。但直接解決這兩個問題確實不容易，這著實讓我和春哥迷茫了幾天，有兩三天在紡園我都沒怎么睡著，因為想不到更好的方法。直到有一天思路發(fā)生了一些轉(zhuǎn)變，既然最優(yōu)解比較復(fù)雜，為什么不繞過去，使用有損服務(wù)理念找次優(yōu)解呢。讓復(fù)雜的事情簡單化，好了，想到這里突然有一種撥開云霧的感覺。

思路對了，方案就可以做到簡單并且可靠，大家可以看到最終的方案是比較簡單的，并且效果還挺好的。在方案描述之前大概講一下減低問題復(fù)雜度的方法：

a）延遲心跳測試法：這是測試結(jié)果準(zhǔn)確的前提保障，我們認(rèn)為長連接建立后連續(xù)三次成功的短心跳就可以很大程度的保證下一次心跳環(huán)境是正常的。

b）成功一次認(rèn)定，失敗連續(xù)累積認(rèn)定：成功是絕對的，連續(xù)失敗多次才可能是失敗。

c）臨界值避免：我們使用比計算出的心跳稍微小一點的值做為穩(wěn)定心跳避免臨界值。

d）動態(tài)調(diào)整：即使在一次完整的智能心跳計算過程中，我們沒有找到最好的值，我們還有機會來進行校正。

當(dāng)我和春哥想出第二個簡單易行的方案后，我們心里就很有底了，去找Ray討論，Ray聽完后一次通過，然后Ray約了Harvey，給Harvey講完后，Harvey說聽起來可以，可以試試。

然后就開始動手，分析競品加確定方案花了差不多兩個月。寫心跳的主要代碼，只花了一天時間，我記得那天是年會后的一天。回過頭來再看這個方案花費的時間還是值得的，后來灰度的統(tǒng)計數(shù)據(jù)顯示，70%用戶都可以達到我們的心跳上限。

搞完智能心跳后一段時間在廣州沒事干，我就跟Ray商量，Ray讓我去測試下WebView的性能瓶頸。然后我跟周斯基一起來做這件事，搞完了安卓客戶端WebView性能瓶頸測試后，因為懷孕的老婆一個人在深圳，領(lǐng)導(dǎo)就安排我先回深圳了。春哥堅守著把GCM部分完成后才回深圳。

等我們的心跳版本正式發(fā)布后，一年前我在公司km上分享了智能心跳方案，吸引不少做push的同事加入了討論，感覺這方面的交流還是很有必要的。

好了，廢話了很多，下面分享一下微信的智能心跳方案細節(jié)。由于字?jǐn)?shù)比較多，建議大家使用PC版微信查看。

1.主要目標(biāo)

本方案的主要目標(biāo)是，在盡量不影響用戶收消息及時性的前提下，根據(jù)網(wǎng)絡(luò)類型自適應(yīng)的找出保活信令TCP連接的盡可能大的心跳間隔，從而達到減少安卓微信因心跳引起的空中信道資源消耗，減少心跳Server的負載，以及減少部分因心跳引起的耗電。

主要方法是參考WhatsApp和Line中有價值的做法，結(jié)合影響TCP連接壽命的因素，實現(xiàn)Android微信后臺自適應(yīng)心跳算法，同時使用GCM作為輔助通道增加新消息通知的可靠性。

2. WhatsApp、Line、微信的Push策略分析

2.1 WhatsApp

在不支持GCM的設(shè)備上，采用和微信類似的長連接+心跳策略，WIFI和手機網(wǎng)絡(luò)下的心跳間隔都為4分45秒，心跳5次后，主動斷開連接再重連。

在支持GCM的設(shè)備上，主要靠GCM來激活WhatsApp，WhatsApp啟動后，會建立一個與服務(wù)器的長連接，直接通過此長連接發(fā)送Push消息，這個長連接10分鐘無消息就會主動斷掉，且這十分鐘內(nèi)不做心跳，斷掉后WhatsApp客戶端和它的服務(wù)器不再有連接。當(dāng)有消息時候，服務(wù)器發(fā)現(xiàn)沒有長連接會發(fā)送GCM消息，手機收到GCM消息后，會重新建立長連接來收取消息，10分鐘無消息會再斷開，如此循環(huán)。

2.2 Line

從測試中發(fā)現(xiàn)Line在國內(nèi)、臺灣、美國使用了不同的策略。

1、美國（使用GCM）：

啟動時，會保持7分鐘心跳（CDMA2000網(wǎng)絡(luò)）維持長連接半小時，之后主動斷開長連接。當(dāng)有消息時，服務(wù)器會發(fā)送GCM消息，Line客戶端接收到GCM消息后，重新建立長連接，并再次用心跳維持半個小時。

2、國內(nèi)（不使用GCM）：

在國內(nèi)，同樣帳號在相同網(wǎng)絡(luò)，不同的手機上測出了兩種策略：

長連接+心跳策略（在Galaxy S3上使用），心跳間隔WIFI下是3分20秒，手機網(wǎng)絡(luò)是7分鐘。

輪詢策略（在紅米和Nexus S上使用），如圖2-1所示。與心跳策略的主要區(qū)別用紅色標(biāo)出，客戶端在長連接建立后也會定時發(fā)送請求，Server會回復(fù)并且同時關(guān)閉長連接。客戶端等待輪詢間隔T1后再次建立TCP連接。Line會根據(jù)手機的活躍狀態(tài)動態(tài)調(diào)整T1，調(diào)整范圍是從最小1分到最大到2小時半。而長連接存活時間T2比較固定，在WIFI下4分鐘，手機網(wǎng)絡(luò)7分鐘。如果在T2時收到新消息會延長T2的時間。

圖2-1 Line在國內(nèi)的輪詢策略

3、臺灣（不使用GCM）：

從IBG同事win和guang提供的測試數(shù)據(jù)中看到，臺灣使用的策略跟國內(nèi)的輪詢策略類似。

2.3 微信

微信沒有使用GCM，自己維護TCP長連接，使用固定心跳。

2.4心跳典型值

2.5Line、WhatsApp、微信Push策略的優(yōu)點

a）微信：當(dāng)前心跳間隔比競品短，所以微信在新消息提醒上會最及時。

b）使用GCM：Line和WhatsApp使用GCM策略的最大優(yōu)點就是省電，以及減輕系統(tǒng)負荷（減少后臺應(yīng)用數(shù)目）。

c）Line：Line的輪詢策略，優(yōu)點是當(dāng)Line處于活躍狀態(tài)時，及時收消息。當(dāng)Line處于不活躍狀態(tài)時，省電。

2.6Line、WhatsApp微信Push策略的不足

a）微信當(dāng)前心跳頻率相對競品較大，在耗電、耗流量，占用信令通道等方面有所影響。

b）Line的輪詢策略，導(dǎo)致的問題是消息可能會延遲接收，測試發(fā)現(xiàn)最大延遲間隔到2.5小時。

c）WhatsApp和Line使用Push拉起一個定時長連接策略，缺點是要依賴Google的Push服務(wù)，如果Google的Push服務(wù)不穩(wěn)定，消息也會延遲接收。

d）在國內(nèi)的移動和聯(lián)通2G網(wǎng)絡(luò)下，由于運營商的策略，GCM長連接頻繁斷連，WhatsApp的Push消息很不及時，體驗非常差。

3. GCM研究

3.1 GCM特點

a）Android2.2以下的手機不支持GCM，2.2到3.0需要安裝Google Store并設(shè)置Google帳號，4.04及以上版本不需要設(shè)置帳號也能支持。

b）GCM只傳遞數(shù)據(jù)（可以傳遞小于4kb的數(shù)據(jù)），對這些數(shù)據(jù)的處理可以全部由開發(fā)者控制。

c）Android應(yīng)用不需要運行就可以接收消息(通過Android廣播)。

d）GCM不保證發(fā)送的消息的順序，也不保證消息一定能夠推送到手機。

3.2 GCM心跳策略以及存在的問題

a）用心跳保活長連接，心跳間隔為WIFI下15分鐘，數(shù)據(jù)網(wǎng)絡(luò)下28分鐘。

b）Google可以改變所有Android設(shè)備的心跳間隔值（目前還未改變過）。

c）GCM由于心跳間隔固定，并且較長，所以在NAT aging-time設(shè)置較小的網(wǎng)絡(luò)（如聯(lián)通2G，或有些WIFI環(huán)境下）會導(dǎo)致TCP長連接在下一次心跳前被網(wǎng)關(guān)釋放。造成Push延遲接收。

3.3 GCM的可用性及穩(wěn)定性

目前測試發(fā)現(xiàn)GCM在國內(nèi)可用性不高，原因有：

a） Android很多被手機廠商定制化，廠商可能會去掉GCM服務(wù)。

b） Android2.2到3.0之間需要安裝Google Store并設(shè)置Google帳號。

c）由于國內(nèi)2G和移動3G的NAT超時時間都小于GCM心跳時間(28分鐘)，TCP長連接必然無法保活，每次都要等28分鐘心跳失敗重連后才能收到Push。

d）某些運營商可能限制了5228端口，移動3G/2G下，發(fā)現(xiàn)幾乎無法連接上GCM服務(wù)器，也就無法獲得GCM通知，WhatsApp放后臺10分鐘后，經(jīng)常很長時間都收不到Push消息。

在美國3G網(wǎng)絡(luò)下抓包的24小時，GCM的連接極其穩(wěn)定，24小時內(nèi)GCM長連接未曾斷過，在臺灣3G網(wǎng)絡(luò)下抓包14個小時，GCM連接也只斷過一次。WhatsApp用戶在此類地區(qū)網(wǎng)絡(luò)下客戶端可以獲得很及時的Push通知。

在中國電信3G下抓包，大部分時間GCM連接都比較穩(wěn)定，只會因為偶爾的DHCP造成斷連現(xiàn)象，由于頻率很低(平均數(shù)小時才發(fā)生一次)，對Push體驗的影響不大。

3.4 GCM Server類型

GCM提供兩種Server模型：

a）HTTP Server : 使用同步接口發(fā)送HTTP請求，一次請求可以發(fā)給最多1000個設(shè)備。

b）XMPP Server :使用異步接口發(fā)送請求，只支持對單個設(shè)備（或同一個用戶的多個關(guān)聯(lián)設(shè)備發(fā)送），發(fā)送請求并發(fā)數(shù)須小于1000，支持設(shè)備到云端Server發(fā)送數(shù)據(jù)。需要Google將我們的發(fā)送Server加入白名單。

4.微信可能的改進點探討

微信Push的優(yōu)化主要有幾個優(yōu)化點：

a） 公共Push通道

b） 使用GCM Push作為輔助通道

c）自適應(yīng)心跳間隔優(yōu)化

4.1 公共Push通道

由于GCM在國內(nèi)的可靠性很低，現(xiàn)在國內(nèi)Android上的Push基本上是各自為政，很多軟件都自己實現(xiàn)Push。導(dǎo)致手機被經(jīng)常性的喚醒，耗電耗流量嚴(yán)重。

市面上已經(jīng)有很多第三方的公共推送服務(wù)，大家可以選擇一個適合自己應(yīng)用的推送服務(wù)。騰訊也有信鴿和維納斯組件，大家在選擇方案的時候可以對比下。

最終因為我們國內(nèi)外使用一套方案，并且是輔助公道，所以我們選擇使用GCM。

4.2 使用GCM Push作為輔助通道

當(dāng)前使用GCM的成本不大，可以使用GCM作為輔助通道來增加新消息的及時性。

使用GCM作為輔助通道，在支持GCM的設(shè)備上微信上傳自己的注冊GCM ID給微信Server。

微信Server在發(fā)現(xiàn)長連接失效的情況下，可以使用GCM 作為輔助通道通知客戶端有新消息，客戶端收到push通知后做一次sync。

只利用GCM來激活微信，不傳遞消息的具體數(shù)據(jù)，要控制給同一設(shè)備發(fā)送GCM通知的時間間隔(如五分鐘)。

4.3 自適應(yīng)心跳間隔優(yōu)化

4.3.1影響TCP連接壽命的因素

在Android下，不管是GCM，還是微信，都是通過TCP長連接來進行Push消息的，TCP長連接存活，消息Push就及時，所以要對影響TCP連接壽命的因素進行研究。

1、NAT超時

大部分移動無線網(wǎng)絡(luò)運營商都在鏈路一段時間沒有數(shù)據(jù)通訊時，會淘汰 NAT 表中的對應(yīng)項，造成鏈路中斷（NAT超時的更多描述見附錄6.1）。NAT超時是影響TCP連接壽命的一個重要因素(尤其是國內(nèi))，所以客戶端自動測算NAT超時時間，來動態(tài)調(diào)整心跳間隔，是一個重要的優(yōu)化點。

2、DHCP的租期（lease time）

目前測試發(fā)現(xiàn)安卓系統(tǒng)對DHCP的處理有Bug，DHCP租期到了不會主動續(xù)約并且會繼續(xù)使用過期IP，這個問題會造成TCP長連接偶然的斷連。（租期問題的具體描述見附錄6.2）。

3、網(wǎng)絡(luò)狀態(tài)變化

手機網(wǎng)絡(luò)和WIFI網(wǎng)絡(luò)切換、網(wǎng)絡(luò)斷開和連上等情況有網(wǎng)絡(luò)狀態(tài)的變化，也會使長連接變?yōu)闊o效連接，需要監(jiān)聽響應(yīng)的網(wǎng)絡(luò)狀態(tài)變化事件，重新建立Push長連接。

4.3.2 心跳范圍選擇

1、前后臺區(qū)分處理：

為了保證微信收消息及時性的體驗，當(dāng)微信處于前臺活躍狀態(tài)時，使用固定心跳。

微信進入后臺（或者前臺關(guān)屏）時，先用幾次最小心跳維持長鏈接。然后進入后臺自適應(yīng)心跳計算。這樣做的目的是盡量選擇用戶不活躍的時間段，來減少心跳計算可能產(chǎn)生的消息不及時收取影響。

2、后臺自適應(yīng)心跳選擇區(qū)間：

可根據(jù)自身產(chǎn)品的特點選擇合適的心跳范圍。

4.3.3 狀態(tài)轉(zhuǎn)換圖

4.3.4自適應(yīng)心跳算法描述

1、按網(wǎng)絡(luò)類型區(qū)分計算：

因為每個網(wǎng)絡(luò)的NAT時間可能不一致。所以需要區(qū)分計算，數(shù)據(jù)網(wǎng)絡(luò)按subType做關(guān)鍵字，WIFI按WIFI名做關(guān)鍵字。

對穩(wěn)定的網(wǎng)絡(luò)，因為NAT老化時間的存在，在自適應(yīng)計算態(tài)的時候，暫設(shè)計以下步驟在當(dāng)前心跳區(qū)間逼近出最大可用的心跳。

a） 變量說明：

[MinHeart，MaxHeart]——心跳可選區(qū)間。

successHeart——當(dāng)前成功心跳，初始為MinHeart

curHeart——當(dāng)前心跳初始值為successHeart

heartStep——心跳增加步長

successStep——穩(wěn)定期后的探測步長

b） 最大值探測步驟：

圖4-1 自適應(yīng)心跳計算流程

自適應(yīng)心跳計算流程如圖4-1所示，經(jīng)過該流程，會找到必然使心跳失敗的curHeart（或者MaxHeart），為了保險起見，我們選擇比前一個成功值稍微小一點的值作為后臺穩(wěn)定期的心跳間隔。

影響手機網(wǎng)絡(luò)測試的因素太多，為了盡量保證測試結(jié)果的可靠性，我們使用延遲心跳測試法。在我們重新建立TCP連接后，先使用 短心跳連續(xù)成功三次，我們才認(rèn)為網(wǎng)絡(luò)相對穩(wěn)定，可以使用curHeart進行一次心跳測試。圖4-2顯示了一次有效心跳測試過程。圖4-3顯示了在沒有達到穩(wěn)定網(wǎng)絡(luò)環(huán)境時，我們會一直使用固定短心跳直到滿足三次連續(xù)短心跳成功。

使用延遲心跳測試的好處是，可以剔除偶然失敗，和網(wǎng)絡(luò)變化較大的情況（如地鐵），使測試結(jié)果相對可靠（五次延遲測試確定結(jié)論）。同時在網(wǎng)絡(luò)波動較大的情況，使用短心跳，保證收取消息相對及時。

c） 運行時的動態(tài)調(diào)整策略(已經(jīng)按測算心跳穩(wěn)定值后)

NAT超時值算出來后，在維持心跳的過程中的策略

ü 無網(wǎng)絡(luò)、網(wǎng)絡(luò)時好時壞、偶然失敗、NAT超時變小：在后臺穩(wěn)定期發(fā)生心跳發(fā)生失敗后，我們使用延遲心跳測試法測試五次。如果有一次成功，則保持當(dāng)前心跳值不變；如果五次測試全失敗，重新計算合理心跳值。該過程如圖4-4所示，有一點需要注意，每個新建的長連接需要先用短心跳成功維持3次后才用successHeart進行心跳。

圖4-2 后臺穩(wěn)定態(tài)動態(tài)調(diào)整心跳策略

ü NAT超時變大：以周為周期，每周三將后臺穩(wěn)定態(tài)調(diào)至自適應(yīng)計算態(tài)，使用心跳延遲法往后探測心跳間隔。

ü successHeart是NAT超時臨界值：因為我們現(xiàn)在選擇的是一個比successHeart稍小的值作為穩(wěn)定值，所以在計算過程中可以避開臨界值。當(dāng)運營商在我們后臺穩(wěn)定期將NAT超時調(diào)整為我們當(dāng)前計算值，那么由于我們每周會去向下探索，所以下一周探測時也可以及時調(diào)整正確。

4.3.5 冗余Sync和心跳

在用戶的一些主動操作以及聯(lián)網(wǎng)狀態(tài)改變時，增加冗余Sync和心跳，確保及時收到消息。

1、當(dāng)用戶點亮屏幕的時候，做一次心跳。

2、當(dāng)微信切換到前臺時，做一次Sync。

3、聯(lián)網(wǎng)時重建信令TCP，做一次Sync

5. 可能存在的風(fēng)險及預(yù)防措施

5.1 DHCP租期因素

1、問題：根據(jù)目前的測試結(jié)果顯示，安卓不續(xù)約到期的IP Bug，會導(dǎo)致TCP連接在不確定的時間點失效，從而會導(dǎo)致一次心跳失敗。

2、預(yù)防：統(tǒng)計后臺穩(wěn)定期的心跳成功率，上報給后臺。后臺可以按地區(qū)分網(wǎng)絡(luò)監(jiān)控這個指標(biāo)的波動，并且后臺可以根據(jù)不同的波動，動態(tài)調(diào)整某區(qū)域特定網(wǎng)絡(luò)下可選的心跳區(qū)間。

5.2 其他影響TCP壽命的因素

是否有遺漏的因素？歡迎各位聯(lián)系我反饋。

6 附錄

6.1 附錄A——NAT超時介紹

因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內(nèi)網(wǎng)的 IP，手機要連接 Internet，就需要通過運營商的網(wǎng)關(guān)做一個網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation，NAT)。簡單的說運營商的網(wǎng)關(guān)需要維護一個外網(wǎng) IP、端口到內(nèi)網(wǎng) IP、端口的對應(yīng)關(guān)系，以確保內(nèi)網(wǎng)的手機可以跟 Internet 的服務(wù)器通訊。

NAT 功能由圖中的 GGSN 模塊實現(xiàn)

大部分移動無線網(wǎng)絡(luò)運營商都在鏈路一段時間沒有數(shù)據(jù)通訊時，會淘汰 NAT 表中的對應(yīng)項，造成鏈路中斷。下表列出一些已測試過的網(wǎng)絡(luò)的NAT超時時間(更多數(shù)據(jù)由于測試條件所限沒有測到)：

長連接心跳間隔必須要小于NAT超時時間(aging-time)，如果超過aging-time不做心跳，TCP長連接鏈路就會中斷，Server就無法發(fā)送Push給手機，只能等到客戶端下次心跳失敗后，重建連接才能取到消息。

6.2 附錄B——安卓DHCP的租期（lease time）問題

目前測試發(fā)現(xiàn)安卓系統(tǒng)對DHCP的處理有Bug：

1、 DHCP租期到了不會主動續(xù)約并且會繼續(xù)使用過期IP，詳細描述見http://www.net.princeton.edu/android/android-stops-renewing-lease-keeps-using-IP-address-11236.html。這個問題導(dǎo)致的問題表象是，在超過租期的某個時間點（沒有規(guī)律）會導(dǎo)致IP過期，老的TCP連接不能正常收發(fā)數(shù)據(jù)。并且系統(tǒng)沒有網(wǎng)絡(luò)變化事件，只有等應(yīng)用判斷主動建立新的TCP連接才引起安卓設(shè)備重新向DHCP Server申請IP租用。

2、 未到租期的一半時間，安卓設(shè)備重新向DHCP Server申請IP租用。從目前測試結(jié)果來看，這種現(xiàn)象恢復(fù)的比較快。

3、 移動2G/3G，聯(lián)通2G沒有抓到DHCP。

4、 美國3G下抓取24小時，沒有抓到DHCP。