本文內容由“微信多媒體團隊”整理發布。

1、引言

廣州TIT創意園，這里是騰訊在廣州的研發團隊所在地，LiveVideoStack采訪了微信多媒體內核中心音視頻算法高級工程師梁俊斌（Denny）。從華為2012實驗室到騰訊，過去十余年梁俊斌一直專注在音頻技術。他告訴LiveVideoStack：音頻技術還有許多難點需要解決，而作為技術人也延展到應用場景，關注用戶需求。本文整理了本次訪談的主要內容，僅供參閱。

學習交流：

- 即時通訊開發交流3群：185926912[推薦]

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

（本文同步發布于：http://www.52im.net/thread-1828-1-1.html）

2、相關文章

《微信團隊分享：視頻圖像的超分辨率技術原理和應用場景》

《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》

《微信團隊分享：微信Android版小視頻編碼填過的那些坑》 

《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》

《騰訊技術分享：微信小程序音視頻技術背后的故事》

Q：Denny你好，先簡單介紹下自己的經歷，從學生時代到進入職場，過去這段時間的一些關鍵的經歷，以及現在主要做哪些方面的研究？

梁俊斌：現在是2018年，二十年前（1998年）我考進華南理工大學，直到2007年這9年都在華南理工大學完成我的本科、碩士、博士的學業，期間跨越了好幾個不同的學科和技術領域，包括機械、電子、自動化、人工智能，這些不同的學科跨度還是蠻大的，和其他的音頻同行有不同，他們一開始在學校就專攻音視頻多媒體、編解碼算法。我在大學期間，在音視頻領域是沒有較多的積累，只是基本了解一點，實際接觸不多。

2007年，從華南理工大學畢業之后加入了華為公司，進入了“2012實驗室”多媒體工程能力中心，在這里我開始踏入語音頻領域，并從此鎖定了自己的職業道路方向，到現在我還在持續做語音相關的技術。期間有過一些其他部門的同事邀請我轉行，但我拒絕了，我堅信要做自己認為正確的事情，就必須破釜沉舟把它做深做透。音頻這個行業還有很多很不成熟的東西，可能從外界普通用戶的角度來說，我們這塊已經很成熟了，沒什么可做的，但實際上（語音）還有很多尚未解決的難題，需要有人來做。

后來我進入了騰訊公司，加入了微信團隊。微信給我最大的觸動就是所有人都在用，這種空前的成就感是不言而喻的，所有的親戚朋友都在用，要是自己做不好的話，尤其是語音通話、語音消息每天都在用，哪天不小心出點Bug，就會影響到很多很多身邊的人，所以在享受微信工作帶來的滿足感的同時做技術每個環節都要求非常嚴謹。

華為最為神秘的“2012實驗室”（據說研究的都是各種黑科技）：

華為的“2012實驗室”是華為的總研究組織，據稱，該實驗室的名字來自于任正非在觀看《2012》電影后的暢想，他認為未來信息爆炸會像數字洪水一樣，華為要想在未來生存發展就得構造自己的“諾亞方舟”。

華為2012實驗室的主要研究的方向有新一代通信、云計算、音頻視頻分析、數據挖掘、機器學習等。主要面向的是未來5-10年的發展方向。華為官方數據顯示，2015年，華為研發投入為596億元人民幣，占2015年銷售收入的15.1%，近十年來，華為已經在研發方面投入了超過2400億元人民幣。

2012實驗室的二級部門包括：中央硬件工程學院、海思、研發能力中心、中央軟件院。今天著重講述華為很少對外公開，但在2012實驗室里有著極高戰略地位的研究部門。

Q：音頻這個領域，在外人看來已經沒有什么可做的，無外乎就是語音，不像視頻各種新鮮的產品，360度視頻、VR等。那么，音頻這塊到底還有什么挑戰？我們外行所不知道的？

梁俊斌：語音通話是兩個或多個人在不同的地點通過手機或者說其他終端完成對話的過程，這里涉及到通話的外界聲學環境因素，包括噪聲、回聲，混響，所有這些環境因素都會影響對方的收聽效果，而不同場景環境下問題現象差異較大，如何有效解決這是一個方面。

第二方面，微信是一個超十億級用戶的APP，其中的音視頻通話功能是最基礎的，我們每天都有幾億人在使用這個功能，這里涉及成千上萬款不同廠家不同型號的手機（當然還有PC、Mac等設備），其不同硬件有不同的聲學特性，例如頻響、不同設備的內置硬件處理后的噪聲、雜音等，也有操作系統非實時性的問題，還有各種APP的音頻資源沖突等各種狀況，我們都需要做相應的適配和有針對性的優化。

另外，網絡傳輸可靠性是非常關鍵的部分，網絡傳輸存在丟包、抖動、時延等問題，網絡越復雜問題更多。語音包到達對方終端后解碼、播放。聲音傳入耳朵的過程是心理聲學感知的過程，你能不能感知的到對方傳遞的聲音信息，信息是否干凈且易懂。聲音傳遞到大腦，其中的關鍵信息是否讓你有深刻印象還是聽了就忘沒有痕跡，這些都是很值得研究的課題。而我們微信技術架構部多媒體內核中心自主研發的WAVE（微信音視頻引擎）組件正是圍繞上述問題不斷迭代、持續改進優化，構建高可用性的互聯網音視頻通話技術基石。

行外人不了解這些細節問題，所以才覺得沒什么可做的，然而這個細節問題是必須有人做的，而且需要長期的一絲不茍的投入。做一個能通話的APP不難，但做一個超十億級用戶都認可的通話功能是不簡單的。

Q：微信做到這個量級，已經不僅僅是做一個簡單產品的問題了，而是要對用戶負責，因為這個可能會影響到很多人工作和生活。

梁俊斌：是的，這是一個系統工程，而不僅是一個安裝在手機上的應用軟件，需要涉及通話雙方端到端一環扣一環的質量監控和故障應對體系。我們每天都會積極搜集用戶的反饋信息，深入具體case去分析通話問題的原因，盡我們所能幫助用戶解決問題。

此外我們擁有功能強大的后臺運維系統，該系統能實時對大盤通話質量做端到端的分析，對異常情況會及時報警，保障通話功能的正常使用。雖然微信通話是免費的，但我們身上的責任是巨大的，我們微信技術架構部多媒體內核中心每個同事每天都在為提升改進用戶音視頻通話體驗而不斷努力。

Q：在互聯網上丟包、抖動是不可控的，需要來應對。另外，如何更清晰和深刻的傳達信息，可能涉及到心理學，耳朵的結構特性，這些能簡單講一講嗎？

梁俊斌：是的，互聯網是相對不可靠的，在WAVE引擎里面提供了適配不同網絡傳輸特性的抗丟包、抗抖動算法和機制，讓通話過程語音更順暢。

心理聲學是研究物理聲學與人類聽覺感知之間關系的一門邊緣學科，心理聲學其中一個基本特性就是掩蔽特性，其又分為時域效應和頻域效應，這里我們側重在頻域上的掩蔽效應，常規情況下相鄰頻帶能量強的會屏蔽掉能量弱的頻帶，在通話應用中，例如降噪算法，我們會通過降低噪聲頻點能量至掩蔽值以下來降低噪聲對人耳感知的干擾，同時減少對正常語音的損傷。

除此以外，心理聲學還應用到很多技術點上，這里就不一一細說了。

Q：一般我用微信開電話會議會用耳機，用耳機相當于就沒有回聲了，基本上就可以把回聲消除掉了？

梁俊斌：部分手機在耳機模式下由于聲屏蔽設計所以基本沒有回聲，但也有些手機在耳機模式下還是有可能產生回聲的，可能是電耦合的電學回聲，因為這里耳機產生的回聲的線性度比較高，相對聲學回聲的非線性度高而言是比較容易通過AEC抵消抑制的，所以常規情況下你通過耳機接聽基本沒有回聲問題。

什么是AEC？

AEC是回聲消除器（Acoustic Echo Canceller）技術的簡稱, AEC是對揚聲器信號與由它產生的多路徑回聲的相關性為基礎，建立遠端信號的語音模型，利用它對回聲進行估計，并不斷地修改濾波器的系數，使得估計值更加逼近真實的回聲。然后，將回聲估計值從話筒的輸入信號中減去，從而達到消除回聲的目的，AEC還將話筒的輸入與揚聲器過去的值相比較，從而消除延長延遲的多次反射的聲學回聲。根椐存儲器存放的過去的揚聲器的輸出值的多少，AEC可以消除各種延遲的回聲。

Q：其實我們要做得事情是非常多的，設備不斷更新。網絡情況可能網絡會越來越好一點，5G移動網絡穩定性會高一點。

梁俊斌：從5G的設計目標是高帶寬低時延，但目前還沒真正商用，對此我還是有點保留的，因為頻率越高傳輸的距離越有限，網絡覆蓋應該更小，最終的網絡質量還要跟基站建設密度相關，要是做得不好的話，對我們音視頻通話是一個挑戰。由于純語音通話本身所占帶寬有限，5G的影響相對來說還不是很大，對于視頻通話體驗應該是有提升的，當然帶寬越大、時延越低，我們可以做得技術可以更多。

另外通話雙方使用的如果是不同網絡或者不同運營商網絡，如何適配和確保數據的連接的可靠性，正確性、低時延，這些是比較重要的。

關于移動弱網的文章，可以讀一讀以下幾篇：

《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》

《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》

《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》

Q：您從華為開始進入音頻領域，我相信這個過程中也有其他的機會和誘惑，為什么還會專注在音頻這個領域？相對來說，多媒體技術就已經很窄了，音頻會更小眾，更孤獨。

梁俊斌：剛才提到“孤獨”這個詞很準確，為什么呢？搞技術的人就必須習慣孤獨，享受埋頭鉆研的“孤獨”帶來的愉悅，技術人經常面對挫折而無助的局面，每一次失敗的嘗試讓我們感受到了冰冷的絕望，但內心的光明指引著我們砥礪前行。

為什么選擇音頻？剛開始接觸音頻的時候，我覺得音頻技術可操作性很強。相對于以前在學校里面做的很多底層芯片相關的項目，DSP、ARM、MCU、FPGA等，需要借助別人的專用平臺，在別人提供的最小系統板上或自己設計的PCB上開發，硬件制（電路）板周期長。如果工廠制板工藝環節出現什么問題，例如PCB層間有金屬絲殘留導致短路或不穩定狀況，返工還要考慮外面制板工廠的工期以及芯片供貨周期，有時候芯片要從國外申購就要等好幾周的時間。

而做音頻則方便多了，很簡單，只要你有一臺PC或者手機，你就能錄音，你就能做處理，你就能馬上聽到自己做的東西的效果，整個過程完全可以自己掌控。而且在華為、騰訊公司能夠提供相當不錯的大平臺和優越環境，讓我可以沉下心來搞音頻，所以我就一直堅持下來了。

Q：我也觀察到一個現象，搞多媒體這些技術人，大部分還比較低調的，專注在自己手頭的事情，這個可能也跟這個行業對人的修煉有關系吧。

梁俊斌：（搞多媒體開發）就是要不斷的積累，積淀越深厚才能看得更高更遠。

那時候我在華為做了幾年的管理之后反思，因為在大公司里面做管理，大部分時間都是被支配的，沒有太多的時間可以專心做自己想做的事情。后來自己就做了決定，還是全身心投入到技術研發，做自己想做的事情，這個是最理想的狀態。

Q：音頻技術的發展方向在哪里？比如和AI技術的結合。

梁俊斌：我在學校的時候就開始接觸AI的理論和算法，例如神經網絡、無監督學習和有監督學習等，那時候的機器比現在差太遠了，更沒有適合并行運算的GPU，跑不了很復雜的東西，耗時很長，而且沒有現在那么開放的數據庫可供訓練，所以當時的AI理論技術沒能得到長足發展，也沒有成功的實際應用。回到現在，過了那么多年后，以前冷門的技術現在變成熱門了。現在AI和語音結合得比較緊密，語音識別、聲紋識別、語音合成、AI降噪等等，但處理及存儲的開銷、時延問題，以及AI算法在實際運行中如何做到可觀可控等問題還有待進一步解決。

你提到音頻這一塊是不是越來越小眾了？當下看到的感覺是越來越小，但我們要看未來（的應用）。

目前我們只是做了單聲道、雙聲道的通話應用，未來必然是沉浸式的虛擬現實音視頻體驗，隨著傳感器工藝升級，設備體積進一步微型化，網絡管道的海量帶寬支持，未來我們將可以非常自由的體驗與現實世界無異的虛擬現實世界，這里運用到的3D立體音頻動態建模，實際環境聲場與虛擬聲場的融合交互技術。

另外，隨著便攜傳感器的普及，AI對個人和群體的數據分析，AI會比我們自己更了解自己，例如AI根據外界環境狀況、個人喜好、當前身體的各項檢測指標判別你當下的情緒和心理狀況，可以為你提供更適合當前個人心情、場景環境的音樂，讓你身心更愉悅或者讓你的情緒得到更有效的宣泄。現在也有一些主動降噪的音效設備，放在床邊，能夠主動抑制你的打鼾的聲音，讓你和家人能夠睡得更好，這些都是音頻技術可以看到的未來。

不要局限在自己所做的事情，技術可以在不同的應用場景上得以延展，不同應用場景反過來決定了需要什么樣的技術，什么樣的算法。所以我并不覺得我們沒什么事情可做了，只有我們沒有把場景和用戶需求理解到位，這反而是我們擔心的。倘若我們對用戶需求都不理解，對使用場景不理解，那我們確實沒什么可做的。如果我們搞清楚了用戶的應用場景，我們才能開發出相應的技術，并告知用戶這個技術特性是你所需要的。所以要吃透分析用戶場景和需求，肯定會有很多事情需要我們做的。

Q：我的體會是這樣，我在用英語流利說學英文，非常大的一個難點，就是我在地鐵和公交車上，噪聲很大，這個時候我說同樣的話，評分就會比安靜的環境低很多，他沒辦法根據環境去適應。如果通過陣列麥克風這樣的硬件可以做到降噪，但是普通的手機是沒辦法實現的。

梁俊斌：一般人只有兩個耳朵，如果播放單聲道音源的時候，你可以理解人只用了一個耳朵，因為他兩個耳朵聽到的東西是完全一樣的。

人在聽單聲道的信號的時候，單個耳朵就能抽取出自己感興趣的內容，而忽略干擾信號的部分，這就是雞尾酒會效應，即在一個很繁雜的環境里人都能快速捕獲自己想聽的內容。

相比之下，我們目前還需要借助多個麥克風組成陣列，通過陣列算法來增強某個方向的信號衰弱其它方向的信號，如果需要角度分辨度更高，或者立體空間某個角落的聲音信號則需要更加多的麥克風和更復雜的陣列布局。

所以這個領域的研究就很有趣了，單個人耳完勝我們目前商用的麥克風陣列。很多大牛都在研究這個，還沒有完全攻克，如果這個問題解決了，那普通手機只需要一個麥克風就可以實現人耳相近的效果了。

什么是麥克風陣列？

麥克風陣列(Microphone Array)，從字面上，指的是麥克風的排列。也就是說由一定數目的聲學傳感器(一般是麥克風)組成，用來對聲場的空間特性進行采樣并處理的系統。采用該技術，能利用兩個麥克風接收到聲波的相位之間的差異對聲波進行過濾，能最大限度將環境背景聲音清除掉，只剩下需要的聲波。對于在嘈雜的環境下采用這種配置的設備，能使聽者聽起來很清晰，無雜音。

附錄1：更多音視頻技術文章

[1] 開源實時音視頻技術WebRTC的文章：

《開源實時音視頻技術WebRTC的現狀》

《簡述開源實時音視頻技術WebRTC的優缺點》

《訪談WebRTC標準之父：WebRTC的過去、現在和未來》

《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》

《WebRTC實時音視頻技術的整體架構介紹》

《新手入門：到底什么是WebRTC服務器，以及它是如何聯接通話的？》

《WebRTC實時音視頻技術基礎：基本架構和協議棧》

《淺談開發實時視頻直播平臺的技術要點》

《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》

《基于開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》

《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》

《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》

《實時通信RTC技術棧之：視頻編解碼》

《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》

《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》

《了不起的WebRTC：生態日趨完善，或將實時音視頻技術白菜化》

>> 更多同類文章 ……

[2] 實時音視頻開發的其它精華資料：

《即時通訊音視頻開發（一）：視頻編解碼之理論概述》

《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》

《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》

《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》

《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》

《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》

《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》

《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》

《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》

《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》

《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》

《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》

《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》

《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》

《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》

《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》

《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》

《實時語音聊天中的音頻處理與編碼壓縮技術簡述》

《網易視頻云技術分享：音頻處理與壓縮技術快速入門》

《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》

《基于RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》

《聲網架構師談實時音視頻云的實現難點(視頻采訪)》

《淺談開發實時視頻直播平臺的技術要點》

《還在靠“喂喂喂”測試實時語音通話質量？本文教你科學的評測方法！》

《實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享》

《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》

《如何用最簡單的方法測試你的實時音視頻方案》

《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》

《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》

《移動端實時音視頻直播技術詳解（一）：開篇》

《移動端實時音視頻直播技術詳解（二）：采集》

《移動端實時音視頻直播技術詳解（三）：處理》

《移動端實時音視頻直播技術詳解（四）：編碼和封裝》

《移動端實時音視頻直播技術詳解（五）：推流和傳輸》

《移動端實時音視頻直播技術詳解（六）：延遲優化》

《理論聯系實際：實現一個簡單地基于HTML5的實時視頻直播》

《IM實時音視頻聊天時的回聲消除技術詳解》

《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》

《如何優化傳輸機制來實現實時音視頻的超低延遲？》

《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》

《Android直播入門實踐：動手搭建一套簡單的直播系統》

《網易云信實時視頻直播在TCP數據傳輸層的一些優化思路》

《實時音視頻聊天技術分享：面向不可靠網絡的抗丟包編解碼器》

《P2P技術如何將實時視頻直播帶寬降低75%？》

《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》

《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》

《微信團隊分享：微信每日億次實時音視頻聊天背后的技術解密》

《近期大熱的實時直播答題系統的實現思路與技術難點分享》

《福利貼：最全實時音視頻開發要用到的開源工程匯總》

《七牛云技術分享：使用QUIC協議實現實時視頻直播0卡頓！》

《實時音視頻聊天中超低延遲架構的思考與技術實踐》

《理解實時音視頻聊天中的延時問題一篇就夠》

《實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序》

《寫給小白的實時音視頻技術入門提綱》

《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》

《騰訊技術分享：微信小程序音視頻技術背后的故事》

《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》

>> 更多同類文章 ……

附錄2：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技術詳解》

《騰訊技術分享：微信小程序音視頻技術背后的故事》

《騰訊資深架構師干貨總結：一文讀懂大型分布式系統設計的方方面面》

《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》

>> 更多同類文章 ……

（本文同步發布于：http://www.52im.net/thread-1828-1-1.html）