默認
打賞 發表評論 0
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
融云技術分享:融云安卓端IM產品的網絡鏈路保活技術實踐
閱讀(3529) | 評論(0 收藏3 淘帖1 1

本文來自融云技術團隊原創分享,原文發布于“融云全球互聯網通信云”公眾號,原題《IM 即時通訊之鏈路保活》,即時通訊網收錄時有部分改動。


1、引言


眾所周知,IM 即時通訊是一項對即時性要求非常高的技術,而保障消息即時到達的首要條件就是鏈路存活。那么在復雜的網絡環境和國內安卓手機被深度定制化的條件下,如何保障鏈路存活呢?本文詳解了融云安卓端IM產品在基于 TCP 協議實現鏈路保活方面的實踐總結

2、相關文章



3、IM 系統整體框架


融云技術分享:融云安卓端IM產品的網絡鏈路保活技術實踐_1.png

如上圖所示,為了保障鏈路存活,一套成熟的 IM 系統一般會包含消息鏈路和推送鏈路兩條長連接通道

當有新消息到達時,消息服務首先會判斷消息鏈路是否存活,如果消息鏈路處于存活狀態,消息優先從消息鏈路下發到客戶端,否則會被路由到推送服務器,由推送鏈路下發。

綜上所述:鏈路保活涉及到消息鏈路和推送鏈路兩條鏈路的保活策略。基于這兩條鏈路使用場景的不同,保活策略上除了心跳機制是相同的,其它保活策略各有不同。下面將逐一解讀。

4、鏈路保活的必要性


基于 TCP 的 Socket 連接建立之后,如果不做任何處理,這個連接會長時間存在并且可用嗎?答案是否定的。

原因有兩點:

1)默認Socket 連接無法及時探測到鏈路的異常情況,即使將 Socket 的屬性參數 KeepAlive 設置為 True 仍然無法及時獲取到鏈路存活狀態。這是因為 Socket 的連接狀態是由一個狀態機進行維護的,連接完畢后,雙方都會處于建立狀態。假如某臺服務器因為某些原因導致負載超高,無法及時響應業務請求,這時 TCP 探測到的仍然是連接狀態,而實際上此鏈路已經不可用了。

2)國內運營商的 NAT 超時機制會把一定時間內沒有數據交互的連接斷開,這個時間可能只有幾分鐘,遠無法滿足我們的長連接需求。

這方面更詳細的技術文章,請見:為何基于TCP協議的移動端IM仍然需要心跳保活機制?》、《微信團隊原創分享:Android版微信后臺保活實戰分享(網絡保活篇)

5、通用保活機制-心跳機制


基于以上原因,要維持 Socket 連接長時間存活,就需要實現自己的保活機制

最通用的一種保活機制就是心跳機制。即客戶端每隔一段時間給服務器發送一個很小的數據包,根據能否收到服務器的響應來判斷鏈路的可用性。為了節省流量,這個包一般非常小(通常是越小越好,比如網易云信的IM云產品中1字節心跳包是作為產品賣點進行宣傳的),甚至沒有內容。

融云技術分享:融云安卓端IM產品的網絡鏈路保活技術實踐_2.png

那么客戶端如何實現定時發送心跳包呢?一般有兩種方式。

一種是通過 Java 里的 Timer 來實現。

最基本的步驟如下:

  • 1)建立一個要執行的任務 TimerTask ;
  • 2)創建一個 Timer 實例,通過 Timer 提供的 schedule() 方法,將 TimerTask 加入到定時器 Timer 中,設置每隔一段時間執行 TimerTask , 在 TimerTask 里發送心跳包。這種方式實現起來較簡單,而且省電,不需要持有 WakeLock 。缺點也很明顯,長時間在后臺,進程被回收或者系統休眠后, Timer 機制隨之失效。

另外一種方式是利用安卓系統的定時任務管理器 AlarmManager 循環執行發送心跳包的任務。

這種方式不會因為系統休眠而失效,系統休眠后仍然可以通過 WakeLock 喚醒,執行心跳任務。

因此相對 Timer 機制,這種方式比較費電,使用的時候一定要注意如下幾點:

  • 1)首先根據需求合理使用 AlarmManager 的鬧鐘參數。鬧鐘各參數的區別參考下表:
    融云技術分享:融云安卓端IM產品的網絡鏈路保活技術實踐_3.png
  • 2)其次 AlarmManager 提供了 cancel() 方法,在設置新的定時任務前,通過 cancel() 方法取消系統里設置的同類型任務,避免設置冗余任務。

最后,安卓從 6.0 版本引入了 Doze 模式,并提供了新的鬧鐘設置方法 setExactAndAllowWhileIdle() ,通過該方法設置的鬧鐘時間,系統會智能調度,將各個應用設置的事務統一在一次喚醒中處理,以達到省電的目的。推薦在安卓 6.0 以上系統中,優先使用該方法。

這方面更詳細的技術文章,請見:


6、消息鏈路保活機制


消息鏈路作為收發消息的主要通道,需要最大程度保障鏈路的可用性。在鏈路不可用或者異常斷開時,能及時探測并啟動重連等保障機制。

基于以上特性,消息鏈路除了前面所說的心跳機制外,還另外維護了兩套鏈路優化機制:復合連接機制和重連機制。

復合連接機制的基本步驟如下:

  • 1)客戶端連接導航服務器,導航服務器會下發應用對應的配置信息,其中包括連接服務器的地址列表;
  • 2)客戶端從第一個服務器地址嘗試連接,并啟動超時機制,如果連接失敗或沒有及時收到服務響應, 則繼續嘗試連接下一個直到成功連接,將成功連接的地址保存到本地,作為最優地址,后面連接時優先使用此地址。通過這種機制,能保障客戶端優先選用最優鏈路,縮短連接時間。

融云技術分享:融云安卓端IM產品的網絡鏈路保活技術實踐_4.png
▲ 復合連接機制原理

重連機制:則是指業務層在檢測到與服務器的連接斷開后,嘗試 N 次重新連接服務器,首次斷開 1 秒后會重新連接,如果仍然連接不成功,會在 2 秒后(重連間隔時間為上次重連間隔時間乘 2  )嘗試重新連接服務器,以此類推當嘗試重連 N 次后,仍然連不上服務器將不再嘗試重新連接,只有在網絡情況發生變化或重新打開應用時才會再次嘗試重連。

融云技術分享:融云安卓端IM產品的網絡鏈路保活技術實踐_5.png
▲ 重連機制原理

7、推送鏈路保活機制


推送鏈路作為消息到達的補充手段,要求盡可能延長在后臺的存活時間。即使被殺后,仍然能被再次喚醒。 iOS 手機有 APNS 來達到以上效果(詳見《了解iOS消息推送一文就夠:史上最全iOS Push技術詳解),但安卓的官方推送系統 FCM 在國內基本不可用。那在國內安卓系統上如何保障推送到達呢?

首先咱們需要先了解下安卓系統上進程管理的兩大機制:

  • 1)一種是 LMK 機制,英文是 Low Memory Killer , 基于 Linux 的內存管理機制衍生而來。主要是通過進程的 oom_adj 值來判定進程的重要程度,從而決定是否回收這些進程。 oom_adj 的值越低,代表重要度越高,比如 native 進程, framework 層啟動的系統進程,優先級一般都為負數。其次是前臺可見進程,系統也不會回收。然而可見進程退到后臺后, oom_adj 的值會立即升高,在系統定時清理時被殺;
  • 2)另外一種機制是安卓原生的權限管理機制( AppOps ),各大廠家在此基礎上又進行了深度定制化,比如小米的安全中心,華為的手機管家等,都用來進行權限管理。該權限管理機制運行在安卓系統的框架層,上層各應用的進程如果想嘗試重新啟動,系統首先會去權限管理中心檢查該進程有沒有自啟動權限,如果有,才準予啟動。否則,從框架層直接限制系統的啟動。

基于以上兩種機制,推送鏈路的保活也可分為兩大類。

第一類:進程保活:

它的思路是根據 LMK 機制提高進程優先級,降低被殺的幾率。

主要有以下幾種方法:

  • 1.1)監聽黑屏事件,啟動 1 像素透明 Activity :使應用進程轉為可視進程,降低被殺概率。在屏幕亮時,關閉該 Activity 。
  • 1.2)雙服務守護: A 服務以 startForeground() 形式啟動,發送一個通知, B 服務同樣以  startForeground() 形式啟動,且發送和 A 相同 ID 的通知,然后在 B 服務里調用 stopForeground() 方法,取消通知。這樣 A 服務就會以前臺進程的形式存活,且不影響用戶感知。
  • 1.3)根據文件鎖互斥原理,監視 Java  進程存活狀態:若被殺, Linux 層成功持有文件,則通過 exec() 命令,打開一個純 Linux 的可執行文件,開啟一個 Daemon 進程, 該進程因為從 Linux 層啟動,在安卓 5.0 之前,優先級會比較高,不會被殺。在安卓 5.0 之后,該方式不再有效。

第二類:進程拉活的策略和安卓系統的 AppOps 機制有關:

一般有如下幾種:

  • 1)利用 Service 本身的 Sticky 屬性,在 Service 的 onStartCommand() 中返回 START_STICKY ,這樣當 Service 被殺掉后,系統會自動嘗試重啟。不過在國內定制化的系統上,這種方式能成功重啟的幾率很低,需要用戶在權限管理中心打開自啟動等權限,才能成功拉活;
  • 2)也就是前面講過的心跳機制,不過這里要求使用 AlarmManager 設置  ELAPSED_REALTIME_WAKEUP 屬性的鬧鐘,在系統休眠后,才會正常接受到心跳事件,從而將進程拉活;
  • 3)通過監聽網絡切換,用戶行為等事件,拉起進程;
  • 4)應用間互相拉活。比如系統里有好幾個應用集成了同一個 SDK , 那么在用戶啟動其中某一個 App 的時候, SDK 會去掃描其它應用,把“兄弟姐妹” 拉活。這種方式對用戶體驗傷害非常大,會造成系統莫名其妙的耗電。

以下保活“黑科技”的詳細介紹文章,請詳讀:


隨著安卓系統版本的迭代,對后臺進程的啟動管控越來越嚴。為了解決推送的問題,各手機廠家推出了自己的系統級推送服務。由廠家在 Framework 層統一維護一條推送通道,上層所有應用共同使用該推送鏈路,不需要再維護單獨進程。當前支持系統級推送的廠家有:小米、華為、魅族、 vivo 、OPPO 。

鑒于Android系統對后臺進程管控越來越嚴,保活“黑科技”已經不怎么靈了:


集成第三方系統級推送之后,整個消息的收發流程可以參考下圖:
融云技術分享:融云安卓端IM產品的網絡鏈路保活技術實踐_6.png

這種系統級別的推送省電,省內存,到達率高。應用可以根據手機型號的不同,優先使用廠家系統級別的推送,再配合自身的保活機制,最大程度保障推送的到達率。

附錄:更多IM相關的技術文章匯總


[1] IM開發相關的熱門技術問題綜合文章:
新手入門一篇就夠:從零開發移動端IM
移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”
移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結
從客戶端的角度來談談移動端IM的消息可靠性和送達機制
現代移動端網絡短連接的優化手段總結:請求速度、弱網適應、安全保障
騰訊技術分享:社交網絡圖片的帶寬壓縮技術演進之路
小白必讀:閑話HTTP短連接中的Session和Token
IM開發基礎知識補課:正確理解前置HTTP SSO單點登陸接口的原理
移動端IM中大規模群消息的推送如何保證效率、實時性?
移動端IM開發需要面對的技術問題
開發IM是自己設計協議用字節流好還是字符流好?
請問有人知道語音留言聊天的主流實現方式嗎?
IM消息送達保證機制實現(一):保證在線實時消息的可靠投遞
IM消息送達保證機制實現(二):保證離線消息的可靠投遞
如何保證IM實時消息的“時序性”與“一致性”?
一個低成本確保IM消息時序的方法探討
IM單聊和群聊中的在線狀態同步應該用“推”還是“拉”?
IM群聊消息如此復雜,如何保證不丟不重?
談談移動端 IM 開發中登錄請求的優化
移動端IM登錄時拉取數據如何作到省流量?
淺談移動端IM的多點登陸和消息漫游原理
完全自已開發的IM該如何設計“失敗重試”機制?
通俗易懂:基于集群的移動端IM接入層負載均衡方案分享
微信對網絡影響的技術試驗及分析(論文全文)
即時通訊系統的原理、技術和應用(技術論文)

[2] 一些網絡編程基礎資料:
TCP/IP詳解 - 第11章·UDP:用戶數據報協議
TCP/IP詳解 - 第17章·TCP:傳輸控制協議
TCP/IP詳解 - 第18章·TCP連接的建立與終止
TCP/IP詳解 - 第21章·TCP的超時與重傳
技術往事:改變世界的TCP/IP協議(珍貴多圖、手機慎點)
通俗易懂-深入理解TCP協議(上):理論基礎
通俗易懂-深入理解TCP協議(下):RTT、滑動窗口、擁塞處理
高性能網絡編程(一):單臺服務器并發TCP連接數到底可以有多少
高性能網絡編程(二):上一個10年,著名的C10K并發連接問題
高性能網絡編程(三):下一個10年,是時候考慮C10M并發問題了
高性能網絡編程(四):從C10K到C10M高性能網絡應用的理論探索
高性能網絡編程(五):一文讀懂高性能網絡編程中的I/O模型
高性能網絡編程(六):一文讀懂高性能網絡編程中的線程模型
不為人知的網絡編程(一):淺析TCP協議中的疑難雜癥(上篇)
不為人知的網絡編程(二):淺析TCP協議中的疑難雜癥(下篇)
不為人知的網絡編程(三):關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT
不為人知的網絡編程(四):深入研究分析TCP的異常關閉
不為人知的網絡編程(五):UDP的連接性和負載均衡
不為人知的網絡編程(六):深入地理解UDP協議并用好它
不為人知的網絡編程(七):如何讓不可靠的UDP變的可靠?
不為人知的網絡編程(八):從數據傳輸層深度解密HTTP
不為人知的網絡編程(九):理論聯系實際,全方位深入理解DNS
網絡編程懶人入門(一):快速理解網絡通信協議(上篇)
網絡編程懶人入門(二):快速理解網絡通信協議(下篇)
網絡編程懶人入門(三):快速理解TCP協議一篇就夠
網絡編程懶人入門(四):快速理解TCP和UDP的差異
網絡編程懶人入門(五):快速理解為什么說UDP有時比TCP更有優勢
網絡編程懶人入門(六):史上最通俗的集線器、交換機、路由器功能原理入門
網絡編程懶人入門(七):深入淺出,全面理解HTTP協議
網絡編程懶人入門(八):手把手教你寫基于TCP的Socket長連接
網絡編程懶人入門(九):通俗講解,有了IP地址,為何還要用MAC地址?
現代移動端網絡短連接的優化手段總結:請求速度、弱網適應、安全保障
移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”
移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結
從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路
腦殘式網絡編程入門(一):跟著動畫來學TCP三次握手和四次揮手
腦殘式網絡編程入門(二):我們在讀寫Socket時,究竟在讀寫什么?
腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識
腦殘式網絡編程入門(四):快速理解HTTP/2的服務器推送(Server Push)
腦殘式網絡編程入門(五):每天都在用的Ping命令,它到底是什么?
腦殘式網絡編程入門(六):什么是公網IP和內網IP?NAT轉換又是什么鬼?
>> 更多同類文章 ……

[3] 有關推送技術方面的文章:
iOS的推送服務APNs詳解:設計思路、技術原理及缺陷等
信鴿團隊原創:一起走過 iOS10 上消息推送(APNS)的坑
Android端消息推送總結:實現原理、心跳保活、遇到的問題等
掃盲貼:認識MQTT通信協議
一個基于MQTT通信協議的完整Android推送Demo
IBM技術經理訪談:MQTT協議的制定歷程、發展現狀等
求教android消息推送:GCM、XMPP、MQTT三種方案的優劣
移動端實時消息推送技術淺析
掃盲貼:淺談iOS和Android后臺實時消息推送的原理和區別
絕對干貨:基于Netty實現海量接入的推送服務技術要點
移動端IM實踐:谷歌消息推送服務(GCM)研究(來自微信)
為何微信、QQ這樣的IM工具不使用GCM服務推送消息?
極光推送系統大規模高并發架構的技術實踐分享
從HTTP到MQTT:一個基于位置服務的APP數據通信實踐概述
魅族2500萬長連接的實時消息推送架構的技術實踐分享
專訪魅族架構師:海量長連接的實時消息推送系統的心得體會
深入的聊聊Android消息推送這件小事
基于WebSocket實現Hybrid移動應用的消息推送實踐(含代碼示例)
一個基于長連接的安全可擴展的訂閱/推送服務實現思路
實踐分享:如何構建一套高可用的移動端消息推送系統?
Go語言構建千萬級在線的高并發消息推送系統實踐(來自360公司)
騰訊信鴿技術分享:百億級實時消息推送的實戰經驗
百萬在線的美拍直播彈幕系統的實時推送技術實踐之路
京東京麥商家開放平臺的消息推送架構演進之路
了解iOS消息推送一文就夠:史上最全iOS Push技術詳解
基于APNs最新HTTP/2接口實現iOS的高性能消息推送(服務端篇)
解密“達達-京東到家”的訂單即時派發技術原理和實踐
技術干貨:從零開始,教你設計一個百萬級的消息推送系統
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:[已解決] 求助MobileIMSDK ios端連服務器一直登錄超時下一篇:求教關于IM應用中,聊天記錄數據存儲的一些疑問

本帖已收錄至以下技術專輯

推薦方案
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
乐彩网17500