而在實現長連線方式時，存在很多效能問題，如 長連線保活
今天，我將 手把手教大家實現自適應的心跳保活機制，從而能高效維持長連線
確保實時性
避免短時間內重複連線所造成的通道資源 & 網路資源的浪費
可是，長連線會存在斷開的情況，而 斷開原因 主要是：
長連線所在程序被殺死
nat超時
網路狀態發生變化
其他不可抗因素（網路狀態差、dhcp的租期等等 ）
特別注意：排除其他外因（網路切換、nat超時、人為原因），tcp長連線在雙方都不斷開連線的情況上，本質上是不會自動中斷的
驗證：讓2臺電腦連上同1個wifi（其中1臺做伺服器, 另1臺做客戶端連線伺服器（無設定keepalive）；只要電腦、路由器不斷網斷電，那麼，2臺電腦的長連線是不會自動中斷的。
斷線重連：斷了之後繼續重連回來
具體實現
前者請參考文章：android：檢測網路狀態&監聽網路變化；後者主要存在於心跳保活機制，所以下面會在心跳保活機制中一起講解。
從上圖可以看出，對於心跳機制方案設計的要點在於
心跳包的規格（內容 & 大小）
心跳傳送的間隔時間
斷線重連機制 （核心 = 如何 判斷長連線的有效性）
7.1.1 設計原則
7.1.2 設計方案
7.2.1 設計原則
7.2.2 設計方案
a. 最直接 & 常用方案
其中，x ＜5分鐘即可。（綜合主流移動im產品，此處建議 x= 4分鐘）
但是，這種方案存在一些問題：
b. 自適應心跳間隔時間 設計方案
7.3.1 設計原則
此處需要 分清：長連線 存活 & 有效 狀態的區別：
7.3.2 設計方案
通過計數計算
判斷流程
7.3.3 網上流傳的方案
如，長連線本身不可用（此時重連多少次也沒用）
下面，將優化 & 完善上述方案，從而保證 客戶端與伺服器依然保持著通訊狀態
優化點
確保當前網路的有效性 & 穩定性再開始長連線自適應計算心跳包間隔時間的時機
原因：tcp keepalive機制 的作用 是檢測連線的有無（死活），但無法檢測連線是否有效。
「連線有效」的定義 = 雙方具備傳送 & 接收訊息的能力
保活 心跳機制
英文 heartbeat mechanism 中文 保活機制 心跳機制 介紹 雙方建立互動的連線，但是並不是一直存在資料互動，有些連線會在資料互動完畢後，主動釋放連線，而有些不會，那麼在長時間無資料互動的時間段內，互動雙方都有可能出現掉電 宕機 異常重啟等各種意外，當這些意外發生之後，這些tcp連線...
Android長連線，怎麼處理心跳機制
心跳包的機制，其實就是傳統的長連線。或許有的人知道訊息推送的機制，訊息推送也是一種長連線 是將資料有伺服器端推送到客戶端這邊從而改變傳統的 拉 的請求方式。下面我來介紹一下安卓和客戶端兩個資料請求的方式 1 push 這個也就是有伺服器推送到客戶端這邊 現在有第三方技術 比如極光推送。2 pull ...
android 長連線的心跳及推送機制
在寫之前，我們首先了解一下為什麼android維護長連線需要心跳機制，首先我們知道，維護任何乙個長連線都需要心跳機制，客戶端傳送乙個心跳給 的。如果超過乙個時間的閾值，客戶端沒有收到伺服器的應答，或者伺服器沒有收到客戶端的心跳，那麼對客戶端來說則斷開與伺服器的連線重新建立乙個 連線，對伺服器來說只要...