一、引言
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）