前言

當實現具備實時性需求時，我們一般會選擇長連接的通信方式

而在實現長連接方式時，存在很多性能問題，如 長連接保活

今天，我將 手把手教大家實現自適應的心跳保活機制，從而能高效維持長連接

目錄

示意圖

1. 長連接 介紹

1.1 簡介

示意圖

1.2 作用

通過 長時間保持雙方連接，從而：

提高通信速度

確保實時性

避免短時間內重復連接所造成的信道資源 & 網絡資源的浪費

1.3 長連接 與 短連接的區別

示意圖

2. 長連接斷開的原因

從上節可知，在長連接的情況下，雙方的所有通信 都建立在1條長連接上(1次TCP連接)；所以，長連接 需要 持續保持雙方連接 才可使得雙方持續通信

可是，長連接會存在斷開的情況，而 斷開原因 主要是：

長連接所在進程被殺死

NAT超時

網絡狀態發生變化

其他不可抗因素(網絡狀態差、DHCP的租期等等 )

下面，我將對每種原因進行分析

原因1：進程被殺死

當進程被殺死后，長連接也會隨之斷開

原因2：NAT 超時(重點關注)

NAT超時現象如下

示意圖

各運營商 & 地區的 NAT超時時間如下

示意圖

特別注意：排除其他外因(網絡切換、NAT超時、人為原因)，TCP長連接在雙方都不斷開連接的情況上，本質上是不會自動中斷的

即，不需要心跳包來維持

驗證：讓2臺電腦連上同1個Wifi(其中1臺做服務器, 另1臺做客戶端連接服務器(無設置KeepAlive)；只要電腦、路由器不斷網斷電，那么，2臺電腦的長連接是不會自動中斷的。

原因3：網絡狀態發生變化

當移動客戶端網絡狀態發生變化時(如移動網絡 & Wifi切換、斷開、重連)，也會使長連接斷開

原因4：其他不可抗因素

如網絡狀態差、DHCP的租期到期等等，都會使得長連接發生 偶然的斷開

DHCP的租期到期：對于 Android系統， DHCP到了租期后不會主動續約 & 繼續使用過期IP,，從而導致長連接 斷開

3. 高效維持長連接的解決方案

在了解長連接斷開原因后，針對對應原因，此處給出 高效維持長連接的解決方案

示意圖

為此，若需有效維持長連接，則需要做到

示意圖

其實，說得簡單點：高效維持長連接的關鍵在于

保活：處于連接狀態時盡量不要斷

斷線重連：斷了之后繼續重連回來

解決方案1：進程保活

整體概括如下：

示意圖

解決方案2：心跳保活機制

這是本文的重點，下節開始會詳細解析

解決方案3：斷線重連機制

原理

檢測網絡狀態變化 & 判斷連接的有效性

具體實現

前者請參考文章：Android：檢測網絡狀態&監聽網絡變化；后者主要存在于心跳保活機制，所以下面會在心跳保活機制中一起講解。

4. 心跳保活機制簡介

心跳保活機制的整體介紹如下

示意圖

注：很多人容易混淆 心跳機制 & 輪詢機制，此處給出二者區別

示意圖

5. 主流心跳機制分析 & 對比

對國、內外主流的移動IM產品(WhatsApp、Line、微信)進行了心跳機制的簡單分析 & 對比，具體請看下圖

示意圖

6. 心跳機制方案 總體設計

下面，將根據市面上主流的心跳機制，設計 一套心跳機制方案

6.1 基本流程

示意圖

6.2 設計要點

對于心跳機制方案設計的主要考慮因素 = 保證消息的實時性 & 耗費設備的資源(網絡流量、電量、CPU等等)

從上圖可以看出，對于心跳機制方案設計的要點在于

心跳包的規格(內容 & 大小)

心跳發送的間隔時間

斷線重連機制 (核心 = 如何 判斷長連接的有效性)

在下面的方案設計中，將針對這3個問題給出詳細的解決方案。

7. 心跳機制方案 詳細設計

7.1 心跳包的規格

為了減少流量 & 提高發送效率，需要精簡心跳包的設計

7.1.1 設計原則

主要從心跳包的內容 & 大小入手，設計原則具體如下

示意圖

7.1.2 設計方案

心跳包 = 1個攜帶少量信息 & 大小在10字節內的信息包

7.2 心跳發送的間隔時間

為了 防止NAT超時 & 減少設備資源的消耗(網絡流量、電量、CPU等等)，心跳發送的間隔時間 是 整個 心跳機制方案設計的重點。

7.2.1 設計原則

心跳發送間隔時間的設計原則如下

示意圖

7.2.2 設計方案

a. 最直接 & 常用方案

一般，最直接 & 常用的心跳發送間隔時間設置方案 ：每隔估計 x 分鐘發送心跳包1次

即 選擇 ＜所有NAT超時時間最短(5分鐘)的時間 即可，綜合主流移動IM產品，此處建議 x= 4分鐘

但是，這種方案存在一些問題：

示意圖

下面，我將詳細講解 自適應心跳間隔時間 的設計方案

b. 自適應心跳間隔時間 設計方案

基本流程

示意圖

該方案需要解決的有2個核心問題：

1.如何自適應計算心跳間隔 從而使得心跳間隔 接近 當前NAT 超時時間？

答：不斷增加心跳間隔時間進行心跳應答測試，直到心跳失敗5次后，即可找出最接近 當前NAT 超時時間的心跳間隔時間。具體請看下圖：

示意圖

注：只有當心跳間隔 接近 NAT 超時時間 時，才能最大化平衡 長連接不中斷 & 設備資源消耗最低的問題。

2.如何檢測 當前網絡環境的NAT 超時時間 發生了變化 ？

答：當前發送心跳包成功 的最大間隔時間(即最接近NAT超時時間的心跳間隔) 發送失敗5次后，則判斷當前網絡環境的NAT 超時時間 發生了變化。具體請看下圖：

示意圖

注：在檢測到 NAT 超時時間 發生變化后，重新自適應計算心跳間隔 從而使得心跳間隔 接近 NAT 超時時間

總結：統籌2個核心問題，總結出自適應心跳間隔時間 設計方案為下圖

示意圖

7.3 斷線重連機制

該機制的核心在于， 如何 判斷長連接的有效性

即，什么情況下視為 長連接 斷線？

7.3.1 設計原則

判斷長連接是否有效的準則 = 服務器是否返回心跳應答

此處需要 分清：長連接 存活 & 有效 狀態的區別：

示意圖

7.3.2 設計方案

基本思路

若連續5次發送心跳后，服務器都無心跳應答，則視為長連接無效

通過計數計算

判斷流程

示意圖

7.3.3 網上流傳的方案

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

示意圖

至此，關于心跳保活機制已經講解完畢。

7.4 總結

設計方案

示意圖

流程設計

其中，標識 “灰色” 的判斷流程參考上文描述

示意圖

8. 優化 & 完善

上面的方案依然會存在缺陷，從而導致 長連接斷開

如，長連接本身不可用(此時重連多少次也沒用)

下面，將優化 & 完善上述方案，從而保證 客戶端與服務器依然保持著通信狀態

優化點

確保當前網絡的有效性 & 穩定性再開始長連接

自適應計算心跳包間隔時間的時機

8.1 確保當前網絡的有效性 & 穩定性再開始長連接

問題描述

示意圖

解決方案

示意圖

加入到原有 心跳保活機制 主流程

示意圖

8.2 自適應計算心跳包間隔時間的時機

問題描述

示意圖

方案設計

示意圖

加入到原有 心跳保活機制 主流程

示意圖

8.3 總結

示意圖

9. 額外說明：TCP 協議自帶 KeepAlive 的機制 是否 可替代心跳機制

很多人認為，TCP 協議自身就有KeepAlive機制，為何基于它的通訊鏈接，仍需 在應用層實現額外的心跳保活機制？

9.1 回答

結論：無法替代

原因：TCP KeepAlive機制 的作用 是檢測連接的有無(死活)，但無法檢測連接是否有效。

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

9.2 KeepAlive 機制概述

先來看看KeepAlive 機制 是什么

示意圖

9.3 具體原因

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

示意圖

9.4 特別注意

KeepAlive 機制只是操作系統底層的一個被動機制，不應該被上層應用層使用

當系統關閉一個由KeepAlive 機制檢查出來的死連接時，是不會主動通知上層應用的，只能通過調用相應IO操作的返回值中發現

9.6 結論

KeepAlive機制無法代替心跳機制，需要在應用層 自己實現心跳機制以檢測長連接的有效性，從而高效維持長連接

10. 實現方式

關于該心跳保活機制的實現方案，可采用多種方案實現

在Android端，本人推薦使用 Rxjava，因為：基于事件流的鏈式調用 的使用方式 使得 復雜方案 實現得更加優雅、邏輯簡潔 & 使用簡單

RxJava簡介如下

示意圖

關于RxJava的使用，請看我系列文章：手把手帶你玩轉RxJava

11. 總結

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

示意圖

下面我將繼續對Android中的其他代碼規范進行深入講解 ，有興趣可以繼續關注Carson_Ho的安卓開發筆記

請點贊！因為你的鼓勵是我寫作的最大動力！

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

總結

以上是生活随笔為你收集整理的android 心跳 简书,如何高效维持网络长连接：手把手教你实现 自适应的心跳保活机制...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。