一、引言
2020年春節早已過去兩月有餘，回顧本次騰訊手Q春節紅包活動的玩法，主要以答題形式結合中國傳統文化（成語、詩詞、對聯、曆史等）的方式進行，達到寓教于樂的效果。
▲ 2020年春節QQ的紅包活動
對于這種大體量的IM社交應用營運活動，技術上除了前端、背景的大力支撐，對于手Q用戶端來說，又是從哪些方面來保證整個紅包活動的靈活性、穩定性和使用者體驗的呢？帶着這個問題，我們一起來閱讀餘下的文字。
學習交流：
- 即時通訊/推送技術開發交流5群：215477170[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
（本文同步釋出于：http://www.52im.net/thread-2966-1-1.html）
二、内容概述
本文将回顧今年的春節紅包活動中，針對手Q用戶端在活動配置、錯峰、資料上報、資源預下載下傳和柔性政策五個方面進行探讨和總結，希望能和大家在後續春節紅包項目上一起學習交流。
具體來說，這些技術手段主要是以下幾個方面的内容：
1）配置：通過配置控制衆多可變參數，靈活應對活動變化
2）錯峰：解決活動高峰背景服務負載過高的問題，新錯峰方案提升使用者感覺體驗
3）資料上報：即保證活動資料的及時上報，又避免過度消耗資源
4）資源預下載下傳：解決活動高峰CDN帶寬壓力過高問題的同時，提升使用者體驗；
5）柔性政策：確定活動不會對其它業務産生太大影響。
三、系列文章
❶ 系列文章目錄：
《社交軟體紅包技術解密(一)：全面解密QQ紅包技術方案——架構、技術實作等》
《社交軟體紅包技術解密(二)：解密微信搖一搖紅包從0到1的技術演進》
《社交軟體紅包技術解密(三)：微信搖一搖紅包雨背後的技術細節》
《社交軟體紅包技術解密(四)：微信紅包系統是如何應對高并發的》
《社交軟體紅包技術解密(五)：微信紅包系統是如何實作高可用性的》
《社交軟體紅包技術解密(六)：微信紅包系統的存儲層架構演進實踐》
《社交軟體紅包技術解密(七)：支付寶紅包的海量高并發技術實踐》
《社交軟體紅包技術解密(八)：全面解密微網誌紅包技術方案》
《社交軟體紅包技術解密(九)：談談手Q春節紅包的設計、容災、運維、架構等》
《社交軟體紅包技術解密(十)：手Q用戶端針對2020年春節紅包的技術實踐》（* 本文）
❷ 其它相關文章：
《技術往事：“QQ群”和“微信紅包”是怎麼來的？》
《QQ 18年：解密8億月活的QQ背景服務接口隔離技術》
《微信“紅包照片”背後的技術難題》
四、關于“配置”
整個春節紅包活動是通過全局配置進行控制的，可動态修改，以靈活應對活動的變更。根據産品需求，結合需求變更的可能性，以及通用能力的可複用性，本次春節紅包總共定義了四份配置。
1）入口配置：
包含活動入口吊墜、小程式入口Banner和一些控制開關等配置内容。春節紅包活動橫跨小年、除夕、大年初一，每天有4場答題活動，有些場次為商家專場，是以入口配置中提前以清單形式定義好了各天各場次的具體活動資訊。
2）大插屏配置：
包含活動預熱大插屏的配置内容，由于剛開始時需求的不确定性，獨立出來作為一份配置，後來還增加了分會場呼吸燈的配置内容。
3）錯峰配置：
包含本次春節紅包活動用戶端錯峰方案的配置内容，獨立配置，可供手Q其它通用營運業務複用。
4）預下載下傳配置：
包含春節紅包活動用戶端需要提前預下載下傳的資源配置内容，本次活動資源預覆寫接入使用了QQ錢包業務搭建的資源預下載下傳系統，是以配置參照了QQ錢包預下載下傳系統制定的格式。
五、關于“錯峰”
5.1、以往春節紅包活動的錯峰方案
錯峰，目的是為了解決春節紅包活動高峰對抽獎背景負載帶來瞬間沖擊的問題。以往春節紅包活動的錯峰方案，主要有以下兩種。
1）通過用戶端緩沖過程，控制對抽獎背景的請求：
通過控制參與抽獎的頻率、限制抽獎的次數等方式來進行錯峰，如搖一搖、刷一刷等。
2）通過對活動入口随機時間錯峰顯示，控制對抽獎背景的請求：
将所有使用者随機均勻地映射到活動開始後的一段時間區間内，使使用者錯峰顯示入口進入參與活動，如2019年春節的福袋。錯峰時間的算法形如：hash(uin) % gap。
5.2、我們使用的錯峰方案
上節提到的兩種錯峰方式，第二種與本次春節紅包活動場景是比較吻合的。
不過，該方案存在一個問題：由于其随機性，使得有使用者回報身邊其他人都能看到活動入口參與抽獎了，而自己卻一直看不到入口。
針對方案二的問題，我們引入了使用者地理位置的因素進行改進，下圖描述了總體錯峰方案：
具體方案實作流程如下：
首先，我們定義了一份錯峰配置，包含錯峰時間間隔和區域劃分清單，将全國使用者根據地理位置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.1、意義
春節紅包的資料，不僅是衡量活動營運的品質名額，還會影響到活動的招商。通過對資料進行監控，産品同學可以根據實際活動情況調整産品政策，開發同學可以及時發現并定位問題。同時，資料還是申請活動資源的重要依據。
6.2、核心訴求
春節紅包這種大型全民活動的資料，主要具有上報資料量大、上報并發高、上報場景多樣的特點。
對于春節紅包資料上報，主要有三方面的核心訴求：
1）資料能夠及時上報（實時性需求）；
2）避免為及時上報而導緻資源的過度消耗（如用戶端性能、網絡開銷；背景性能、擴容資源等）；
3）確定上報服務的穩定可用（要有可調整和容錯的能力）。
6.3、為何不使用現有的資料上報
為什麼不直接使用手Q現有的資料上報系統呢？
主要是基于如下幾方面的考慮：
1）可能影響其它長期營運的正常業務；
2）定制化成本高（上報背景需要做一些秒級監控、UV統計等定制邏輯）；
3）上報控制不夠靈活、生效慢（通過配置控制上報邏輯，調整後配置覆寫需要一定時間才能全部生效）；
4）人力、溝通成本等其它方面的考慮。
6.4、春節紅包資料上報
針對春節紅包資料的特點及核心訴求，我們設計了本次春節紅包資料上報方案。
6.4.1 資料上報架構
如上圖所示：
1）調用層：封裝了各上報場景的通用上報能力，通過接口層的統一上報接口将上報資料轉發給邏輯層進行處理。Native、H5均通過原生統一上報接口走SSO通道上報，上報更可靠且無需重複開發；
2）邏輯層：主要包括資料預處理、資料上報政策和容錯機制三部分内容。其中，資料預處理負責對上報的資料進行聚合、過濾和轉換；資料上報政策通過背景可控的參數來控制資料上報的時機、頻率、大小和存儲，確定資料能夠及時上報又不影響用戶端和背景的性能，而且能夠實時動态調整；容錯機制制定了過載政策和降級政策，提供應對上報背景過載的措施；
3）基礎層：即系統和手Q封裝提供的一些基礎能力，如檔案I/O、安全加/解密等。
6.4.2 資料上報的實作流程
如上圖所示：
1）用戶端通過一個串行隊列來處理所有上報的資料，對資料首先會進行聚合、過濾和轉換的預處理，然後将預處理的資料先寫到記憶體緩存中，當滿足儲存檔案的時機時，再異步寫到磁盤檔案中；
2）為避免頻繁寫檔案對CPU、磁盤等帶來的影響，用戶端每隔一段時間寫一次檔案；為防止記憶體中資料丢失，用戶端在前背景切換、殺程序、app crash場景下也會儲存檔案進行補償；
3）當滿足上報時機時，會觸發資料上報請求，并清空緩存資料同時儲存檔案；
4）上報請求回包中帶有上報控制相關資訊，提供了靈活調整的能力。
6.5、遇到的問題分析與解決
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.6、容錯機制
下圖為上報資料的流通流程：
在用戶端資料上報到背景的鍊路中，SSO接入層和上報服務背景均有過載的風險。針對這兩個風險，我們分别用過載政策和降級政策來應對。
1）SSO接入層過載：如果SSO接入層過載了，所采用的的過載政策是：由SSO接入層直接回包，用戶端根據過載标記，将批量上報的batchSize值設定為最大值，并翻倍上報的頻率時間，進而降低用戶端的上報頻率。
2）上報服務背景過載：針對上報服務背景過載的情況，我們制定了一套降級政策，背景回包中包含了兩個降級資訊：
reportLevel：上報級别，預設為0
reportLevelTime：上報級别有效時間，當reportLevel>0時有效
我們設定了4個上報級别，如下圖所示，用戶端根據背景設定的上報級别，來降級上報服務。如果上報級别設定為1，則用戶端會将所有實時上報降級為批量上報；更進一步的，可以設定上報級别為2來降級屏蔽非使用者行為類的資料上報；甚至可以設定上報級别為3來屏蔽所有資料的上報。通過上報級别有效時間，來確定用戶端能夠恢複正常的上報邏輯。
6.7、可優化點
下圖為本次春節紅包活動在除夕當天的資料上報請求曲線，實際上報請求峰值為預估上報請求峰值的13.33%。
從曲線可以明顯的發現，每場答題活動開始時，資料上報都有一個尖峰，這是因為用戶端未對資料上報進行錯峰引起的。這也是本資料上報方案的可優化點之一，錯峰方式可以簡單的随機錯峰上報，亦可參考第二部分内容的錯峰方案。
另一個可優化的點，我們在觸發資料上報請求時，可以帶上觸發上報的時機，這有助于分析使用者觸發資料上報的行為。
七、關于“資源預下載下傳”
7.1、概述
春節紅包活動不僅涉及資源衆多，而且有些資源還比較大。如果這些資源都由用戶端通過實時下載下傳的方式使用，不僅會對CDN帶寬造成巨大的壓力，同時也會對使用者參與活動的體驗造成很大的影響。
自然而然想到最正常最有效的解決辦法就是資源預下載下傳。
對于資源預下載下傳的能力，包括但不限于需要考慮以下幾點：
1）資源能夠正常預下載下傳到本地；
2）業務接入的開發效率（提供更便捷通用的接口，內建資源判斷、實時下載下傳、資源檔案預處理等邏輯）；
3）考慮資源過大時可能引起的CDN帶寬激增問題（需要制定相應的流控方案）；
4）預下載下傳過程不應該影響到其它業務（如手Q啟動時的消息加載、其它業務資源的實時下載下傳等）；
5）資源管理（下載下傳、更新、删除、防篡改、淘汰機制等）；
6）預下載下傳配置管理（存儲、更新、合并、去重等）；
7）等等...
今年春節紅包活動，接入使用的是QQ錢包業務搭建的資源預下載下傳系統，此處就不深入詳細介紹，隻針對今年春節紅包活動在如下幾個方面内容做讨論。
7.2、預下載下傳配置問題
預下載下傳配置為JSON格式，接入手Q配置系統進行釋出時，需要填寫一份涉及所有預下載下傳資源的配置内容，如果通過人工了解手寫配置，不僅易出錯而且效率低下，輕則影響用戶端資源的正常預下載下傳，重則JSON解析處理不當可能會導緻app産生崩潰，在春節如此大體量使用者情況下會造成相當大的影響。
我們的處理辦法是，由春節紅包活動的管理平台根據預下載下傳配置的格式，一鍵導出自動生成預下載下傳配置内容，再到配置平台上釋出。同時，用戶端拉取到預下載下傳配置時，對所拉取的配置内容進行 JSON Schema 校驗，確定這是一個正确的配置後才會使用。若檢查發現配置格式異常，會立刻上報告警通知相關産品、開發人員，以及時發現配置問題并采取措施修複。
7.3、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.4、覆寫率&命中率
預下載下傳支援配置網絡參數，來控制目前資源在什麼樣的網絡環境下才會去預下載下傳。春節紅包總體資源較大，我們配置了所有資源隻在Wifi網絡環境下才預下載下傳，防止消耗使用者的手機流量。是以，我們總體資源的覆寫率不是太高，因為還有不少占比使用者的聯網狀态是非Wifi的。
當然，覆寫率隻是衡量預下載下傳功能的一個名額，另一個重要名額是資源預下載下傳的命中率。命中，表示使用者在使用某個資源時，是否命中了本地預下載下傳的資源。我們在使用者進入主活動入口的時機，增加了資源的命中檢查：如果該使用者進入主活動頁面時，預下載下傳配置中的所有資源都提前預下載下傳到本地了，即認為命中，否則認為不命中，以活動當天首次進入為準。經上報統計，本次春節紅包的資源預下載下傳命中率超過90%。
理想的情況下，預下載下傳要能達到以較低的覆寫率獲得較高的命中率的效果最佳，這說明大部分參與活動的使用者基本都覆寫到了所有資源，是我們的目标使用者。是以，對于目标使用者比較明确的業務，可以通過白名單方式來控制預下載下傳配置隻針對目标使用者進行下發。
八、關于“柔性政策”
春節紅包活動在手Q消息清單處設定了吊墜入口，且活動主要是以H5頁面的方式進行的，對手Q可能會産生如下三方面的影響。
1）對下拉消息清單重新整理消息的影響：
基于使用者對以前手Q春節紅包的認知，在春節紅包活動開始之前，有些使用者會習慣性地去下拉消息清單尋找活動入口，另外分會場設定的呼吸燈也會引導使用者下拉消息清單。這個行為會觸發拉取離線消息，在活動高峰時給消息背景帶來額外的壓力。
為消除對下拉消息清單重新整理消息的影響，我們在每場活動開始時的前後一段時間内以及呼吸燈第一次展示後的一段時間内，禁止使用者重新整理消息，在視覺上仍然有一個假重新整理消息的過程，但實際不會觸發拉取離線消息的請求。通過在配置中添加禁刷開關和禁刷時間來進行控制，可靈活調整。
這裡有個細節，我們将活動開始前後的禁刷時間分開控制，防止禁刷時間段過長，降低春節紅包活動禁刷消息對正常離線消息拉取的影響。
2）對url安全檢查的影響：
在手Q中打開一個H5頁面，WebView會對頁面url攔截進行url安全檢查，隻有通過檢查後才能繼續加載頁面内容。本次春節紅包活動主要以H5方式進行，有較多的url連結，如果都進行安全檢查的話，在活動高峰會給檢查背景增加較大的壓力。
為消除對檢查背景的影響，采取的措施是針對所有春節紅包活動的頁面屏蔽url安全檢查。通過在配置中添加url安全檢查開關和url字首清單來進行控制，所有活動頁面的url走内部域名。另外，屏蔽url安全檢查在一定程度上還可以加快活動頁面的加載速度，弱網環境下會更加明顯。
3）對離線包更新檢查的影響：
本次春節紅包活動的大部分頁面均支援離線包，在使用WebView打開支援離線包頁面時，會觸發離線包的異步更新檢查，在活動高峰期同樣會給離線包背景增加不小的壓力。
消除該影響的辦法，是在所有支援離線包頁面的url中，增加一個開關參數，用戶端判斷若帶有該參數，則直接屏蔽離線包的更新檢查。
那如果活動期間，前端頁面發了新版本的離線包，用戶端要怎麼更新呢？我們設計了一套按需更新的方案，大緻思路是：在進入主活動頁面時，頁面會拉取一份離線包版本配置，并檢查本地離線包版本與配置中指定的版本是否一緻，若不一緻則觸發更新檢查，觸發方式為發起一個不帶屏蔽開關參數的資源請求，請求目标對象為一個1位元組的檔案或1像素的圖檔。
九、寫在最後
2020春節紅包曆時近4個月，經過多次演練、疊代、優化，團隊所有成員在産品體驗、開發細節、測試場景等方面不斷打磨。
在全程參與這種大型全民營運活動的過程中，感受頗深的是，在設計或實作某個看似簡單的功能時，一定要多系統性地思考，盡量做到有依有據，考慮到各方各面。遇到哪怕看似再小的問題時，也要重視，尋其根因。
（—— 全文完 ——）
附錄：有關微信、QQ的技術文章彙總
《微信朋友圈千億通路量背後的技術挑戰和實踐總結》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(圖檔壓縮篇)》
《騰訊技術分享：騰訊是如何大幅降低帶寬和網絡流量的(音視訊技術篇)》
《微信團隊分享：微信移動端的全文檢索多音字問題解決方案》
《騰訊技術分享：Android版手機QQ的緩存監控與優化實踐》
《微信團隊分享：iOS版微信的高性能通用key-value元件技術實踐》
《微信團隊分享：iOS版微信是如何防止特殊字元導緻的炸群、APP崩潰的？》
《騰訊技術分享：Android手Q的線程死鎖監控系統技術實踐》
《微信團隊原創分享：iOS版微信的記憶體監控系統技術實踐》
《讓網際網路更快：新一代QUIC協定在騰訊的技術實踐分享》
《iOS背景喚醒實戰：微信收款到賬語音提醒技術總結》
《騰訊技術分享：社交網絡圖檔的帶寬壓縮技術演進之路》
《微信團隊分享：視訊圖像的超分辨率技術原理和應用場景》
《微信團隊分享：微信每日億次實時音視訊聊天背後的技術解密》
《QQ音樂團隊分享：Android中的圖檔壓縮技術詳解（上篇）》
《QQ音樂團隊分享：Android中的圖檔壓縮技術詳解（下篇）》
《騰訊團隊分享：手機QQ中的人臉識别酷炫動畫效果實作詳解》
《騰訊團隊分享 ：一次手Q聊天界面中圖檔顯示bug的追蹤過程分享》
《微信團隊分享：微信Android版小視訊編碼填過的那些坑》
《微信手機端的本地資料全文檢索優化之路》
《企業微信用戶端中組織架構資料的同步更新方案優化實戰》
《微信團隊披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ背景服務接口隔離技術》
《月活8.89億的超級IM微信是如何進行Android端相容測試的》
《以手機QQ為例探讨移動端IM中的“輕應用”》
《一篇文章get微信開源移動端資料庫元件WCDB的一切！》
《微信用戶端團隊負責人技術訪談：如何着手用戶端性能監控和優化》
《微信背景基于時間序的海量資料冷熱分級架構設計實踐》
《微信團隊原創分享：Android版微信的臃腫之困與子產品化實踐之路》
《微信背景團隊：微信背景異步消息隊列的優化更新實踐分享》
《微信團隊原創分享：微信用戶端SQLite資料庫損壞修複實踐》
《騰訊原創分享(一)：如何大幅提升移動網絡下手機QQ的圖檔傳輸速度和成功率》
《騰訊原創分享(二)：如何大幅壓縮移動網絡下APP的流量消耗（下篇）》
《騰訊原創分享(三)：如何大幅壓縮移動網絡下APP的流量消耗（上篇）》
《微信Mars：微信内部正在使用的網絡層封裝庫，即将開源》
《如約而至：微信自用的移動端IM網絡層跨平台元件庫Mars已正式開源》
《開源libco庫：單機千萬連接配接、支撐微信8億使用者的背景架構基石 [源碼下載下傳]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團隊原創分享：Android版微信背景保活實戰分享(程序保活篇)》
《微信團隊原創分享：Android版微信背景保活實戰分享(網絡保活篇)》
《Android版微信從300KB到30MB的技術演進(PPT講稿) [附件下載下傳]》
《微信團隊原創分享：Android版微信從300KB到30MB的技術演進》
《微信技術總監談架構：微信之道——大道至簡(演講全文)》
《微信技術總監談架構：微信之道——大道至簡(PPT講稿) [附件下載下傳]》
《如何解讀《微信技術總監談架構：微信之道——大道至簡》》
《微信海量使用者背後的背景系統存儲架構(視訊+PPT) [附件下載下傳]》
《微信異步化改造實踐：8億月活、單機千萬連接配接背後的背景解決方案》
《微信朋友圈海量技術之道PPT [附件下載下傳]》
《微信對網絡影響的技術試驗及分析（論文全文）》
《一份微信背景技術架構的總結性筆記》
《架構之道：3個程式員成就微信朋友圈日均10億釋出量[有視訊]》
《快速裂變：見證微信強大背景架構從0到1的演進曆程（一）》
《快速裂變：見證微信強大背景架構從0到1的演進曆程（二）》
《微信團隊原創分享：Android記憶體洩漏監控和優化技巧總結》
《全面總結iOS版微信更新iOS9遇到的各種“坑”》
《微信團隊原創資源混淆工具：讓你的APK立減1M》
《微信團隊原創Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實戰記錄》
《iOS版微信安裝包“減肥”實戰記錄》
《移動端IM實踐：iOS版微信界面卡頓監測方案》
《微信“紅包照片”背後的技術難題》
《移動端IM實踐：iOS版微信小視訊功能技術方案實錄》
《移動端IM實踐：Android版微信如何大幅提升互動性能（一）》
《移動端IM實踐：Android版微信如何大幅提升互動性能（二）》
《移動端IM實踐：實作Android版微信的智能心跳機制》
《移動端IM實踐：WhatsApp、Line、微信的心跳政策分析》
《移動端IM實踐：谷歌消息推送服務(GCM)研究（來自微信）》
《移動端IM實踐：iOS版微信的多裝置字型适配方案探讨》
《信鴿團隊原創：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術分享：百億級實時消息推送的實戰經驗》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《騰訊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）