開發(fā)社交類APP項目，我們都知道離不開聊天功能，那么聊天App后臺架構應該怎樣布局結構更高效？因為聊天是目前移動互聯網流行的通信方式，聊天功能是當今App后臺功能中的重要部分，比如當用戶a向用戶b發(fā)送了段消息后，用戶b在線的話就能立刻收到消息等等，這些問題是我們APP開發(fā)人員需要面對解決的問題，深圳APP開發(fā)公司本文與各位一起分享我們開發(fā)工程師在處理這方面問題的經驗。研究聊天功能，就要先明白移動互聯網有別于PC互聯網的特性，從而更好地明白協議和架構背后的原理，下面我們先分享移動網絡的特性：
APP開發(fā)經驗之移動互聯網的網絡特性
當數據從網絡的端發(fā)送到另外端（例如從App端到App后臺），只有通過一個共同的約定（即協議），雙方才能正確解析這些數據協議就相當于一套語言（例如中文和英語），通信的雙方必須知道每個數據是什么含義，才能準確解析數據。
因為移動互聯網的特性，所以傳統的PC通信協議不適用于移動互聯網。下面從移動互聯網的特性出發(fā)，詳細講述聊天的協議移動互聯網有兩個顯著的特點。
·弱網絡性
·對流量敏感
1．APP開發(fā)聊天功能移動網絡環(huán)境之弱網絡性
弱網絡性是指由于手機不斷移動（例如在7氣車、地鐵上）的特性，有可能處于快速移動當中，因此出現信號不穩(wěn)定、響應時間變長、出現經常丟包等情況。例如有時在地鐵上，從App發(fā)送請求到App后臺，App后臺處理完畢后返回數據這個過程因為延遲就可能需要10秒，該流程如圖9-2所示。
APP開發(fā)知識移動網絡之弱網絡特性案例示意圖9-2地鐵車廂中App請求耗時
因此針對弱網絡環(huán)境，開發(fā)者在沒計協議時必須考慮盡量減少數據往返的次數，數據往返的次數越多，耗時越長。另外由于弱網絡性，App以長連接的形式連接到服務器，可能會出現App和服務器的連接忽然中斷的情況，而且這種情況是沒法通過連接端口的異常判斷。例如當地鐵高速行駛導致網絡中斷，App沒法向服務器的端口發(fā)送斷開的信息，服務器還是以為和App直保持著連接，這種現象稱為TCP half-open。
TCP half-open對我們APP開發(fā)功能的危害如下
·占用了服務器的資源（服務器維持個連接是需要耗費內存的）
·發(fā)送消息的異常。
有效防止TCP half-open的方法是使用應用層心跳機制：在App和服務器保持連接的過程中，App在規(guī)定時間間隔內向服務器發(fā)送一個數據（為了節(jié)省流量，數據可以只是個字符“h”，因為是隔定時間就發(fā)送次，這種數據被形象地稱為“心跳數據”）。服務器收到這個數據知道這個連接是有效的。對于那些超過規(guī)定時間間隔還未收到心跳數據的連接，服務器就主動斷開連接，通過這種機制就能有效解決TCP half-open的現象。
服務器檢查App的連接有3種方式。
(1)服務器記錄每個連接收到心跳包的最后時間，每隔一段時間檢查所有連接，如果發(fā)現某個連接最后收到心跳包的時間減去當前時間的值大干超時時間，就把那個連接斷開。如圖9-3所示，服務器的當前時間為“2018-09-03 17:53:02”，各個連接最后收到心跳包的時間如下。
APP開發(fā)聊天功能與網絡協議處理流程圖9-3服務器忙存的連接的時間
假設服務器設定的超時時間是60秒，經比較，璉接l最后收到心跳包的時司超過了60秒，那么連接l將會被服務器斷開這種方式的主要缺點是服務器需要同時檢查所有連接，如果連接的數目很大（例如上萬，上十萬），檢查連接時對系統的性能影響大
(2)服務器為每個連接建立個定時器，到了規(guī)定的超時時司沒有收到心跳包定時器就觸發(fā)把當前的連接斷開，如果收到心跳包，就重設定時器，不斷重復前面的過程。下面舉個例子說明。
當前服務器的時司是2018-09-03 20:02:02．設定超時時間是60秒當App和服務器建立連接，根據超時時間為這個連接設置了定時器的觸發(fā)時間為2018-09-03 20：03：02，如圖9-4所示。
APP開發(fā)經驗示意圖9-4建立連接，初始化定時器
在2018-09-03 20:03:00，App向服務器發(fā)送了個心跳包，服務器收到心跳包后把定時器的觸發(fā)重設h201s-09-03 20:04:00．如圖9-5所示。
APP開發(fā)聊天功能與服務器協議流程示意圖9-5服務器收到心跳包后重設定時器
如果服務器到了定時的觸發(fā)時間2018-09-03 20:04:OO還沒有收到App新發(fā)送的心跳包，則定時器被觸發(fā)，主動端口了服務器和App的連接，如圖9-6所示。
APP開發(fā)聊天功能與服務器傳送協議流程示意圖9—6沒收到心跳包觸發(fā)時器斷開連接
這種方式的主要缺點是為每個連接建立個獨立的定時器，如果連接的數目很大（例如上萬、上十萬）．就會建立上萬、上十萬的定時器，也會消耗大量的系統資源。
(3)這種方式是(1)和(2)的折中，稱為時間輪片(Timing Wheel)。按照超時時司的長短，每秒設置一個桶，如果超時時間為60秒就設置60個桶．60個桶組成個循環(huán)隊列。第一個桶欣秒后將要超時的連接，第二個桶欣兩秒后將要超時的連接，每個連接收到心跳包就把自己放在第60個桶，然后在每秒的定時器中把第個桶的所有連接斷開，把這個空桶挪到隊尾。時間輪片的模型如圖9-7所示。
APP開發(fā)聊天功能與服務器傳送協議示意圖9-7時間輪片模型
這種服務器檢查App的連接的方式，好處是不需要檢查所有的連接，節(jié)省了大量的系統資源。
2．APP開發(fā)聊天功能移動網絡環(huán)境之對流量敏感
在非Wi-Fi環(huán)境下用戶使用手機卡的流量套餐上網，用戶對流量比較敏感，各種安全監(jiān)控App也經常提醒用戶，某某應用耗費了多少流量，用戶看到這種消息就非常緊張，如果是生活必備的App用戶可能就忍了，但其他App用戶可能就直接卸載。以上問題APP開發(fā)公司提醒我們程序員在處理聊天類項目功能時必須要注意避免的。好了，本文關于聊天類APP制作時對于移動網絡特性了解方面的經驗就分享到這里。謝謝關注，博納網絡編輯整理。
