前言

• 當(dāng)實(shí)現(xiàn)具備實(shí)時(shí)性需求時(shí)，我們一般會(huì)選擇長(zhǎng)連接的通信方式
• 而在實(shí)現(xiàn)長(zhǎng)連接方式時(shí)，存在很多性能問(wèn)題，如 長(zhǎng)連接保活
• 今天，我將 手把手教大家實(shí)現(xiàn)自適應(yīng)的心跳保活機(jī)制，從而能高效維持長(zhǎng)連接

目錄

示意圖

1. 長(zhǎng)連接 介紹

1.1 簡(jiǎn)介

示意圖

1.2 作用

通過(guò) 長(zhǎng)時(shí)間保持雙方連接，從而：

• 提高通信速度
• 確保實(shí)時(shí)性
• 避免短時(shí)間內(nèi)重復(fù)連接所造成的信道資源 & 網(wǎng)絡(luò)資源的浪費(fèi)

1.3 長(zhǎng)連接 與 短連接的區(qū)別

示意圖

2. 長(zhǎng)連接斷開的原因

• 從上節(jié)可知，在長(zhǎng)連接的情況下，雙方的所有通信 都建立在1條長(zhǎng)連接上（1次TCP連接）；所以，長(zhǎng)連接 需要 持續(xù)保持雙方連接 才可使得雙方持續(xù)通信

• 可是，長(zhǎng)連接會(huì)存在斷開的情況，而 斷開原因 主要是：

  1. 長(zhǎng)連接所在進(jìn)程被殺死
  2. NAT超時(shí)
  3. 網(wǎng)絡(luò)狀態(tài)發(fā)生變化
  4. 其他不可抗因素（網(wǎng)絡(luò)狀態(tài)差、DHCP的租期等等 ）

下面，我將對(duì)每種原因進(jìn)行分析

原因1：進(jìn)程被殺死

當(dāng)進(jìn)程被殺死后，長(zhǎng)連接也會(huì)隨之?dāng)嚅_

原因2：NAT 超時(shí)（重點(diǎn)關(guān)注）

• NAT超時(shí)現(xiàn)象如下

示意圖

• 各運(yùn)營(yíng)商 & 地區(qū)的 NAT超時(shí)時(shí)間如下

示意圖

• 特別注意：排除其他外因（網(wǎng)絡(luò)切換、NAT超時(shí)、人為原因），TCP長(zhǎng)連接在雙方都不斷開連接的情況上，本質(zhì)上是不會(huì)自動(dòng)中斷的

1. 即，不需要心跳包來(lái)維持
2. 驗(yàn)證：讓2臺(tái)電腦連上同1個(gè)Wifi（其中1臺(tái)做服務(wù)器, 另1臺(tái)做客戶端連接服務(wù)器（無(wú)設(shè)置KeepAlive）；只要電腦、路由器不斷網(wǎng)斷電，那么，2臺(tái)電腦的長(zhǎng)連接是不會(huì)自動(dòng)中斷的。

原因3：網(wǎng)絡(luò)狀態(tài)發(fā)生變化

當(dāng)移動(dòng)客戶端網(wǎng)絡(luò)狀態(tài)發(fā)生變化時(shí)（如移動(dòng)網(wǎng)絡(luò) & Wifi切換、斷開、重連），也會(huì)使長(zhǎng)連接斷開

原因4：其他不可抗因素

如網(wǎng)絡(luò)狀態(tài)差、DHCP的租期到期等等，都會(huì)使得長(zhǎng)連接發(fā)生 偶然的斷開

DHCP的租期到期：對(duì)于 Android系統(tǒng)， DHCP到了租期后不會(huì)主動(dòng)續(xù)約 & 繼續(xù)使用過(guò)期IP,，從而導(dǎo)致長(zhǎng)連接 斷開

3. 高效維持長(zhǎng)連接的解決方案

• 在了解長(zhǎng)連接斷開原因后，針對(duì)對(duì)應(yīng)原因，此處給出 高效維持長(zhǎng)連接的解決方案

示意圖

• 為此，若需有效維持長(zhǎng)連接，則需要做到

示意圖

其實(shí)，說(shuō)得簡(jiǎn)單點(diǎn)：高效維持長(zhǎng)連接的關(guān)鍵在于

• 保活：處于連接狀態(tài)時(shí)盡量不要斷
• 斷線重連：斷了之后繼續(xù)重連回來(lái)

解決方案1：進(jìn)程保活

整體概括如下：

示意圖

解決方案2：心跳保活機(jī)制

這是本文的重點(diǎn)，下節(jié)開始會(huì)詳細(xì)解析

解決方案3：斷線重連機(jī)制

• 原理
  檢測(cè)網(wǎng)絡(luò)狀態(tài)變化 & 判斷連接的有效性
• 具體實(shí)現(xiàn)
  前者請(qǐng)參考文章：Android：檢測(cè)網(wǎng)絡(luò)狀態(tài)&監(jiān)聽網(wǎng)絡(luò)變化；后者主要存在于心跳保活機(jī)制，所以下面會(huì)在心跳保活機(jī)制中一起講解。

4. 心跳保活機(jī)制簡(jiǎn)介

• 心跳保活機(jī)制的整體介紹如下

示意圖

• 注：很多人容易混淆 心跳機(jī)制 & 輪詢機(jī)制，此處給出二者區(qū)別

示意圖

5. 主流心跳機(jī)制分析 & 對(duì)比

對(duì)國(guó)、內(nèi)外主流的移動(dòng)IM產(chǎn)品（WhatsApp、Line、微信）進(jìn)行了心跳機(jī)制的簡(jiǎn)單分析 & 對(duì)比，具體請(qǐng)看下圖

示意圖

6. 心跳機(jī)制方案 總體設(shè)計(jì)

下面，將根據(jù)市面上主流的心跳機(jī)制，設(shè)計(jì) 一套心跳機(jī)制方案

6.1 基本流程

示意圖

6.2 設(shè)計(jì)要點(diǎn)

• 對(duì)于心跳機(jī)制方案設(shè)計(jì)的主要考慮因素 = 保證消息的實(shí)時(shí)性 & 耗費(fèi)設(shè)備的資源（網(wǎng)絡(luò)流量、電量、CPU等等）
• 從上圖可以看出，對(duì)于心跳機(jī)制方案設(shè)計(jì)的要點(diǎn)在于
  1. 心跳包的規(guī)格（內(nèi)容 & 大小）
  2. 心跳發(fā)送的間隔時(shí)間
  3. 斷線重連機(jī)制 （核心 = 如何 判斷長(zhǎng)連接的有效性）

在下面的方案設(shè)計(jì)中，將針對(duì)這3個(gè)問(wèn)題給出詳細(xì)的解決方案。

7. 心跳機(jī)制方案 詳細(xì)設(shè)計(jì)

7.1 心跳包的規(guī)格

為了減少流量 & 提高發(fā)送效率，需要精簡(jiǎn)心跳包的設(shè)計(jì)

7.1.1 設(shè)計(jì)原則

主要從心跳包的內(nèi)容 & 大小入手，設(shè)計(jì)原則具體如下

示意圖

7.1.2 設(shè)計(jì)方案

心跳包 = 1個(gè)攜帶少量信息 & 大小在10字節(jié)內(nèi)的信息包

7.2 心跳發(fā)送的間隔時(shí)間

為了 防止NAT超時(shí) & 減少設(shè)備資源的消耗（網(wǎng)絡(luò)流量、電量、CPU等等），心跳發(fā)送的間隔時(shí)間 是 整個(gè) 心跳機(jī)制方案設(shè)計(jì)的重點(diǎn)。

7.2.1 設(shè)計(jì)原則

心跳發(fā)送間隔時(shí)間的設(shè)計(jì)原則如下

示意圖

7.2.2 設(shè)計(jì)方案

a. 最直接 & 常用方案

• 一般，最直接 & 常用的心跳發(fā)送間隔時(shí)間設(shè)置方案 ：每隔估計(jì) x 分鐘發(fā)送心跳包1次

• 即 選擇 ＜所有NAT超時(shí)時(shí)間最短（5分鐘）的時(shí)間 即可，綜合主流移動(dòng)IM產(chǎn)品，此處建議 x= 4分鐘

• 但是，這種方案存在一些問(wèn)題：

示意圖

下面，我將詳細(xì)講解 自適應(yīng)心跳間隔時(shí)間 的設(shè)計(jì)方案

b. 自適應(yīng)心跳間隔時(shí)間 設(shè)計(jì)方案

• 基本流程

示意圖

• 該方案需要解決的有2個(gè)核心問(wèn)題：

1.如何自適應(yīng)計(jì)算心跳間隔 從而使得心跳間隔 接近 當(dāng)前NAT 超時(shí)時(shí)間？

答：不斷增加心跳間隔時(shí)間進(jìn)行心跳應(yīng)答測(cè)試，直到心跳失敗5次后，即可找出最接近 當(dāng)前NAT 超時(shí)時(shí)間的心跳間隔時(shí)間。具體請(qǐng)看下圖：

示意圖

注：只有當(dāng)心跳間隔 接近 NAT 超時(shí)時(shí)間 時(shí)，才能最大化平衡 長(zhǎng)連接不中斷 & 設(shè)備資源消耗最低的問(wèn)題。

2.如何檢測(cè) 當(dāng)前網(wǎng)絡(luò)環(huán)境的NAT 超時(shí)時(shí)間 發(fā)生了變化 ？

答：當(dāng)前發(fā)送心跳包成功 的最大間隔時(shí)間（即最接近NAT超時(shí)時(shí)間的心跳間隔） 發(fā)送失敗5次后，則判斷當(dāng)前網(wǎng)絡(luò)環(huán)境的NAT 超時(shí)時(shí)間 發(fā)生了變化。具體請(qǐng)看下圖：

示意圖

注：在檢測(cè)到 NAT 超時(shí)時(shí)間 發(fā)生變化后，重新自適應(yīng)計(jì)算心跳間隔 從而使得心跳間隔 接近 NAT 超時(shí)時(shí)間

• 總結(jié)：統(tǒng)籌2個(gè)核心問(wèn)題，總結(jié)出自適應(yīng)心跳間隔時(shí)間 設(shè)計(jì)方案為下圖

示意圖

7.3 斷線重連機(jī)制

該機(jī)制的核心在于， 如何 判斷長(zhǎng)連接的有效性

即，什么情況下視為 長(zhǎng)連接 斷線？

7.3.1 設(shè)計(jì)原則

• 判斷長(zhǎng)連接是否有效的準(zhǔn)則 = 服務(wù)器是否返回心跳應(yīng)答
• 此處需要 分清：長(zhǎng)連接 存活 & 有效 狀態(tài)的區(qū)別：

示意圖

7.3.2 設(shè)計(jì)方案

• 基本思路
  若連續(xù)5次發(fā)送心跳后，服務(wù)器都無(wú)心跳應(yīng)答，則視為長(zhǎng)連接無(wú)效

通過(guò)計(jì)數(shù)計(jì)算

• 判斷流程

示意圖

7.3.3 網(wǎng)上流傳的方案

在網(wǎng)上流傳著一些用于判斷長(zhǎng)連接是否有效的方案，具體介紹如下

示意圖

至此，關(guān)于心跳保活機(jī)制已經(jīng)講解完畢。

7.4 總結(jié)

• 設(shè)計(jì)方案

示意圖

• 流程設(shè)計(jì)

其中，標(biāo)識(shí) “灰色” 的判斷流程參考上文描述

示意圖

8. 優(yōu)化 & 完善

• 上面的方案依然會(huì)存在缺陷，從而導(dǎo)致 長(zhǎng)連接斷開

如，長(zhǎng)連接本身不可用（此時(shí)重連多少次也沒(méi)用）

• 下面，將優(yōu)化 & 完善上述方案，從而保證 客戶端與服務(wù)器依然保持著通信狀態(tài)

• 優(yōu)化點(diǎn)

  1. 確保當(dāng)前網(wǎng)絡(luò)的有效性 & 穩(wěn)定性再開始長(zhǎng)連接
  2. 自適應(yīng)計(jì)算心跳包間隔時(shí)間的時(shí)機(jī)

8.1 確保當(dāng)前網(wǎng)絡(luò)的有效性 & 穩(wěn)定性再開始長(zhǎng)連接

• 問(wèn)題描述

示意圖

• 解決方案

示意圖

• 加入到原有 心跳保活機(jī)制 主流程

  
  
  示意圖

8.2 自適應(yīng)計(jì)算心跳包間隔時(shí)間的時(shí)機(jī)

• 問(wèn)題描述

示意圖

• 方案設(shè)計(jì)

示意圖

• 加入到原有 心跳保活機(jī)制 主流程

示意圖

8.3 總結(jié)

示意圖

9. 額外說(shuō)明：TCP 協(xié)議自帶 KeepAlive 的機(jī)制 是否 可替代心跳機(jī)制

很多人認(rèn)為，TCP 協(xié)議自身就有KeepAlive機(jī)制，為何基于它的通訊鏈接，仍需 在應(yīng)用層實(shí)現(xiàn)額外的心跳保活機(jī)制？

9.1 回答

• 結(jié)論：無(wú)法替代
• 原因：TCP KeepAlive機(jī)制 的作用 是檢測(cè)連接的有無(wú)（死活），但無(wú)法檢測(cè)連接是否有效。

“連接有效”的定義 = 雙方具備發(fā)送 & 接收消息的能力

9.2 KeepAlive 機(jī)制概述

先來(lái)看看KeepAlive 機(jī)制 是什么

示意圖

9.3 具體原因

KeepAlive 的機(jī)制 不可 替代心跳機(jī)制 的具體原因如下：

示意圖

9.4 特別注意

1. KeepAlive 機(jī)制只是操作系統(tǒng)底層的一個(gè)被動(dòng)機(jī)制，不應(yīng)該被上層應(yīng)用層使用
2. 當(dāng)系統(tǒng)關(guān)閉一個(gè)由KeepAlive 機(jī)制檢查出來(lái)的死連接時(shí)，是不會(huì)主動(dòng)通知上層應(yīng)用的，只能通過(guò)調(diào)用相應(yīng)IO操作的返回值中發(fā)現(xiàn)

9.6 結(jié)論

KeepAlive機(jī)制無(wú)法代替心跳機(jī)制，需要在應(yīng)用層 自己實(shí)現(xiàn)心跳機(jī)制以檢測(cè)長(zhǎng)連接的有效性，從而高效維持長(zhǎng)連接

10. 實(shí)現(xiàn)方式

• 關(guān)于該心跳保活機(jī)制的實(shí)現(xiàn)方案，可采用多種方案實(shí)現(xiàn)
• 在Android端，本人推薦使用 Rxjava，因?yàn)椋?strong>基于事件流的鏈?zhǔn)秸{(diào)用 的使用方式 使得 復(fù)雜方案 實(shí)現(xiàn)得更加優(yōu)雅、邏輯簡(jiǎn)潔 & 使用簡(jiǎn)單

RxJava簡(jiǎn)介如下

示意圖

• 關(guān)于RxJava的使用，請(qǐng)看我系列文章：手把手帶你玩轉(zhuǎn)RxJava

11. 總結(jié)

• 看完本文后，相信在高效維持長(zhǎng)連接的需求下，你可以完美地解決了！（具體總結(jié)如下）

示意圖

• 下面我將繼續(xù)對(duì)Android中的其他代碼規(guī)范進(jìn)行深入講解 ，有興趣可以繼續(xù)關(guān)注Carson_Ho的安卓開發(fā)筆記

請(qǐng)點(diǎn)贊！因?yàn)槟愕墓膭?lì)是我寫作的最大動(dòng)力！

相關(guān)文章閱讀
Android開發(fā)：最全面、最易懂的Android屏幕適配解決方案
Android事件分發(fā)機(jī)制詳解：史上最全面、最易懂
Android開發(fā)：史上最全的Android消息推送解決方案
Android開發(fā)：最全面、最易懂的Webview詳解
Android開發(fā)：JSON簡(jiǎn)介及最全面解析方法!
Android四大組件：Service服務(wù)史上最全面解析
Android四大組件：BroadcastReceiver史上最全面解析

歡迎關(guān)注Carson_Ho的簡(jiǎn)書！

不定期分享關(guān)于安卓開發(fā)的干貨，追求短、平、快，但卻不缺深度。