來源：http://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=207243549&idx=1&sn=4ebe4beb8123f1b5ab58810ac8bc5994&scene=0#rd
前言：在13年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的同事加入了討論，感覺這方面的交流還是很有必要的。
好了，廢話了很多，下面分享一下微信的智能心跳方案細節。由於字數比較多，建議大家使用PC版微信查看。
1.主要目標
本方案的主要目標是，在儘量不影響用戶收消息及時性的前提下，根據網絡類型自適應的找出保活信令TCP連接的儘可能大的心跳間隔，從而達到減少安卓微信因心跳引起的空中信道資源消耗，減少心跳Server的負載，以及減少部分因心跳引起的耗電。
主要方法是參考WhatsApp和Line中有價值的做法，結合影響TCP連接壽命的因素，實現Android微信後臺自適應心跳算法，同時使用GCM作爲輔助通道增加新消息通知的可靠性。
2. WhatsApp、Line、微信的Push策略分析
2.1 WhatsApp
在不支持GCM的設備上，採用和微信類似的長連接+心跳策略，WIFI和手機網絡下的心跳間隔都爲4分45秒，心跳5次後，主動斷開連接再重連。
在支持GCM的設備上，主要靠GCM來激活WhatsApp，WhatsApp啓動後，會建立一個與服務器的長連接，直接通過此長連接發送Push消息，這個長連接10分鐘無消息就會主動斷掉，且這十分鐘內不做心跳，斷掉後WhatsApp客戶端和它的服務器不再有連接。當有消息時候，服務器發現沒有長連接會發送GCM消息，手機收到GCM消息後，會重新建立長連接來收取消息，10分鐘無消息會再斷開，如此循環。
2.2 Line
從測試中發現Line在國內、臺灣、美國使用了不同的策略。
1、美國（使用GCM）：
啓動時，會保持7分鐘心跳（CDMA2000網絡）維持長連接半小時，之後主動斷開長連接。當有消息時，服務器會發送GCM消息，Line客戶端接收到GCM消息後，重新建立長連接，並再次用心跳維持半個小時。
2、國內（不使用GCM）：
在國內，同樣帳號在相同網絡，不同的手機上測出了兩種策略：
長連接+心跳策略（在Galaxy S3上使用），心跳間隔WIFI下是3分20秒，手機網絡是7分鐘。
輪詢策略（在紅米和Nexus S上使用），如圖2-1所示。與心跳策略的主要區別用紅色標出，客戶端在長連接建立後也會定時發送請求，Server會回覆並且同時關閉長連接。客戶端等待輪詢間隔T1後再次建立TCP連接。Line會根據手機的活躍狀態動態調整T1，調整範圍是從最小1分到最大到2小時半。而長連接存活時間T2比較固定，在WIFI下4分鐘，手機網絡7分鐘。如果在T2時收到新消息會延長T2的時間。
上圖是
Line在國內的輪詢策略
2.3 微信
微信沒有使用GCM，自己維護TCP長連接，使用固定心跳。
2.4心跳典型值
2.5Line、WhatsApp、微信Push策略的優點
a）微信：當前心跳間隔比競品短，所以微信在新消息提醒上會最及時。
b）使用GCM：Line和WhatsApp使用GCM策略的最大優點就是省電，以及減輕系統負荷（減少後臺應用數目）。
c）Line：Line的輪詢策略，優點是當Line處於活躍狀態時，及時收消息。當Line處於不活躍狀態時，省電。
2.6Line、WhatsApp微信Push策略的不足
a）微信當前心跳頻率相對競品較大，在耗電、耗流量，佔用信令通道等方面有所影響。
b）Line的輪詢策略，導致的問題是消息可能會延遲接收，測試發現最大延遲間隔到2.5小時。
c）WhatsApp和Line使用Push拉起一個定時長連接策略，缺點是要依賴Google的Push服務，如果Google的Push服務不穩定，消息也會延遲接收。
d）在國內的移動和聯通2G網絡下，由於運營商的策略，GCM長連接頻繁斷連，WhatsApp的Push消息很不及時，體驗非常差。
3. GCM研究
3.1 GCM特點
a）Android2.2以下的手機不支持GCM，2.2到3.0需要安裝Google Store並設置Google帳號，4.04及以上版本不需要設置帳號也能支持。
b）GCM只傳遞數據（可以傳遞小於4kb的數據），對這些數據的處理可以全部由開發者控制。
c）Android應用不需要運行就可以接收消息(通過Android廣播)。
d）GCM不保證發送的消息的順序，也不保證消息一定能夠推送到手機。
3.2 GCM心跳策略以及存在的問題
a）用心跳保活長連接，心跳間隔爲WIFI下15分鐘，數據網絡下28分鐘。
b）Google可以改變所有Android設備的心跳間隔值（目前還未改變過）。
c）GCM由於心跳間隔固定，並且較長，所以在NAT aging-time設置較小的網絡（如聯通2G，或有些WIFI環境下）會導致TCP長連接在下一次心跳前被網關釋放。造成Push延遲接收。
3.3 GCM的可用性及穩定性
目前測試發現GCM在國內可用性不高，原因有：
a） Android很多被手機廠商定製化，廠商可能會去掉GCM服務。
b） Android2.2到3.0之間需要安裝Google Store並設置Google帳號。
c）由於國內2G和移動3G的NAT超時時間都小於GCM心跳時間(28分鐘)，TCP長連接必然無法保活，每次都要等28分鐘心跳失敗重連後才能收到Push。
d）某些運營商可能限制了5228端口，移動3G/2G下，發現幾乎無法連接上GCM服務器，也就無法獲得GCM通知，WhatsApp放後臺10分鐘後，經常很長時間都收不到Push消息。
在美國3G網絡下抓包的24小時，GCM的連接極其穩定，24小時內GCM長連接未曾斷過，在臺灣3G網絡下抓包14個小時，GCM連接也只斷過一次。WhatsApp用戶在此類地區網絡下客戶端可以獲得很及時的Push通知。
在中國電信3G下抓包，大部分時間GCM連接都比較穩定，只會因爲偶爾的DHCP造成斷連現象，由於頻率很低(平均數小時才發生一次)，對Push體驗的影響不大。
3.4 GCM Server類型
GCM提供兩種Server模型：
a）HTTP Server : 使用同步接口發送HTTP請求，一次請求可以發給最多1000個設備。
b）XMPP Server :使用異步接口發送請求，只支持對單個設備（或同一個用戶的多個關聯設備發送），發送請求併發數須小於1000，支持設備到雲端Server發送數據。需要Google將我們的發送Server加入白名單。
4.微信可能的改進點探討
微信Push的優化主要有幾個優化點：
a） 公共Push通道
b） 使用GCM Push作爲輔助通道
c）自適應心跳間隔優化
4.1 公共Push通道
由於GCM在國內的可靠性很低，現在國內Android上的Push基本上是各自爲政，很多軟件都自己實現Push。導致手機被經常性的喚醒，耗電耗流量嚴重。
市面上已經有很多第三方的公共推送服務，大家可以選擇一個適合自己應用的推送服務。騰訊也有信鴿和維納斯組件，大家在選擇方案的時候可以對比下。
最終因爲我們國內外使用一套方案，並且是輔助公道，所以我們選擇使用GCM。
4.2 使用GCM Push作爲輔助通道
當前使用GCM的成本不大，可以使用GCM作爲輔助通道來增加新消息的及時性。
使用GCM作爲輔助通道，在支持GCM的設備上微信上傳自己的註冊GCM ID給微信Server。
微信Server在發現長連接失效的情況下，可以使用GCM 作爲輔助通道通知客戶端有新消息，客戶端收到push通知後做一次sync。
只利用GCM來激活微信，不傳遞消息的具體數據，要控制給同一設備發送GCM通知的時間間隔(如五分鐘)。
4.3 自適應心跳間隔優化
4.3.1影響TCP連接壽命的因素
在Android下，不管是GCM，還是微信，都是通過TCP長連接來進行Push消息的，TCP長連接存活，消息Push就及時，所以要對影響TCP連接壽命的因素進行研究。
1、NAT超時
大部分移動無線網絡運營商都在鏈路一段時間沒有數據通訊時，會淘汰 NAT 表中的對應項，造成鏈路中斷（NAT超時的更多描述見附錄6.1）。NAT超時是影響TCP連接壽命的一個重要因素(尤其是國內)，所以客戶端自動測算NAT超時時間，來動態調整心跳間隔，是一個重要的優化點。
2、DHCP的租期（lease time）
目前測試發現安卓系統對DHCP的處理有Bug，DHCP租期到了不會主動續約並且會繼續使用過期IP，這個問題會造成TCP長連接偶然的斷連。（租期問題的具體描述見附錄6.2）。
3、網絡狀態變化
手機網絡和WIFI網絡切換、網絡斷開和連上等情況有網絡狀態的變化，也會使長連接變爲無效連接，需要監聽響應的網絡狀態變化事件，重新建立Push長連接。
4.3.2 心跳範圍選擇
1、前後臺區分處理：
爲了保證微信收消息及時性的體驗，當微信處於前臺活躍狀態時，使用固定心跳。
微信進入後臺（或者前臺關屏）時，先用幾次最小心跳維持長鏈接。然後進入後臺自適應心跳計算。這樣做的目的是儘量選擇用戶不活躍的時間段，來減少心跳計算可能產生的消息不及時收取影響。
2、後臺自適應心跳選擇區間：
可根據自身產品的特點選擇合適的心跳範圍。
4.3.3 狀態轉換圖
4.3.4自適應心跳算法描述
1、按網絡類型區分計算：
因爲每個網絡的NAT時間可能不一致。所以需要區分計算，數據網絡按subType做關鍵字，WIFI按WIFI名做關鍵字。
對穩定的網絡，因爲NAT老化時間的存在，在自適應計算態的時候，暫設計以下步驟在當前心跳區間逼近出最大可用的心跳。
a） 變量說明：
[MinHeart，MaxHeart]——心跳可選區間。
successHeart——當前成功心跳，初始爲MinHeart
curHeart——當前心跳初始值爲successHeart
heartStep——心跳增加步長
successStep——穩定期後的探測步長
b） 最大值探測步驟：
自適應心跳計算流程如圖4-1所示，經過該流程，會找到必然使心跳失敗的curHeart（或者MaxHeart），爲了保險起見，我們選擇比前一個成功值稍微小一點的值作爲後臺穩定期的心跳間隔。
影響手機網絡測試的因素太多，爲了儘量保證測試結果的可靠性，我們使用延遲心跳測試法。在我們重新建立TCP連接後，先使用 短心跳連續成功三次，我們才認爲網絡相對穩定，可以使用curHeart進行一次心跳測試。圖4-2顯示了一次有效心跳測試過程。圖4-3顯示了在沒有達到穩定網絡環境時，我們會一直使用固定短心跳直到滿足三次連續短心跳成功。
使用延遲心跳測試的好處是，可以剔除偶然失敗，和網絡變化較大的情況（如地鐵），使測試結果相對可靠（五次延遲測試確定結論）。同時在網絡波動較大的情況，使用短心跳，保證收取消息相對及時。
c） 運行時的動態調整策略(已經按測算心跳穩定值後)
NAT超時值算出來後，在維持心跳的過程中的策略
ü 無網絡、網絡時好時壞、偶然失敗、NAT超時變小：在後臺穩定期發生心跳發生失敗後，我們使用延遲心跳測試法測試五次。如果有一次成功，則保持當前心跳值不變；如果五次測試全失敗，重新計算合理心跳值。該過程如圖4-4所示，有一點需要注意，每個新建的長連接需要先用短心跳成功維持3次後才用successHeart進行心跳。
圖4-2 後臺穩定態動態調整心跳策略
ü NAT超時變大：以周爲週期，每週三將後臺穩定態調至自適應計算態，使用心跳延遲法往後探測心跳間隔。
ü successHeart是NAT超時臨界值：因爲我們現在選擇的是一個比successHeart稍小的值作爲穩定值，所以在計算過程中可以避開臨界值。當運營商在我們後臺穩定期將NAT超時調整爲我們當前計算值，那麼由於我們每週會去向下探索，所以下一週探測時也可以及時調整正確。
4.3.5 冗餘Sync和心跳
在用戶的一些主動操作以及聯網狀態改變時，增加冗餘Sync和心跳，確保及時收到消息。
1、當用戶點亮屏幕的時候，做一次心跳。
2、當微信切換到前臺時，做一次Sync。
3、聯網時重建信令TCP，做一次Sync
5. 可能存在的風險及預防措施
5.1 DHCP租期因素
1、問題：根據目前的測試結果顯示，安卓不續約到期的IP Bug，會導致TCP連接在不確定的時間點失效，從而會導致一次心跳失敗。
2、預防：統計後臺穩定期的心跳成功率，上報給後臺。後臺可以按地區分網絡監控這個指標的波動，並且後臺可以根據不同的波動，動態調整某區域特定網絡下可選的心跳區間。
5.2 其他影響TCP壽命的因素
是否有遺漏的因素？歡迎各位聯繫我反饋。
6 附錄
6.1 附錄A——NAT超時介紹
因爲 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連接Internet，就需要通過運營商的網關做一個網絡地址轉換(Network Address Translation，NAT)。簡單的說運營商的網關需要維護一個外網 IP、端口到內網 IP、端口的對應關係，以確保內網的手機可以跟 Internet 的服務器通訊。
長連接心跳間隔必須要小於NAT超時時間(aging-time)，如果超過aging-time不做心跳，TCP長連接鏈路就會中斷，Server就無法發送Push給手機，只能等到客戶端下次心跳失敗後，重建連接才能取到消息。
6.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。
