社交軟件紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐
1、引言
2020年春節早已過去兩月有餘，回顧本次騰訊手Q春節紅包活動的玩法，主要以答題形式結合中國傳統文化（成語、詩詞、對聯、歷史等）的方式進行，達到寓教於樂的效果。php
▲ 2020年春節QQ的紅包活動html
對於這種大致量的IM社交應用運營活動，技術上除了前端、後臺的大力支撐，對於手Q客戶端來講，又是從哪些方面來保證整個紅包活動的靈活性、穩定性和用戶體驗的呢？帶着這個問題，咱們一塊兒來閱讀餘下的文字。前端
學習交流：程序員
- 即時通信/推送技術開發交流5羣：215477170[推薦]算法
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》數據庫
（本文同步發佈於：http://www.52im.net/thread-2966-1-1.html）小程序
2、內容概述
本文將回顧今年的春節紅包活動中，針對手Q客戶端在活動配置、錯峯、數據上報、資源預下載和柔性策略五個方面進行探討和總結，但願能和你們在後續春節紅包項目上一塊兒學習交流。微信小程序
具體來講，這些技術手段主要是如下幾個方面的內容：緩存
1）配置：經過配置控制衆多可變參數，靈活應對活動變化安全
2）錯峯：解決活動高峯後臺服務負載太高的問題，新錯峯方案提高用戶感知體驗
3）數據上報：即保證活動數據的及時上報，又避免過分消耗資源
4）資源預下載：解決活動高峯CDN帶寬壓力太高問題的同時，提高用戶體驗；
5）柔性策略：確保活動不會對其它業務產生太大影響。
3、系列文章
❶ 系列文章目錄：
《社交軟件紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實現等》
《社交軟件紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟件紅包技術解密(三)：微信搖一搖紅包雨背後的技術細節》
《社交軟件紅包技術解密(四)：微信紅包系統是如何應對高併發的》
《社交軟件紅包技術解密(五)：微信紅包系統是如何實現高可用性的》
《社交軟件紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》
《社交軟件紅包技術解密(七)：支付寶紅包的海量高併發技術實踐》
❷ 其它相關文章：
4、關於「配置」
整個春節紅包活動是經過全局配置進行控制的，可動態修改，以靈活應對活動的變動。根據產品需求，結合需求變動的可能性，以及通用能力的可複用性，本次春節紅包總共定義了四份配置。
1）入口配置：
包含活動入口吊墜、小程序入口Banner和一些控制開關等配置內容。春節紅包活動橫跨小年、除夕、大年初一，天天有4場答題活動，有些場次爲商家專場，所以入口配置中提早以列表形式定義好了各天各場次的具體活動信息。
2）大插屏配置：
包含活動預熱大插屏的配置內容，因爲剛開始時需求的不肯定性，獨立出來做爲一份配置，後來還增長了分會場呼吸燈的配置內容。
3）錯峯配置：
包含本次春節紅包活動客戶端錯峯方案的配置內容，獨立配置，可供手Q其它通用運營業務複用。
4）預下載配置：
包含春節紅包活動客戶端須要提早預下載的資源配置內容，本次活動資源預覆蓋接入使用了QQ錢包業務搭建的資源預下載系統，所以配置參照了QQ錢包預下載系統制定的格式。
5、關於「錯峯」
5.一、以往春節紅包活動的錯峯方案
錯峯，目的是爲了解決春節紅包活動高峯對抽獎後臺負載帶來瞬間衝擊的問題。以往春節紅包活動的錯峯方案，主要有如下兩種。
1）經過客戶端緩衝過程，控制對抽獎後臺的請求：
經過控制參與抽獎的頻率、限制抽獎的次數等方式來進行錯峯，如搖一搖、刷一刷等。
2）經過對活動入口隨機時間錯峯顯示，控制對抽獎後臺的請求：
將全部用戶隨機均勻地映射到活動開始後的一段時間區間內，使用戶錯峯顯示入口進入參與活動，如2019年春節的福袋。錯峯時間的算法形如：hash(uin) % gap。
5.二、咱們使用的錯峯方案
上節提到的兩種錯峯方式，第二種與本次春節紅包活動場景是比較吻合的。
不過，該方案存在一個問題：因爲其隨機性，使得有用戶反饋身邊其餘人都能看到活動入口參與抽獎了，而本身卻一直看不到入口。
針對方案二的問題，咱們引入了用戶地理位置的因素進行改進，下圖描述了整體錯峯方案：
具體方案實現流程以下：
首先，咱們定義了一份錯峯配置，包含錯峯時間間隔和區域劃分列表，將全國用戶根據地理位置adcode劃分爲多個區域批次。
對處於同一批次的用戶，他們看到活動入口的時間段是同樣的。假設配置活動的開始時間爲9:00，錯峯時間間隔爲1分鐘，那麼第一批用戶能看到入口的時間爲9:00~9:01，第二批用戶能看到入口的時間爲9:01~9:02，以此類推。
主要流程以下：
1）根據用戶地理位置adcode和錯峯配置進行映射，獲得映射後的分區索引i；
2）計算獲得一次錯峯時間：T1 = T0 + i*interval；
3）對於同一批次的用戶，經過隨機時間，將這些用戶隨機均勻地映射分佈到對應較小的時間段內，計算獲得二次錯峯時間：T2 = T1 + hash(uin)%interval；
4）獲得的二次錯峯時間T2即爲用戶實際能夠看到入口參與活動的時間：T = T2；
5）對於地理位置一次錯峯可能出現的異常狀況，如用戶未受權獲取地理位置（佔比30%左右）、國外用戶無adcode未匹配到分區索引等，客戶端可採起必定的兜底策略，如根據用戶帳號uin進行隨機映射到某個分區：i = hash(uin) % regions.count 。
該錯峯方案實現時抽離了業務依賴，並走獨立配置，可供其它通用性運營業務複用。
同時，該錯峯方案還申請了專利，如下是專利信息：
6、關於「數據上報」
6.一、意義
春節紅包的數據，不只是衡量活動運營的質量指標，還會影響到活動的招商。經過對數據進行監控，產品同窗能夠根據實際活動狀況調整產品策略，開發同窗能夠及時發現並定位問題。同時，數據仍是申請活動資源的重要依據。
6.二、核心訴求
春節紅包這種大型全民活動的數據，主要具備上報數據量大、上報併發高、上報場景多樣的特色。
對於春節紅包數據上報，主要有三方面的核心訴求：
1）數據可以及時上報（實時性需求）；
2）避免爲及時上報而致使資源的過分消耗（如客戶端性能、網絡開銷；後臺性能、擴容資源等）；
3）確保上報服務的穩定可用（要有可調整和容錯的能力）。
6.三、爲什麼不使用現有的數據上報
爲何不直接使用手Q現有的數據上報系統呢？
主要是基於以下幾方面的考慮：
1）可能影響其它長期運營的正常業務；
2）定製化成本高（上報後臺須要作一些秒級監控、UV統計等定製邏輯）；
3）上報控制不夠靈活、生效慢（經過配置控制上報邏輯，調整後配置覆蓋須要必定時間才能所有生效）；
4）人力、溝通成本等其它方面的考慮。
6.四、春節紅包數據上報
針對春節紅包數據的特色及核心訴求，咱們設計了本次春節紅包數據上報方案。
6.4.1 數據上報架構
如上圖所示：
1）調用層：封裝了各上報場景的通用上報能力，經過接口層的統一上報接口將上報數據轉發給邏輯層進行處理。Native、H5均經過原生統一上報接口走SSO通道上報，上報更可靠且無需重複開發；
2）邏輯層：主要包括數據預處理、數據上報策略和容錯機制三部份內容。其中，數據預處理負責對上報的數據進行聚合、過濾和轉換；數據上報策略經過後臺可控的參數來控制數據上報的時機、頻率、大小和存儲，確保數據可以及時上報又不影響客戶端和後臺的性能，並且可以實時動態調整；容錯機制制定了過載策略和降級策略，提供應對上報後臺過載的措施；
3）基礎層：即系統和手Q封裝提供的一些基礎能力，如文件I/O、安全加/解密等。
6.4.2 數據上報的實現流程
如上圖所示：
1）客戶端經過一個串行隊列來處理全部上報的數據，對數據首先會進行聚合、過濾和轉換的預處理，而後將預處理的數據先寫到內存緩存中，當知足保存文件的時機時，再異步寫到磁盤文件中；
2）爲避免頻繁寫文件對CPU、磁盤等帶來的影響，客戶端每隔一段時間寫一次文件；爲防止內存中數據丟失，客戶端在先後臺切換、殺進程、app crash場景下也會保存文件進行補償；
3）當知足上報時機時，會觸發數據上報請求，並清空緩存數據同時保存文件；
4）上報請求回包中帶有上報控制相關信息，提供了靈活調整的能力。
6.五、遇到的問題分析與解決
6.5.1 相同埋點數據增大請求包大小
春節紅包的數據中，有多類埋點數據觸發屢次的狀況（如曝光、點擊等），所以一個上報請求包中可能會存在多條相同的埋點數據，增大了請求包大小。經過對請求包中的數據進行二次聚合（批量上報實際上是對上報請求作了一次聚合），經測試平都可減少請求包大小28%。
另外，針對特定的需求場景，有些數據多是不能聚合的。例如，咱們對於操做時間超過1小時的相同數據是不會進行聚合處理的，由於今年春節活動有場次的概念，每場活動間隔1個小時，產品同窗可能須要以場次維度統計相關數據，若合併可能會干擾數據統計的準確性。
6.5.2 上報請求次數過多
前期演練監控上報請求發現，一場答題活動結束後，客戶端上報的請求次數比預估中的偏多，與抽獎請求的比例超過了2:1（預估上報請求峯值與抽獎請求峯值的比例大約爲5:4）。假如抽獎請求到達到了峯值，那可能上報請求的峯值會更高，須要上報後臺擴容更多的機器。
咱們針對上報請求的top用戶日誌進行分析，發現主要有兩方面緣由：
1）用戶頻繁先後臺切換觸發屢次上報請求：初始先後臺切換上報的頻控時間設置了10s比較短，可能致使用戶屢次觸發只有幾條數據的請求；
2）一些關鍵指標數據（如覆蓋數據）最開始走的是實時上報，會有多個只有一條數據的上報請求。
針對這兩個緣由，咱們採起了相應的措施：
1）調整先後臺切換觸發上報的時間間隔，將秒級改成分鐘級，後臺可控；
2）關鍵指標數據改成批量上報，並經過每日一檢的方式增長觸發時機。
解決以後上報請求數小於抽獎請求數，比例降到了1.0如下。經測試平均單用戶上報請求數下降了71.4%。
6.5.3 關鍵指標數據不許確
針對前期的幾回演練，咱們統計了配置、資源的覆蓋率，發現所獲得的結果與預想中的有些出入。咱們所使用的配置系統是在登陸級別拉取的，下發成功率高於95%，而演練時統計上報數據配置的覆蓋率範圍在80~88%之間，懷疑可能覆蓋上報的數據丟失了。
咱們針對部分有活躍（前臺登陸）但卻沒有覆蓋上報的用戶進行了分析，發現這些用戶確實是拉取到配置並觸發了覆蓋上報，但上報的數據可能丟失了。一方面多是在內存的數據未及時同步到文件中，由於初始設置寫文件的頻率爲每30秒寫一次，時間略長，用戶殺進程或退後臺等操做場景下，內存中的數據可能會丟失；另外一方面也多是網絡緣由致使上報數據的丟失。
針對這兩個緣由，咱們採起的對應措施：
1）縮短保存文件的時間間隔（對多個值測試綜合性能和時間效率考慮取值10秒），後臺可控，並進行多時機補償：包括先後臺切換、殺進程和App Crash三種場景。經測試，對比每次都寫文件，每10秒寫一次文件可以下降對CPU影響66.7%，下降對磁盤的影響87.9%。
2）確保關鍵指標數據上報成功，並過濾冗餘數據：把覆蓋類指標每日一檢的方式改成每次登陸/斷網重連時就觸發覆蓋檢查，並加上必定的頻控，覆蓋檢查得出結果後即上報。當覆蓋數據實際觸發上報到後臺併成功回包後，本地記錄上報的狀態，這樣當下次觸發覆蓋檢查上報前，若判斷該覆蓋數據已上報過，就再也不上報，直接做爲冗餘數據過濾掉。相比每日一檢的方式（天天都會產生多條覆蓋數據上報），這種方式單用戶最多能夠節省93%的覆蓋數據量。
解決後，以後演練的覆蓋類數據恢復了正常，配置覆蓋率在97%~99%之間。
6.六、容錯機制
下圖爲上報數據的流通流程：
在客戶端數據上報到後臺的鏈路中，SSO接入層和上報服務後臺均有過載的風險。針對這兩個風險，咱們分別用過載策略和降級策略來應對。
1）SSO接入層過載：若是SSO接入層過載了，所採用的的過載策略是：由SSO接入層直接回包，客戶端根據過載標記，將批量上報的batchSize值設置爲最大值，並翻倍上報的頻率時間，從而下降客戶端的上報頻率。
2）上報服務後臺過載：針對上報服務後臺過載的狀況，咱們制定了一套降級策略，後臺回包中包含了兩個降級信息：
reportLevel：上報級別，默認爲0
reportLevelTime：上報級別有效時間，當reportLevel>0時有效
咱們設定了4個上報級別，以下圖所示，客戶端根據後臺設置的上報級別，來降級上報服務。若是上報級別設置爲1，則客戶端會將全部實時上報降級爲批量上報；更進一步的，能夠設置上報級別爲2來降級屏蔽非用戶行爲類的數據上報；甚至能夠設置上報級別爲3來屏蔽全部數據的上報。經過上報級別有效時間，來確保客戶端可以恢復正常的上報邏輯。
6.七、可優化點
下圖爲本次春節紅包活動在除夕當天的數據上報請求曲線，實際上報請求峯值爲預估上報請求峯值的13.33%。
從曲線能夠明顯的發現，每場答題活動開始時，數據上報都有一個尖峯，這是由於客戶端未對數據上報進行錯峯引發的。這也是本數據上報方案的可優化點之一，錯峯方式能夠簡單的隨機錯峯上報，亦可參考第二部份內容的錯峯方案。
另外一個可優化的點，咱們在觸發數據上報請求時，能夠帶上觸發上報的時機，這有助於分析用戶觸發數據上報的行爲。
7、關於「資源預下載」
7.一、概述
春節紅包活動不只涉及資源衆多，並且有些資源還比較大。若是這些資源都由客戶端經過實時下載的方式使用，不只會對CDN帶寬形成巨大的壓力，同時也會對用戶參與活動的體驗形成很大的影響。
天然而然想到最常規最有效的解決辦法就是資源預下載。
對於資源預下載的能力，包括但不限於須要考慮如下幾點：
1）資源可以正常預下載到本地；
2）業務接入的開發效率（提供更便捷通用的接口，集成資源判斷、實時下載、資源文件預處理等邏輯）；
3）考慮資源過大時可能引發的CDN帶寬激增問題（須要制定相應的流控方案）；
4）預下載過程不該該影響到其它業務（如手Q啓動時的消息加載、其它業務資源的實時下載等）；
5）資源管理（下載、更新、刪除、防篡改、淘汰機制等）；
6）預下載配置管理（存儲、更新、合併、去重等）；
7）等等...
今年春節紅包活動，接入使用的是QQ錢包業務搭建的資源預下載系統，此處就不深刻詳細介紹，只針對今年春節紅包活動在以下幾個方面內容作討論。
7.二、預下載配置問題
預下載配置爲JSON格式，接入手Q配置系統進行發佈時，須要填寫一份涉及全部預下載資源的配置內容，若是經過人工理解手寫配置，不只易出錯並且效率低下，輕則影響客戶端資源的正常預下載，重則JSON解析處理不當可能會致使app產生崩潰，在春節如此大致量用戶狀況下會形成至關大的影響。
咱們的處理辦法是，由春節紅包活動的管理平臺根據預下載配置的格式，一鍵導出自動生成預下載配置內容，再到配置平臺上發佈。同時，客戶端拉取到預下載配置時，對所拉取的配置內容進行 JSON Schema 校驗，確保這是一個正確的配置後纔會使用。若檢查發現配置格式異常，會馬上上報告警通知相關產品、開發人員，以及時發現配置問題並採起措施修復。
7.三、CDN帶寬預估
春節紅包的資源多且大，要覆蓋全網用戶作資源預下載，須要持續足夠長一段時間。CDN需提早作好資源分配，以知足活動資源覆蓋的帶寬需求。
所以，咱們須要對春節紅包活動的CDN帶寬進行預估：提早多久開始預下載資源？CDN須要分配多少離線帶寬和在線帶寬？
假設咱們提早D天下發了預下載配置。
1）離線帶寬的預估：
離線帶寬資源的分配，要能知足全部用戶可以在D天時間內，都能順利預下載下來全部資源。假設手Q總用戶數爲N，須要預下載的離線資源總大小爲M千字節（KB），那麼能夠估算出全部用戶預下載全部離線資源的總流量（單位：bit）:
預下載的總流量 = M * 1024 * 8 * N
也就是說D天時間要下載這麼多流量的資源，經過一個估算係數C，預估出離線帶寬值（單位：Gbps）：
離線帶寬 = 預下載的總流量 * C / ( D * 86400 * 1024 * 1024 * 1024 )= ( M * 8 * N ) * C / ( D * 86400 * 1024 * 1024 )
2）在線帶寬的預估：
在線帶寬資源的分配，取決於活動期間資源實時下載預估能達到的峯值。咱們針對活動所涉及的全部資源，根據資源使用入口級別將其分爲了4個資源等級，不一樣級別的資源其請求峯值是不同的。
根據各活動入口的預估峯值，以及演練時的轉化率數據，得出各級別資源的峯值，另外還須要考慮資源預下載的影響，從而估算出在線帶寬。
對於每一個資源, 假設其在線資源大小爲R千字節（KB），該資源預計峯值爲PW/s，資源預下載覆蓋率取90%的話，那麼該資源的在線帶寬峯值爲（單位：Gpbs）：
在線帶寬 = ( R * 1024 * 8 ) * ( P * 10000 * 0.1 ) / (1024 * 1024 * 1024)
7.四、覆蓋率&命中率
預下載支持配置網絡參數，來控制當前資源在什麼樣的網絡環境下才會去預下載。春節紅包整體資源較大，咱們配置了全部資源只在Wifi網絡環境下才預下載，防止消耗用戶的手機流量。所以，咱們整體資源的覆蓋率不是過高，由於還有很多佔比用戶的聯網狀態是非Wifi的。
固然，覆蓋率只是衡量預下載功能的一個指標，另外一個重要指標是資源預下載的命中率。命中，表示用戶在使用某個資源時，是否命中了本地預下載的資源。咱們在用戶進入主活動入口的時機，增長了資源的命中檢查：若是該用戶進入主活動頁面時，預下載配置中的全部資源都提早預下載到本地了，即認爲命中，不然認爲不命中，以活動當天首次進入爲準。經上報統計，本次春節紅包的資源預下載命中率超過90%。
理想的狀況下，預下載要能達到以較低的覆蓋率得到較高的命中率的效果最佳，這說明大部分參與活動的用戶基本都覆蓋到了全部資源，是咱們的目標用戶。所以，對於目標用戶比較明確的業務，能夠經過白名單方式來控制預下載配置只針對目標用戶進行下發。
8、關於「柔性策略」
春節紅包活動在手Q消息列表處設置了吊墜入口，且活動主要是以H5頁面的方式進行的，對手Q可能會產生以下三方面的影響。
1）對下拉消息列表刷新消息的影響：
基於用戶對之前手Q春節紅包的認知，在春節紅包活動開始以前，有些用戶會習慣性地去下拉消息列表尋找活動入口，另外分會場設置的呼吸燈也會引導用戶下拉消息列表。這個行爲會觸發拉取離線消息，在活動高峯時給消息後臺帶來額外的壓力。
爲消除對下拉消息列表刷新消息的影響，咱們在每場活動開始時的先後一段時間內以及呼吸燈第一次展現後的一段時間內，禁止用戶刷新消息，在視覺上仍然有一個假刷新消息的過程，但實際不會觸發拉取離線消息的請求。經過在配置中添加禁刷開關和禁刷時間來進行控制，可靈活調整。
這裏有個細節，咱們將活動開始先後的禁刷時間分開控制，防止禁刷時間段過長，下降春節紅包活動禁刷消息對正常離線消息拉取的影響。
2）對url安全檢查的影響：
在手Q中打開一個H5頁面，WebView會對頁面url攔截進行url安全檢查，只有經過檢查後才能繼續加載頁面內容。本次春節紅包活動主要以H5方式進行，有較多的url連接，若是都進行安全檢查的話，在活動高峯會給檢查後臺增長較大的壓力。
爲消除對檢查後臺的影響，採起的措施是針對全部春節紅包活動的頁面屏蔽url安全檢查。經過在配置中添加url安全檢查開關和url前綴列表來進行控制，全部活動頁面的url走內部域名。另外，屏蔽url安全檢查在必定程度上還能夠加快活動頁面的加載速度，弱網環境下會更加明顯。
3）對離線包更新檢查的影響：
本次春節紅包活動的大部分頁面均支持離線包，在使用WebView打開支持離線包頁面時，會觸發離線包的異步更新檢查，在活動高峯期一樣會給離線包後臺增長不小的壓力。
消除該影響的辦法，是在全部支持離線包頁面的url中，增長一個開關參數，客戶端判斷若帶有該參數，則直接屏蔽離線包的更新檢查。
那若是活動期間，前端頁面發了新版本的離線包，客戶端要怎麼更新呢？咱們設計了一套按需更新的方案，大體思路是：在進入主活動頁面時，頁面會拉取一份離線包版本配置，並檢查本地離線包版本與配置中指定的版本是否一致，若不一致則觸發更新檢查，觸發方式爲發起一個不帶屏蔽開關參數的資源請求，請求目標對象爲一個1字節的文件或1像素的圖片。
9、寫在最後
2020春節紅包歷時近4個月，通過屢次演練、迭代、優化，團隊全部成員在產品體驗、開發細節、測試場景等方面不斷打磨。
在全程參與這種大型全民運營活動的過程當中，感覺頗深的是，在設計或實現某個看似簡單的功能時，必定要多系統性地思考，儘可能作到有依有據，考慮到各方各面。遇到哪怕看似再小的問題時，也要重視，尋其根因。
（—— 全文完 ——）
附錄：有關微信、QQ的技術文章彙總
《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(圖片壓縮篇)》
《騰訊技術分享：騰訊是如何大幅下降帶寬和網絡流量的(音視頻技術篇)》
《騰訊技術分享：Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享：iOS版微信的高性能通用key-value組件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字符致使的炸羣、APP崩潰的？》
《騰訊技術分享：Android手Q的線程死鎖監控系統技術實踐》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖片壓縮技術詳解（下篇）》
《騰訊團隊分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視頻編碼填過的那些坑》
《微信團隊披露：微信界面卡死超級bug「15。。。。」的前因後果》
《月活8.89億的超級IM微信是如何進行Android端兼容測試的》
《微信客戶端團隊負責人技術訪談：如何着手客戶端性能監控和優化》
《微信團隊原創分享：Android版微信的臃腫之困與模塊化實踐之路》
《微信團隊原創分享：微信客戶端SQLite數據庫損壞修復實踐》
《騰訊原創分享(一)：如何大幅提高移動網絡下手機QQ的圖片傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《如約而至：微信自用的移動端IM網絡層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機千萬鏈接、支撐微信8億用戶的後臺框架基石 [源碼下載]》
《微信新一代通訊安全解決方案：基於TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信後臺保活實戰分享(進程保活篇)》
《微信團隊原創分享：Android版微信後臺保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載]》
《微信海量用戶背後的後臺系統存儲架構(視頻+PPT) [附件下載]》
《微信異步化改造實踐：8億月活、單機千萬鏈接背後的後臺解決方案》
《架構之道：3個程序員成就微信朋友圈日均10億發佈量[有視頻]》
《微信團隊原創分享：Android內存泄漏監控和優化技巧總結》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《移動端IM實踐：Android版微信如何大幅提高交互性能（一）》
《移動端IM實踐：Android版微信如何大幅提高交互性能（二）》
《移動端IM實踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《信鴿團隊原創：一塊兒走過 iOS10 上消息推送(APNS)的坑》
《騰訊TEG團隊原創：基於MySQL的分佈式數據庫TDSQL十年鍛造經驗分享》
《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》
《瞭解iOS消息推送一文就夠：史上最全iOS Push技術詳解》
《騰訊資深架構師乾貨總結：一文讀懂大型分佈式系統設計的方方面面》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》
《手把手教你讀取Android版微信和手Q的聊天記錄(僅做技術研究學習)》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術分享：微信的海量IM聊天消息序列號生成實踐（容災方案篇）》
《騰訊技術分享：GIF動圖技術詳解及手機QQ動態表情壓縮技術實踐》
《微信團隊分享：Kotlin漸被承認，Android版微信的技術嚐鮮之旅》
《QQ設計團隊分享：新版 QQ 8.0 語音消息改版背後的功能設計思路》
《微信團隊分享：極致優化，iOS版微信編譯速度3倍提高的實踐總結》
《IM「掃一掃」功能很好作？看看微信「掃一掃識物」的完整技術實現》
《微信團隊分享：微信支付代碼重構帶來的移動端軟件架構上的思考》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-2966-1-1.html）
- 1. 社交軟件紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐
- 2. 架構17 社交軟件紅包技術10
- 3. 架構15 社交軟件紅包技術08
- 4. 架構11 社交軟件紅包技術03
- 5. 架構11 社交軟件紅包技術04
- 6. 架構16 社交軟件紅包技術09
- 7. 架構12 社交軟件紅包技術05
- 8. 架構10 社交軟件紅包技術02
- 9. QQ紅包技術方案全解密
- 10. 春節紅包
- 更多相關文章...
- • XML 相關技術 - XML 教程
- • Hibernate的快照技術 - Hibernate教程
- • Docker容器實戰(一) - 封神Server端技術
- • 三篇文章瞭解 TiDB 技術內幕——說存儲
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 字節跳動21屆秋招運營兩輪面試經驗分享
- 2. Java 3 年，25K 多嗎？
- 3. mysql安裝部署
- 4. web前端開發中父鏈和子鏈方式實現通信
- 5. 3.1.6 spark體系之分佈式計算-scala編程-scala中trait特性
- 6. dataframe2
- 7. ThinkFree在線
- 8. 在線畫圖
- 9. devtools熱部署
- 10. 編譯和鏈接
- 1. 社交軟件紅包技術解密(十)：手Q客戶端針對2020年春節紅包的技術實踐
- 2. 架構17 社交軟件紅包技術10
- 3. 架構15 社交軟件紅包技術08
- 4. 架構11 社交軟件紅包技術03
- 5. 架構11 社交軟件紅包技術04
- 6. 架構16 社交軟件紅包技術09
- 7. 架構12 社交軟件紅包技術05
- 8. 架構10 社交軟件紅包技術02
- 9. QQ紅包技術方案全解密
- 10. 春節紅包