1、引言

本文內(nèi)容來自vivo互聯(lián)網(wǎng)服務(wù)器團隊李青鑫在“2021 vivo開發(fā)者大會”現(xiàn)場的演講內(nèi)容整理而成（現(xiàn)場演講稿可從本文末附件中下載）。

本文將要分享的是手機廠商vivo的系統(tǒng)級推送平臺在架構(gòu)設(shè)計上的技術(shù)實踐和總結(jié)。這也是目前為止首次由手機廠商分享的自建系統(tǒng)級推送平臺的技術(shù)細(xì)節(jié)，我們也得以借此機會一窺廠商ROOM級推送通道的技術(shù)水準(zhǔn)。

學(xué)習(xí)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4008-1-1.html）

2、關(guān)于作者

李青鑫，vivo互聯(lián)網(wǎng)服務(wù)器團隊架構(gòu)師。

3、為什么需要消息推送

消息推送對于移動端APP來說，是很常見的業(yè)務(wù)特征，比如新聞APP中的最新資訊、社交應(yīng)用中的系統(tǒng)通知、IM即時通訊應(yīng)用的離線聊天消息等等。

可以說，沒有消息推送能力，APP就失去了實時觸達的能力，對于一個應(yīng)用來說，它對用戶的“粘性”將大大下降。而對于用戶來說，信息實時獲取的能力也將大大降低，用戶體驗也將大幅下降。

4、消息推送的技術(shù)障礙

以我們?nèi)粘Ｗ畛Ｒ姷腎M應(yīng)用來說，離線消息的推送是必備能力。

但隨著Android系統(tǒng)的不斷升級，離線推送已經(jīng)不單單是一個后臺服務(wù)加長連接那么理所當(dāng)然了。

對于早期的Android系統(tǒng)來說，想要實現(xiàn)IM的離線消息推送并不困難，搞個后臺服務(wù)再加上socket長連接就算是齊活了。

但隨著Android系統(tǒng)的升級，針對后臺進程和網(wǎng)絡(luò)服務(wù)限制不斷加碼，為了繼續(xù)實現(xiàn)離線消息的推送，開發(fā)者們不得不跟系統(tǒng)斗志斗勇，搞出了各種?；詈诳萍?，比如：Android4.0之后的雙進程守護、Android6.0及之后的防殺復(fù)活術(shù)、以及發(fā)展到后來的騰訊TIM進程永生技術(shù)，一時間群魔亂舞、無比風(fēng)騷（有興趣的同學(xué)，可以讀讀《Android進程永生技術(shù)終極揭秘：進程被殺底層原理、APP應(yīng)對被殺技巧》這篇針對所有保活黑科技的總結(jié)性文章）。

隨著Andriod 9.0的到來，基本從系統(tǒng)上堵死了各種?；詈诳萍嫉幕盥罚ㄔ斠姟禔ndroid P正式版即將到來：后臺應(yīng)用保活、消息推送的真正噩夢》），各Android廠商的ROOM系統(tǒng)級推送通道也應(yīng)運而生——華為推送、小米推送、魅族推送、OPPO推送、vivo推送，一時間從用戶的噩夢（?；詈诳萍紝τ脩衾_很大）變成了開發(fā)者的惡夢并持續(xù)至今（想要做好IM離線推送，如今的IM開發(fā)者們不得不一家家對接各手機廠商的離線推送，你說煩不煩）。

也別跟我說為什么不用Android官方的FCM服務(wù)（在國內(nèi)這鏈接你能打開算我輸，至于為什么，你懂的。。。），也別我跟提那個統(tǒng)一推送聯(lián)盟（4、5年過去了，看樣子還要繼續(xù)等下去）。

于是，為了繼續(xù)搞定離線消息推送，IM的開發(fā)者們目前只有兩條路可選：

• 1）舉白旗向系統(tǒng)投降，放棄?；詈诳萍?，直接引導(dǎo)用戶手動加白名單（詳見《Android?；顝娜腴T到放棄：乖乖引導(dǎo)用戶加白名單吧》）；

• 2）一家一家對接各廠商的系統(tǒng)級推送通道（華為、小米、魅族、OPPO、vivo，悲劇的是，有些小眾廠商并沒自建推送的能力）。

隨著Android系統(tǒng)對于開發(fā)者保活黑科技的“堵”，手機廠商們搞出自家的系統(tǒng)級推送通道來“疏”，也算是理所當(dāng)然。而這些廠商之中，vivo的系統(tǒng)級推送通道出現(xiàn)的算是比較晚的。

本篇文章的余下技術(shù)內(nèi)容，算是目前為止首次由手機廠商分享的自建系統(tǒng)級推送平臺的技術(shù)細(xì)節(jié)，我們一起來學(xué)習(xí)。

5、從技術(shù)角度了解推送平臺

推送平臺是做什么的？

從技術(shù)的角度上來看，推送平臺就是一個通過TCP長連接，將消息發(fā)送給用戶的平臺。所以推送平臺的本質(zhì)其實就是借助網(wǎng)絡(luò)通道，將消息發(fā)送到用戶設(shè)備上。

大家日常都收到過快遞通知吧！當(dāng)快遞員將快遞放到快遞柜中，快遞后臺就會自動推送一條消息，通知你有快遞。我相信，如果你是一位運營人員，你也會喜歡這種自動下發(fā)消息高效的方式。

大家感興趣的，可以通過vivo開放平臺入口，選擇消息推送來更進一步了解更多技術(shù)細(xì)節(jié)，這里就不做展開了。

6、短連接與長連接

消息推送平臺的本質(zhì)，就是通過長連接將內(nèi)容、服務(wù)、用戶連在一起，將內(nèi)容分發(fā)給用戶，為終端設(shè)備提供實時、雙向通信能力。

這里有個概念長連接，那么什么是長連接？

所謂的長連接就是：客戶端與服務(wù)端維持的一條、在相對較長的時間里、都能夠進行網(wǎng)絡(luò)通信的網(wǎng)絡(luò)連接（比如：基于TCP的長連接）。

為什么我們要采用長連接而不是短連接作為平臺底層的網(wǎng)絡(luò)通信？

先來看看短連接下消息下發(fā)的場景：使用短連接的方式就是輪詢，即客戶端定時的去詢問后臺有沒有設(shè)備A的消息，當(dāng)有設(shè)備A的消息時后臺返回對應(yīng)的消息，可能很多情況下都是無功而返，浪費流量。當(dāng)后臺有消息需要發(fā)送給設(shè)備A時，因為設(shè)備A沒有過來取導(dǎo)致消息無法下發(fā)。

而使用長連接：當(dāng)有設(shè)備A的消息時后臺直接發(fā)送給設(shè)備A而不用等設(shè)備A自己過拉取，所以長連接讓數(shù)據(jù)交互更加自然、高效。

7、業(yè)務(wù)需求驅(qū)動架構(gòu)升級

對于系統(tǒng)的技術(shù)架構(gòu)來說，它是動態(tài)的，不同階段都可能會發(fā)生變化。而推動架構(gòu)進行演進的推力，主要來自于業(yè)務(wù)需求，一起來回顧，平臺的業(yè)務(wù)發(fā)展歷程。

自2015年立項以來，隨著業(yè)務(wù)量增長，不斷為系統(tǒng)添加功能特性，豐富整個系統(tǒng)的能力使其滿足不同的業(yè)務(wù)場景需求。比如支持內(nèi)容完全審核、支持IM、支持IoT、支持WebSocket 通信等。

從圖上可以看到，業(yè)務(wù)量幾乎每年都有幾十億的增長，不斷攀高，給系統(tǒng)帶來了挑戰(zhàn)，原有的系統(tǒng)架構(gòu)存在的問題，也逐漸浮出水面，比如延遲、性能瓶頸。

架構(gòu)服務(wù)于業(yè)務(wù)，2018年之前我們平臺所有服務(wù)都放在云上，但是依賴的其他內(nèi)部業(yè)務(wù)部署在自建機房。

隨著業(yè)務(wù)量增長與自建機房的數(shù)據(jù)傳輸，已經(jīng)出現(xiàn)了延遲的問題，并且在逐漸惡化，不利于我們平臺功能的拓展。

所以在2018年下半年，我們對部署架構(gòu)進行調(diào)整：將所有核心邏輯模塊都遷移到自建機房，架構(gòu)優(yōu)化之后，數(shù)據(jù)延遲問題得到徹底解決，同時也為架構(gòu)進一步演進奠定了基礎(chǔ)。從上面的圖中可以看到我們接入網(wǎng)關(guān)也進行優(yōu)化三地部署。

為什么要進行三地部署而不是更多區(qū)域部署呢？

主要基于以下三點考慮：

• 1）第一是基于用戶分布及成本的考慮；

• 2）第二是能為用戶提供就近接入；

• 3）第三是能夠讓接入網(wǎng)關(guān)具備一定容災(zāi)能力。

大家可以設(shè)想下，如果沒有三地部署，接入網(wǎng)關(guān)機房故障時，那么平臺就癱瘓了。

隨著平臺業(yè)務(wù)規(guī)模的進一步擴大，日吞吐量達到10億的量級，用戶對于時效性、并發(fā)要求越來越高。而2018年的邏輯服務(wù)的系統(tǒng)架構(gòu)已經(jīng)無法業(yè)務(wù)高并發(fā)的需求或者需要更高的服務(wù)器成本才能滿足高并發(fā)需求。

所以從平臺功能、成本優(yōu)化出發(fā)，在2019年對系統(tǒng)進行了重構(gòu)，為用戶提供更加豐富的產(chǎn)品功能及更穩(wěn)定、更高性能的平臺。

8、利用長連接能力給更多業(yè)務(wù)賦能

作為公司較大規(guī)模的長連接服務(wù)平臺，團隊積累了非常豐富的長連接經(jīng)驗。我們也一直在思考，如何讓長連接能力為更多業(yè)務(wù)賦能。

我們平臺服務(wù)端各個模塊之間通過RPC調(diào)用，這是一種非常高效的開發(fā)模式，不用每個開發(fā)人員都去關(guān)心底層網(wǎng)絡(luò)層數(shù)據(jù)包的。

我們設(shè)想一下，如果客戶端也能通過RPC調(diào)用后臺，這一定是非常棒的開發(fā)體驗。

未來我們將會提供VRPC通信框架，用于解決客戶端與后臺通信及開發(fā)效率問題，為客戶端與后臺提供一致的開發(fā)體驗，讓更多的開發(fā)人員不再關(guān)心網(wǎng)絡(luò)通信問題，專心開發(fā)業(yè)務(wù)邏輯。

作為一個吞吐量超過百億的推送平臺其穩(wěn)定性、高性能、安全都非常重要，接下來和大家分享，我們在系統(tǒng)穩(wěn)定性、高性能、安全方面的實踐經(jīng)驗。

9、vivo推送平臺的領(lǐng)域模型

從上圖的領(lǐng)域模型可以看出，推送平臺以通信服務(wù)作為核心能力，在核心能力的基礎(chǔ)上我們又提供了，大數(shù)據(jù)服務(wù)以及運營系統(tǒng)，通過不同接口對外提供不同的功能、服務(wù)。

以通信服務(wù)為核心的推送平臺，其穩(wěn)定性和性能都會影響消息的時效性。

消息的時效性是指，消息從業(yè)務(wù)方發(fā)起用設(shè)備收到的耗時。

那么如何衡量消息的時效性呢？我們繼續(xù)往下看。

10、如何實現(xiàn)消息時效性的監(jiān)控與質(zhì)量度量？

傳統(tǒng)的消息時效性測量方法如上圖左所示：發(fā)送端和接收端在兩個設(shè)備上，在發(fā)送的時候取時間t1、在接收到消息的時候取時間t2，這兩個時間相減得到消息的耗時。

但是這種方法并不嚴(yán)謹(jǐn)，為什么呢？因為這兩個設(shè)備的時間基準(zhǔn)，很有可能是不一致的。

我們采用的解決方案如上圖右圖所示：將發(fā)送端和接收端放在同一個設(shè)備上，這樣就可以解決時間基準(zhǔn)的問題。我們就是基于該方案，搭建了一套撥測系統(tǒng)，來主動監(jiān)控消息送達耗時分布。

11、如何實現(xiàn)高性能、穩(wěn)定的長連接網(wǎng)關(guān)？

過去10年討論單機長連接性能時面對的是單機一萬連接的問題（C10K問題），而作為一個上億級設(shè)備同時在線的平臺，我們要面對的是單機100萬連接的問題。

作為長連接網(wǎng)關(guān)，主要職責(zé)是維護與設(shè)備端的TCP連接及數(shù)據(jù)包轉(zhuǎn)發(fā)。

對于長連接網(wǎng)關(guān)：我們應(yīng)該盡可能使其輕量化。

我們從以下幾方面進行了自上而下的重構(gòu)優(yōu)化：

• 1）架構(gòu)設(shè)計；

• 2）編碼；

• 3）操作系統(tǒng)配置；

• 4）硬件特性配置。

具體的實施方法，比如：

• 1）調(diào)整系統(tǒng)最大文件句柄數(shù)、單個進程最大的文件句柄數(shù)；

• 2）調(diào)整系統(tǒng)網(wǎng)卡軟中斷負(fù)載均衡或者開啟網(wǎng)卡多隊列、RPS/RFS；

• 3）調(diào)整TCP相關(guān)參數(shù)比如keepalive(需要根據(jù)宿主機的session時間進行調(diào)整）、關(guān)閉timewait recycles；

• 4）硬件上使用AES-NI指令加速數(shù)據(jù)的加解密。

經(jīng)過我們優(yōu)化之后，線上8C32GB 的服務(wù)器可以穩(wěn)定支持170萬的長連接。

另外一大難點在于連接?；睿阂粭l端到端的 TCP連接，中間經(jīng)過層層路由器、網(wǎng)關(guān)，而每個硬件的資源都是有限的，不可能將所有TCP連接狀態(tài)都長期保存。

所以為了避免TCP資源，被中間路由器回收導(dǎo)致連接斷開，我們需要定時發(fā)送心跳請求，來保持連接的活躍狀態(tài)（為什么TCP有這樣的問題？有興趣可以讀這兩篇：《為什么說基于TCP的移動端IM仍然需要心跳保活？》、《徹底搞懂TCP協(xié)議層的KeepAlive?；顧C制》）。

心跳的發(fā)送頻率多高才合適？發(fā)送太快了會引起功耗、流量問題，太慢了又起不到效果，所以為了減少不必要的心跳及提升連接穩(wěn)定性，我們采用智能心跳，為不同網(wǎng)絡(luò)環(huán)境采用差異性的頻率。

有關(guān)長連接心跳機制的更詳細(xì)資料，可以參閱：

• 《手把手教你用Netty實現(xiàn)網(wǎng)絡(luò)通信程序的心跳機制、斷線重連機制》

• 《一文讀懂即時通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機制：作用、原理、實現(xiàn)思路等》

• 《移動端IM實踐：實現(xiàn)Android版微信的智能心跳機制》

• 《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》

• 《一種Android端IM智能心跳算法的設(shè)計與實現(xiàn)探討（含樣例代碼）》

• 《正確理解IM長連接、心跳及重連機制，并動手實現(xiàn)》

• 《萬字長文：手把手教你實現(xiàn)一套高效的IM長連接自適應(yīng)心跳?；顧C制》

• 《Web端即時通訊實踐干貨：如何讓你的WebSocket斷網(wǎng)重連更快速？》

12、如何實現(xiàn)億級設(shè)備的負(fù)載均衡？

我們平臺超過億級設(shè)備同時在線，各個設(shè)備連接長連接網(wǎng)關(guān)時是通過流量調(diào)度系統(tǒng)進行負(fù)載均衡的。

當(dāng)客戶端請求獲取IP時，流量調(diào)度系統(tǒng)會下發(fā)多個就近接入網(wǎng)關(guān)IP：

那么調(diào)度系統(tǒng)是如何確保下發(fā)的ip是可用的呢？大家可以簡單思考下。

對于我來來說，我們采用四種策略：

• 1）就近接入 ；

• 2）公網(wǎng)探測 ；

• 3）機器負(fù)載；

• 4）接口成功率。

到底采用這幾種策略呢？大家可以想下，這兩個問題：

• 1）內(nèi)網(wǎng)正常，公網(wǎng)就一定能聯(lián)通嗎？

• 2）連接數(shù)少服務(wù)器，就一定是可用的嗎？

答案是否定的，因為長連接網(wǎng)關(guān)與流量調(diào)度系統(tǒng)是通過內(nèi)網(wǎng)進行心跳保活的，所以在流量調(diào)度系統(tǒng)上看到的長連接網(wǎng)關(guān)是正常的，但是很有可能長連接網(wǎng)關(guān)公網(wǎng)連接是異常的比如沒有開通公網(wǎng)權(quán)限等。

所以我們需要結(jié)合多種策略，來評估節(jié)點的可用性，保障系統(tǒng)的負(fù)載均衡、為系統(tǒng)穩(wěn)定性提供保障。

13、如何滿足高并發(fā)需求？

有這么一個場景：以每秒1000的推送速度，將一條新聞發(fā)送給幾億用戶，那么有的用戶可能是幾天后才收到這條消息，這就非常影響用戶體驗，所以高并發(fā)對消息的時效性來說是非常重要的。

從上圖的推送流程來看：會不會覺得TiDB會成為推送的性能瓶頸？

其實不會：初步看可能會覺得它們作為中心存儲，但因為我們采用分布式緩存，將中心存儲的數(shù)據(jù)，根據(jù)一定的策略緩存到各個業(yè)務(wù)節(jié)點，充分利用服務(wù)器資源，提升系統(tǒng)性能、吞吐量。我們線上的分布式緩存命中率99.9% 為中心存儲擋住了絕大部分請求，即使TiDB短時間故障，對我們影響也比較小。

14、如何保障系統(tǒng)穩(wěn)定性？

14.1 概述

作為推送平臺，平臺的流量主要分為外部調(diào)用及內(nèi)部上下游之間的調(diào)用。它們大幅波動都會影響系統(tǒng)的穩(wěn)定性，所以需要進行限流、控速，保障系統(tǒng)穩(wěn)定運行。

14.2 推送網(wǎng)關(guān)限流

推送網(wǎng)關(guān)作為流量入口，其穩(wěn)定性非常重要。

要讓推送網(wǎng)關(guān)穩(wěn)定運行，我們首先要解決流量均衡的問題即避免流量傾斜的問題。因為流量傾斜之后，很有可能會引起雪崩的情況。

我們是采用輪詢的機制，進行流量的負(fù)載均衡，來避免流量傾斜問題。

但是這里有兩個前提條件：

• 1）所有推送網(wǎng)關(guān)節(jié)點，服務(wù)器配置要保持一致，否則很有可能會因為某個處理能力不足導(dǎo)致過載問題；

• 2）應(yīng)控制流入我們系統(tǒng)的并發(fā)量，避免流量洪峰穿透推送網(wǎng)關(guān)導(dǎo)致后端服務(wù)過載。

我們采用的是令牌桶算法，控制每個推送網(wǎng)關(guān)投放速度，進而能夠?qū)ο掠喂?jié)點起到保護作用。

那么令牌數(shù)量設(shè)置多少才合適呢？設(shè)置低了，下游節(jié)點資源不能充分利用；設(shè)置太高了，下游節(jié)點有可能扛不住。

我們可以采用主動+被動的動態(tài)調(diào)整的策略：

• 1）當(dāng)流量超過下游集群處理能力時，通知上游進行限速；

• 2）當(dāng)調(diào)用下游接口超時，達到一定比例是進行限流。

14.3 系統(tǒng)內(nèi)部限速：標(biāo)簽推送平滑下發(fā)

既然推送網(wǎng)關(guān)已經(jīng)限流了，為什么內(nèi)部節(jié)點之間還要限速？

這個是由于我們平臺的業(yè)務(wù)特點決定的，平臺支持全量、標(biāo)簽推送，要避免性能較好的模塊，把下游節(jié)點資源耗盡的情況。

標(biāo)簽推送模塊（提供全量、標(biāo)簽推送）就是一個性能較高的服務(wù)，為了避免它對下游造成影響。我們基于Redis和令牌桶算法實現(xiàn)了平滑推送的功能，控制每個標(biāo)簽任務(wù)的推送速度，來保護下游節(jié)點。

另外：平臺支持應(yīng)用創(chuàng)建多個標(biāo)簽推送，它們的推送速度會疊加，所以僅控制單個標(biāo)簽任務(wù)的平滑推送是不夠的。需要在推送下發(fā)模塊對應(yīng)用粒度進行限速，避免推送過快對業(yè)務(wù)后臺造成壓力。

14.4 系統(tǒng)內(nèi)部限速：消息下發(fā)時限速發(fā)送

為了實現(xiàn)應(yīng)用級別的限速，我們采用Redis實現(xiàn)分布式漏桶限流的方案，具體方案如上圖所示。

這里我們?yōu)槭裁床捎玫氖莄lientId（設(shè)備唯一標(biāo)識），而不是使用應(yīng)用ID來做一致性hash？主要是為了負(fù)載均衡。

自從實現(xiàn)了這個功能之后，業(yè)務(wù)方再也不用擔(dān)心推送太快，造成自己服務(wù)器壓力大的問題。

?

那么被限速的消息會被丟掉嗎？當(dāng)然不會，我們會將這些消息存儲到本地緩存、并且打散存儲到Redis，之所以需要打散存儲主要是為了避免后續(xù)出現(xiàn)存儲熱點問題。

14.5 熔斷降級

推送平臺，一些突發(fā)事件、熱點新聞會給系統(tǒng)帶來較大的突發(fā)流量。我們應(yīng)該如何應(yīng)對突發(fā)流量呢？

?

如上圖左所示：傳統(tǒng)的架構(gòu)上為了避免突發(fā)流量對系統(tǒng)的沖擊，冗余部署大量機器，成本高、資源浪費嚴(yán)重。在面臨突發(fā)流量時，無法及時擴容，導(dǎo)致推送成功率降低。

我們是怎么做的呢？我們采用增加緩沖通道，使用消息隊列和容器的解決方案（這種方案系統(tǒng)改動?。?。當(dāng)無突發(fā)流量時以較小量機器部署，當(dāng)遇到突發(fā)流量時我們也不需要人工介入，它會根據(jù)系統(tǒng)負(fù)載自動擴縮容。

15、基于Karate的自動化測試系統(tǒng)

在日常開發(fā)中大家為了快速開發(fā)需求，往往忽視了接口的邊界測試，這將會給線上服務(wù)造成很大的質(zhì)量風(fēng)險。

另外，不知道大家有沒有注意到，團隊中不同角色溝通時使用的不同媒介比如使用word、excel、xmind等，會導(dǎo)致溝通的信息出現(xiàn)不同程度折損。

所以為了改善以上問題，我們開發(fā)了一個自動化測試平臺，用于提升測試效率與接口用例覆蓋率，我們采用領(lǐng)域統(tǒng)一的語言減少團隊中不同角色溝通信息折損。另外還可以對測試用例統(tǒng)一集中管理，方便迭代維護。

?

16、內(nèi)容安全

作為推送平臺，當(dāng)然要為內(nèi)容安全把好關(guān)，我們提供了內(nèi)容審計的能力。

審計方法采用自動審核為主、人工審核為輔機制來提升審核效率。同時結(jié)合基于影響面及應(yīng)用分級的策略進行內(nèi)容審計。

從下圖中可以看到業(yè)務(wù)請求經(jīng)過接入網(wǎng)關(guān)轉(zhuǎn)發(fā)給內(nèi)容審系統(tǒng)進行第一層本地規(guī)則的內(nèi)容審計，如果沒有命中本地規(guī)則則調(diào)用我們諦聽系統(tǒng)進行內(nèi)容反垃圾審計。

17、未來規(guī)劃

前面我們主要介紹了推送平臺這幾年的架構(gòu)演進及演進過程中的系統(tǒng)穩(wěn)定性、高性能、安全等方面的技術(shù)實踐，接下來介紹未來的重點工作。

為了提供更易用、更穩(wěn)定、更安全的推送，未來將在以下方面持續(xù)投入建設(shè)：

• 1）在單模塊數(shù)據(jù)一致性的基礎(chǔ)上，實現(xiàn)全系統(tǒng)數(shù)據(jù)一致性；

• 2）將繼續(xù)完善各系統(tǒng)的熔斷降級能力；

• 3）平臺的易用性方面持續(xù)優(yōu)化，提供更加便捷的平臺服務(wù)；

• 4）建設(shè)異常流量識別的能力。

18、演講稿附件下載

本文內(nèi)容對應(yīng)的演講原稿附件下載：

?vivo推送平臺架構(gòu)演進(52im.net).pdf?(1.93 MB )

演講原稿內(nèi)容概覽：

19、參考資料

[1]?Android6.0以下的雙進程守護?；顚嵺`

[2]?Android6.0及以上的?；顚嵺`(進程防殺篇)》

[3]?為何基于TCP協(xié)議的移動端IM仍然需要心跳?；顧C制？

[4]?Android版微信后臺?；顚崙?zhàn)分享(進程?；钇?

[5]?實現(xiàn)Android版微信的智能心跳機制

[6]?Android P正式版即將到來：后臺應(yīng)用保活、消息推送的真正噩夢

[7]?融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路保活技術(shù)實踐

[8]?正確理解IM長連接的心跳及重連機制，并動手實現(xiàn)

[9]?史上最強Android?；钏悸罚荷钊肫饰鲵v訊TIM的進程永生技術(shù)

[10]?Android進程永生技術(shù)終極揭秘：進程被殺底層原理、APP對抗被殺技巧

[11]?Web端即時通訊實踐干貨：如何讓你的WebSocket斷網(wǎng)重連更快速？

（本文已同步發(fā)布于：http://www.52im.net/thread-4008-1-1.html）