本文內容整理自騰訊專家研究員 & 微信視頻技術負責人谷沉沉在 2017 ArchSummit 全球架構師峯會上的技術分享。
1、前言
2012 年 7 月，微信 4.2 版本首次加入了實時音視頻聊天功能，如今已發展了 5 年，在面對億級微信用戶複雜多變的網絡和設備環境，微信多媒體團隊在每個技術細節上不斷地深耕細作，爲微信用戶提供了高質量的視頻通話。
今年騰訊全球合作伙伴大會上發佈的《2017 微信數據報告》顯示，到 2017 年 9 月，微信日成功通話次數 2.05 億次，月人均通話時長 139 分鐘，月人均通話次數 19 次。無論是通話次數還是通話時長都比去年增加了一倍多，這個增長速度遠遠高於微信用戶量的增長，這與微信多媒體團隊在音視頻技術上的努力是分不開的。
本文將爲大家介紹微信實時音視頻聊天在不同發展階段的各個關鍵視頻技術環節採用的方案，同時分享在實時音視頻聊天中的視頻編碼器研發的方法和經驗。
在本次正式技術分享前，谷沉沉作爲受訪嘉賓，接受了InfoQ的技術專訪，技術專訪內容請見《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》。
（本文同步發佈於：http://www.52im.net/thread-1311-1-1.html）
學習交流：
- 即時通訊開發交流羣：320837163[推薦]
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
2、分享者
▲ 圖中【左起第5位】爲本文分享者：谷沉沉
谷沉沉：騰訊專家研究員 & 微信視頻技術負責人。
2007 年碩士畢業於哈爾濱工業大學，在校課題研究期間參與過 AVS、H.264SVC 等視頻編解碼標準技術研究。加入騰訊後也一直從事視頻圖像相關的技術研發工作，先後主導過 QQ、微信、手機 QQ 視頻通話、騰訊視頻等產品的視頻技術研發，目前主要負責微信視頻通話、朋友圈視頻圖片等業務相關的視頻圖像技術研發和團隊技術管理。
擁有豐富的視頻技術研究與應用實戰經驗，在國際視頻領域知名學術會議刊物上發表多篇論文，數十項視頻技術領域的發明專利在國內外獲得授權，其中兩件獨立發明的專利榮獲中國專利獎。
3、互聯網實時音視頻聊天的特點
3.1 互聯網視頻應用的目標
與很多互聯網視頻應用類似，互聯網視頻通話的應用目標也是希望用儘可能低的成本使視頻更加清晰與流暢。
上圖右邊互聯網視頻應用的代價成本包含兩個維度：
一是帶寬成本：包括客戶端用戶的流量成本，以及服務器端帶寬成本；
二是計算開銷：表現在服務器端的設備投入量，以及客戶端的 CPU 佔用、耗電量等，而對於性能較差的客戶端設備，控制客戶端的計算資源還可以保障這些設備也能支持基礎質量的視頻通話。
3.2 視頻通話的技術挑戰
上圖中谷沉沉列舉了四類互聯網視頻應用，其中視頻通話應用相對於短視頻分享、流媒體直播和媒體存儲來說有三個特殊的挑戰：
第一：由於微信視頻通話集中在移動端，這就要求系統的計算複雜度儘可能低；
第二：由於視頻通話是高度實時的應用，決定了視頻數據一般採用不可靠傳輸，這就要求視頻傳輸具有一定的魯棒性，比如抗丟包的特性，另外，由於沒有緩衝機制，視頻發送碼率要儘可能平穩；
第三：由於很多用戶在 3G、4G 等移動網絡下使用，對流量比較敏感，所以視頻通話帶寬佔用要儘可能低。
最左邊三點是微信視頻通話作爲海量級用戶產品具有的特殊難點：
1）用戶的網絡狀況和設備性能差異巨大，所以微信視頻通話要適應不同的網絡和設備；
2）由於用戶版本更新存在一定的週期，這就需要考慮新技術對舊版本的兼容性；
3）另外，海量併發用戶對服務器端造成的帶寬成本壓力也是必須要考慮的。
所以，互聯網視頻通話是各種互聯網視頻應用中約束條件最多、最苛刻，也是實現難度較大的一種互聯網視頻應用。
4、微信實時視頻聊天的基本技術框架
據谷沉沉透露，現在微信視頻通話是基於微信多媒體團隊自研的多媒體應用綜合引擎——WAVE (Wechat Audio&Video Engine)。該引擎的底層——內核層是由傳輸、視頻、音頻三大類跨平臺技術構成的。在此之上，針對不同應用類型的特點做了一些接口封裝和應用邏輯設計，形成應用層，目前支持三類不同的應用：第一類是實時通話應用，目前用於微信的點對點和多人視頻通話。第二類是多格式的圖片處理，主要用在微信朋友圈、公衆平臺以及表情等圖片的壓縮和處理上。第三類是音視頻文件壓縮，應用於朋友圈視頻、語音和視頻消息的壓縮和處理等。
經過多年的技術積累，WAVE 引擎支持了每天數億的視頻通話、數十億的視頻播放、數千億的圖片查看，所以整個引擎在壓縮效率、計算速度、音視頻質量等方面的性能都經過了微信億萬用戶的考驗，是業界比較領先的多媒體引擎。
谷沉沉表示他們團隊現在還在不斷提高引擎的處理速度、壓縮效率等性能，希望能用最合理的成本爲廣大用戶提供最好的多媒體體驗。
下圖是基於 WAVE 引擎的微信視頻通話系統，包含視頻、音頻、傳輸三大類技術，分佈在設備層、引擎層、服務器端三個層面。標紅的部分是視頻引擎涉及的技術。
下圖是 WAVE 微信視頻引擎的框圖，在發送端，攝像頭採集的原始視頻數據，一路直接在本地小窗口渲染，另一路先經過視頻前處理，再進行視頻編碼，之後對編碼生成的碼流進行容錯保護，最後發送到網絡上。相應地，在接收端，對收到的碼流先進行錯誤恢復，對正確恢復的數據進行視頻解碼，而後通過後處理增強提升視頻質量，最後經過播放控制流暢地顯示在接收端屏幕主窗口上。
其中 QoS 的反饋模塊會收集接收視頻的質量、網絡狀況等信息，通過服務器處理反饋到發送端，發送端再根據這些信息選擇合適的視頻編碼的參數，這樣就能實時適應不同的網絡狀況。目前，很多網絡適配算法都是在 QoS 服務器上執行的，這樣，如果新算法發佈後發現問題，不用等到下一個客戶端版本的發佈，就可以快速地在服務器端進行修改控制，加快算法的迭代進度。
5、實時視頻引擎的關鍵技術
上圖列出了視頻引擎中最關鍵的六大模塊的技術，其中最核心的是決定整個引擎基礎性能的視頻編解碼模塊，與之密切相關的有前後處理、容錯保護、網絡適配模塊，還有設備層的採集與顯示，以及對海量用戶通話情況的評價和運營體系，這六個模塊技術協同配合，任何一個模塊的短板都會影響整體視頻通話質量。
在微信實時音視頻聊天版本發展的不同時期，這些技術模塊的發展也是各有側重，整體上大致經歷了三個階段：
第一階段是基礎框架的搭建和性能優化：
2010-2012 年，第一個微信視頻通話發佈前後的這段時間，當時大部分主流移動設備 CPU 主頻只有單核 1GHz，爲了在這樣的設備上能流暢運行視頻通話，微信多媒體團隊在視頻編解碼速度優化上下了很大的功夫，當時優化後的編解碼速度在同等壓縮效率下已經達到了業界領先水平；在採集顯示環節也採用了快速、高質量的方案，並做了大量代碼流程優化以提高處理速度，如減少內存的拷貝，優化格式轉換流程等；由於當時客戶端計算能力是整個視頻通話的瓶頸，視頻幀率、碼率較低，發送數據量對於大部分網絡不會造成太大壓力，所以第一階段的容錯保護策略非常簡單，只對關鍵幀做保護。經過這些基礎性能的優化，第一個微信視頻通話版本跟業界同類產品相比，同等帶寬下的視頻清晰度和流暢度都是非常不錯的。
第二階段是隨着移動設備硬件性能的逐漸提升：
一些性能較好的移動設備可以支持更高幀率的視頻通話，發送碼率也隨之增大，於是網絡適配策略就成爲這一階段的研發重點，由於實驗模擬網絡環境與海量用戶真實的網絡環境總是存在差異，所以很多網絡適配算法在經過模擬環境下的驗證後，還必須進行線上灰度測試，通常會隨機抽取大量樣本做算法的對照實驗，如果在大規模樣本上新算法的各項技術指標均優於現網算法，纔會逐步放開到所有的通話。在這個灰度測試過程中，海量用戶通話質量的評價運營體系也逐步建立和完善。
第三階段是在近兩年，移動設備性能大幅度地提升：
很多 4 核 8 核手機的性能甚至比早些年的 PC 機都要好，設備的計算性能已經可以支撐更高複雜度的計算，因此微信多媒體團隊開始研發視頻前後處理技術以提高主觀質量，同時在視頻編解碼上也加入了一些高複雜度、高壓縮效率的算法，使視頻通話在同等帶寬下可以達到更高的視頻質量。
由於演講時間所限，將選擇其中視頻編解碼、前後處理和容錯保護三個模塊進行重點技術分析。
6、實時視頻引擎的關鍵技術之視頻編解碼
6.1 視頻編解碼的性能指標
在互聯網視頻應用中，視頻編解碼的核心指標概括起來一般有三個：
編碼效率；
編解碼速度；
傳輸適應性。
而這些指標之間是相互制約的，編碼效率的提升往往是以犧牲編碼速度爲代價，傳輸適應性也會影響編碼效率，比如容錯保護時增加冗餘會導致編碼效率下降。所以一個好的視頻編解碼器需要在這些指標之間找到合理的平衡點。
這三個指標在視頻通話中具體需要關注哪些方面呢？
首先，在編碼效率上：
1）微信視頻通話的場景非常多樣，除了類似傳統視頻會議那樣整體內容比較靜止的場景外，還有很多運動劇烈的場景。可能很多人認爲微信視頻聊天通常都是手持手機攝像頭對着人臉，應該都屬於比較靜止的視頻場景，但在攝像頭距離人臉較近時，人臉在視頻畫面中佔據了較大部分，這樣人臉的一點輕微運動對於整個視頻來說已經是屬於運動比較劇烈的內容場景，同時手持設備不穩定時還會造成視頻畫面的抖動，使運動更加複雜，因此微信視頻通話中的編碼算法必須適應多種不同的場景；
2）歷史版本互通兼容性，新的編碼技術必須要考慮舊版本的解碼兼容性，所以一旦編解碼格式確定就不能頻繁更新，只有當技術積累到一定程度，壓縮效率有突破性的提升，纔會考慮升級替換；
3）主觀質量是“王道”，對互聯網應用來說，普通用戶不會關注 PSNR 等客觀質量指標，只會用眼睛來看，所以任何的客觀數據都只是技術上一種便捷的衡量方式，最終的衡量標準還是人眼的主觀感受。
其次，在編解碼速度方面：
編解碼算法複雜度和實現優化程度都是影響編碼速度的重要因素。實現優化包括軟件的快速算法和代碼級優化，也包括硬件加速。隨着一代又一代的視頻編碼標準的發展，編碼效率的提升往往伴隨着算法複雜度的增加，CPU 難以支撐高複雜度的軟件編解碼計算，如果硬件視頻編解碼各方面性能可以滿足視頻通話的需求，利用硬件來加速視頻編解碼就可以極大地緩解 CPU 計算資源壓力。此外，還要考慮幀級複雜度的均勻性，因爲視頻通話能支持的最高幀率是由序列中編碼最慢的幀的時間消耗決定的。
第三，在傳輸適應性上：
要求視頻碼流的碼率儘可能平穩，更嚴格地，還要控制幀級瞬時數據量衝擊，以減少瞬時數據量衝擊造成網絡擁塞而出現丟包、延時等問題。此外，視頻碼流還需要具有一定的抗丟包能力。
6.2 如何打造一個優秀可靠的視頻 Codec？
根據多年的工作經驗，我們總結了打造一個優秀可靠的互聯網視頻應用軟件 Codec 的四個階段。
針對其中第三、第四階段的優化，用兩個微信多媒體團隊實戰優化過程中的案例進行具體說明：
第一階段是格式的確立：主要是根據應用的計算複雜度要求選擇合適的編碼標準格式，或者開發私有格式，這一階段主要考慮編碼效率，評價方式類似標準組織的通用測試條件。
第二階段是實現優化：主要是通過代碼優化和快速算法優化等提高編解碼速度，同時控制編碼效率損失，在滿足應用要求的條件下，達到編碼效率和編解碼速度的合理平衡。
第三階段是應用定製：針對特定的應用場景需求做一些定製的研發，達到合入產品預發佈的要求。比如微信視頻通話中的碼率平穩性要求，以及編碼參數切換支持等，都是在這個階段通過碼率控制算法優化來實現的。
6.3 案例分享：碼率控制優化
碼率控制的難點是平衡碼率平穩性和壓縮效率、質量平穩性。雖然學術上有很多碼率控制的研究，但實際工程應用中還是有很多問題需要考慮，如碼率控制的時間單位，極低幀率、極小 I 幀間隔下的碼率控制，單幀瞬時衝擊等。
上圖的第一張設置目標碼率 360kbps 的每秒數據量波動圖中，紫色線是微信自研視頻編解碼器的碼率波動情況，可以看出每秒的碼率基本都穩定在 360kb 左右，而藍色線表示的同等編碼效率下 x264 碼率波動情況，在一些運動比較劇烈的場景，碼率會上升到 420kb，明顯高於目標碼率，這對我們實時視頻通話應用就會有很大的衝擊。
雖然第一張圖中微信自研視頻編解碼器的每秒數據量波動已經非常平穩了，但第二張圖中紅色線表示的半秒數據量波動曲線還是呈鋸齒狀，這在傳輸中依然會對網絡產生一定的衝擊，爲了進一步提升碼率平穩性，微信多媒體團隊又進行了第二輪更加嚴格的碼率控制優化，可以看出綠線所示的現網微信視頻通話版本半秒數據量波動明顯比第二輪優化前的紅線平穩。
第四個階段是打磨穩定，雖然前面每個階段都會對編解碼器進行編解碼匹配、編解碼各項指標性能等編解碼器離線測試驗證，但在合入產品應用後，尤其是在海量用戶實際應用環境中，還是會出現一些編解碼器離線測試時發現不了的問題，如主觀質量的缺陷問題，需要逐一分析儘可能優化主觀質量，以及當解碼器接收到不能正常解碼的“髒”數據時，需要加強解碼器的魯棒性保護，及時終止解碼防止 crash 等。
6.4 案例分享：減輕塊效應
這裏分享了在微信實時音視頻聊天研發過程中減輕塊效應的兩個優化方向：
1）一個優化方向是碼率分配微調，包含幀級和幀內兩個方面：
幀級碼率分配微調是針對碼率平穩性優化造成運動劇烈場景下視頻質量損傷明顯的問題。因此在完成碼率控制算法之後需要根據主觀質量情況對碼率分配做一些微調，適當增加運動劇烈場景下碼率分配以提高質量；幀內率分配微調是指，由於人眼對平坦區域更加敏感，所以也會多爲平坦區域多分配一些碼率。在上面這個視頻中，左面是優化之前，右面是優化之後，在運動劇烈場景中，如揮手的時候，手的部位較平坦區域塊效應明顯減輕。
2）另一個優化方向是編碼模式的微調，這裏舉兩個例子：
2.1）一是關於 skip 模式的判定：
上圖左下角解碼視頻截圖中臉部標紅圈的地方出現比較明顯的塊效應問題，經過分析發現這個視頻中相鄰的這兩幀在這個位置上內容相似，編碼過程中基於率失真最優原則的模式選擇結果是採用 skip 模式編碼，簡單說就是直接拷貝前一幀中相應的像素塊，雖然在客觀編碼效率上是當前塊最優的編碼模式，但主觀質量上塊效應比較明顯，微信多媒體團隊對 skip 模式的判斷條件做了一些微調，將這種情況改用 inter 模式編碼，多留一些殘差信息，雖然這個位置“花費”的比特數比 skip 模式多一點，但失真度也會低一些，圖中右面經過調整之後這個位置基本看不出塊效應。
2.2）另一種編碼模式的微調是 intra 和 inter 模式的選擇：
當 intra 和 inter 模式編碼的率失真代價比較接近，採用哪種模式編碼對客觀編碼效率影響很小。但是在主觀質量上，有時候 inter 模式的殘差較小，量化之後一部分小系數的丟失也容易造成塊效應，這個時候針對這些場景利用一些輔助的統計信息，將這種場景判定爲 intra 模式編碼就能解決這類塊效應問題。
7、實時視頻引擎的關鍵技術之前後處理
前後處理的增強效果毋庸置疑，但在很多場景下“副作用”也比較大，比如去噪容易造成細節模糊甚至缺失，銳化可能帶來鋸齒效應……
因此研究前後處理算法的關鍵是要消除“副作用”，微信多媒體團隊就是按照“寧缺毋濫”的原則，即每次前後處理算法的更新可以只對部分場景增強，增強的幅度也可以較小，但必須保證不會出現質量變差的場景。在算法研究階段需要設計好場景自適應策略，對於算法無法完全解決的情況，再輔以運營策略，比如“白名單、黑名單”機制，對特定型號設備開啓或關閉相應的算法等。
案例分享：光照增強
光照增強問題的發現來源於微信多媒體團隊的一次視頻通話測試體驗，在晚上室內日光燈環境下，不同手機攝像頭採集的視頻質量差異較大，有些手機的採集視頻與真實環境光照基本一致，而有些手機採集的視頻就偏暗，甚至連人臉都無法看清。
針對這種情況，微信多媒體團隊自主研究了一種低照度視頻增強方法：
先通過對單幀平均亮度和最大、最小亮度等信息的分析和統計，推導出單幀的亮度增強和對比度增強的自適應約束；
爲避免視頻連續播放出現亮度閃爍，算法還考慮了前後幀亮度變化的一致性約束；
最後對三個方面的約束做聯合優化求解，由於優化項中只包含二次項，再進行快速算法實現優化，求解過程計算複雜度較低，因此整個光照增強技術可以在視頻通話中實時處理。
上圖左上角子圖 (a) 爲低光照的輸入源視頻截圖，(f) 爲微信自研光照增強算法處理後的視頻截圖，增強後可見臉部更多細節和背景環境的紋理，而從其餘幾個現有視頻圖像增強對照算法處理後的截圖中，可以看出存在不同程度的顏色異常或增強效果不明顯等問題。
這項實用的研究成果在應用於微信視頻通話有效提升視頻質量的同時，也得到了學術界的高度認可。該算法相關的論文已發表在國際視頻領域知名會議 ISCAS2017 上，並受邀在大會上宣講，也是該次會議上僅有 5% 來自工業界的論文之一。感興趣的讀者可參考《Low-Lighting Video Enhancement Using Constrained Spatial-Temporal Model for Real-Time Mobile Communication》, IEEE ISCAS, pp：595-598, 2017。
8、實時視頻引擎的關鍵技術之容錯保護
容錯保護往往通過增加冗餘來實現，而視頻編碼又是通過降低冗餘來提高壓縮效率，所以容錯保護的關鍵是要做到壓縮效率和容錯能力的平衡。
主要有信源容錯和信道容錯兩類方法：
1）信源容錯可以通過改變參考關係：
比如上圖裏 IPPP 這樣依次參考的結構，如果 P4 這幀丟失了，後面從 P5 開始所有幀都無法正常解碼，在視頻通話中就表現爲卡住。但如果改變參考關係，讓 P5 參考 P3，這樣 P4 雖然丟失了，但是 P5 和後面的幀都還可以正常解碼，這就是一種抗丟包能力。由於 P5 的參考幀距離變遠了，相關性比 P5 和 P4 之間的相關性弱，P5 的數據量就會增大，壓縮效率就會降低，這就是這種容錯方式所帶來的時域冗餘代價。我們需要在容錯能力和冗餘代價上取得較好的平衡，在應用中也可以根據網絡狀況選擇合適的冗餘能力。
2）信道容錯的方法有信源容錯可以通過改變參考關係來提高在丟包環境下的視頻解碼正確率：
如上圖中 IPPP 參考幀結構，若 P4 幀丟失了，其後從 P5 開始的所有幀都無法正常解碼，在視頻通話中就表現爲卡住。但如果改變參考關係，使 P5 參考 P3，這樣，P4 的丟失就不影響 P5 及其後續幀的正常解碼。但由於此時 P5 的參考幀距離變大，可能造成 P5 的幀間預測準確性下降，導致 P5 編碼數據量增大，壓縮效率降低，這就是這種容錯方式所帶來的時域冗餘代價。因此需要在容錯能力和冗餘代價上取得較好的平衡，在應用中也可以根據網絡狀況選擇合適的容錯能力。
在信道容錯方面，有分組異或、RS 編碼等 FEC 前向糾錯技術。可以根據每一幀的重要性等級增加不同的冗餘保護，上圖中紅色越深的幀表示重要性越高，它的丟失會造成更多幀解碼失敗，可以對這些越重要的幀增加越多的冗餘保護。另外，對低延時網絡，如果遇到丟包導致解碼失敗，可以向發送端主動請求編碼 I 幀，避免長時間的卡頓。
9、未來之路
談到未來，谷沉沉表示互聯網時代業務和技術日新月異，在不太遠的未來幾年內，視頻技術的發展方向大致有三類：
1）基礎技術的突破，如 H.266、AVS3、AV1 等下一代標準，以及最近的熱點研究方向——基於深度學習的視頻圖像壓縮，壓縮效率將進一步提高；
2）現有視頻產品的體驗提升，繼續向着高質量、低帶寬 / 存儲空間、低功耗的方向發展；
3）新的產品形態不斷出現，比如 3D、VR 甚至光場等沉浸式的視頻通話。
未來，微信多媒體團隊將繼續堅持以專業、專注的精神，研發實用的多媒體技術，也歡迎對視頻圖像技術感興趣的優秀人才加入或開展技術研究合作，一起來不斷提升數億用戶的微信視頻通話等各類視頻圖像相關業務體驗！
附錄1：微信、QQ相關的文章彙總
[1] 有關QQ、微信的技術文章：
《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)的坑》
>> 更多同類文章 ……
[2] 有關QQ、微信的技術故事：
《2017微信數據報告：日活躍用戶達9億、日發消息380億條》
《技術往事：創業初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》
《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
《開發往事：深度講述2010到2015，微信一路風雨的背後》
《開發往事：記錄微信3.0版背後的故事（距微信1.0發佈9個月時）》
>> 更多同類文章 ……
附錄2：更多實時音視頻文章
[1] 開源實時音視頻技術WebRTC的文章：
《訪談WebRTC標準之父：WebRTC的過去、現在和未來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《新手入門：到底什麼是WebRTC服務器，以及它是如何聯接通話的？》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基於開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》
《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》
>> 更多同類文章 ……
[2] 實時音視頻開發的其它精華資料：
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（九）：實時語音通訊的迴音及迴音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的迴音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》
《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《還在靠“喂喂喂”測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《技術揭祕：支持百萬級粉絲互動的Facebook實時視頻直播》
《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》
《首次披露：快手是如何做到百萬觀衆同場看直播仍能秒開且不卡頓的？》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
>> 更多同類文章 ……
（本文同步發佈於：http://www.52im.net/thread-1311-1-1.html）