1、引言
微信小程序自2017年1月9日正式對外公布以來，越來越受到關(guān)注和重視，小程序上的各種技術(shù)體驗(yàn)也越來越豐富。而音視頻作為高速移動網(wǎng)絡(luò)時代下增長最快的應(yīng)用形式之一，在微信小程序中也當(dāng)然不能錯過。本文來自騰訊視頻云終端技術(shù)總監(jiān)rexchang（常青）的技術(shù)分享，講述的是微信小程序中音視頻技術(shù)構(gòu)思、設(shè)計(jì)和實(shí)現(xiàn)等方方面的內(nèi)容，希望能為你的音視頻技術(shù)實(shí)踐帶來啟發(fā)。
如果您能微信小程序開發(fā)沒什么了解，可以從這篇微信官方的《小程序開發(fā)簡易教程》開始。
學(xué)習(xí)交流：
- 即時通訊開發(fā)交流3群：185926912[推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-1799-1-1.html）
2、關(guān)于作者
rexchang（常青）：騰訊視頻云終端技術(shù)總監(jiān)，2008 年畢業(yè)加入騰訊，一直從事客戶端研發(fā)相關(guān)工作，先后參與過 PC QQ、手機(jī)QQ、QQ物聯(lián) 等產(chǎn)品項(xiàng)目，目前在騰訊視頻云團(tuán)隊(duì)負(fù)責(zé)音視頻終端解決方案的優(yōu)化和落地工作。
3、一次偶然的合作
▲ 騰訊云與微信團(tuán)隊(duì)合作達(dá)成
2016年微信開始啟動小程序內(nèi)測之前，騰訊內(nèi)部的各個團(tuán)隊(duì)就已經(jīng)開始接到消息。我們每個人都能預(yù)感到小程序?qū)σ苿討?yīng)用場景產(chǎn)生很大的改變。但在當(dāng)時，我也是剛加入騰訊視頻云團(tuán)隊(duì)不久，對于這樣的信息更多的是關(guān)注，而并無太多細(xì)致的思考。
2017年伊始，隨著大量客戶的咨詢，我以及我所在的騰訊視頻云團(tuán)隊(duì)都開始意識到這里的需求特別的旺盛。但由于精力有限，以“小團(tuán)隊(duì)大成績”著稱的微信工程師團(tuán)隊(duì)很難有精力覆蓋所有的應(yīng)用場景，在音視頻這里，小程序僅提供了一些基礎(chǔ)的采集和播放能力，比如大家最為熟知的 video 標(biāo)簽就是采用了系統(tǒng)播放器來實(shí)現(xiàn)，所以只能支持 HLS 高延時直播和視頻點(diǎn)播功能。
而就在此時，騰訊視頻云的 SDK 產(chǎn)品在經(jīng)過了一年多的打磨優(yōu)化之后，已經(jīng)像是二戰(zhàn)初期的零式戰(zhàn)機(jī)，隨時準(zhǔn)備“砍瓜切菜”。這里和合作機(jī)會雖然不定，但我們團(tuán)隊(duì)依然坐上了從深圳總部開往廣州 T.I.T 的班車。
▲ 廣州T.I.T創(chuàng)意園，微信總部所在地
經(jīng)過多次的溝通，以及 jianx 的努力幫助下，這個合作雖然偶然且充滿了各種不確定，但最終達(dá)成。
幕后：音視頻小程序誕生在2017年4月一輛從深圳開往廣州的C7172列車上
▲ 本文作者常青帶著小程序音視頻的方案乘坐動車前往微信事業(yè)群
4、技術(shù)的挑戰(zhàn)
在音視頻應(yīng)用場景下，兩個團(tuán)隊(duì)能夠達(dá)成合作自然是個好事情，但是微信的市場地位也決定了這是一個不容兒戲的戰(zhàn)場。
所以我們所面臨的挑戰(zhàn)也異常嚴(yán)峻：
1）接口必須簡單易用，最好一兩個標(biāo)簽就能解決問題；
2）滿足多種應(yīng)用場景，既要支持直播又要能夠支持實(shí)時視頻通話；
3）功能必須可擴(kuò)展，開發(fā)者可以根據(jù)自身的需要構(gòu)建出各種個性化應(yīng)用場景；
4）可維護(hù)性好，開發(fā)者能夠自助排查一些技術(shù)問題，而不需要本身是個音視頻專家；
5）安裝包體積增量足夠小，不然微信的安裝包體積控住不住。
除了高標(biāo)準(zhǔn)的要求以外，時間也是一個非常不利的因素。整個項(xiàng)目留給我們可以證明自身能力的時間只有兩周，在短短兩周的時間里，我們需要在一個 G2C 項(xiàng)目落地且成功通過產(chǎn)品演示和方案驗(yàn)收。
5、化繁為簡
面對這些挑戰(zhàn)，我想到了蘇聯(lián)卡拉什尼科夫所設(shè)計(jì)的名槍 AK-47 ：
說 AK-47 是世界上最成功的單兵武器一點(diǎn)也不為過，這把槍全世界一共生產(chǎn)了約一億支。它具有不俗的殺傷力和極為優(yōu)秀的可靠性。從不卡殼，不易損壞，不管是沙漠還是雨林，都能穩(wěn)定地傾瀉火力，并且操作還非常簡單。
之所以這么成功，源于其所貫徹的簡單實(shí)用的設(shè)計(jì)理念：回轉(zhuǎn)式閉鎖確保了安全性，杜絕了隨機(jī)事故的可能性；結(jié)構(gòu)簡單易拆卸，因此要生產(chǎn)它并不需要特別精密的加工技術(shù)，也不需要投資巨大的生產(chǎn)設(shè)備，甚至一個普通小作坊就能開工生產(chǎn)。
沒錯，化繁為簡，追求簡單可靠，這就是我們需要達(dá)成的目標(biāo)。
達(dá)成上述的技術(shù)目標(biāo)并不容易，需要我們團(tuán)隊(duì)一步一步的攻克技術(shù)難關(guān)。
6、攻克技術(shù)難關(guān)之上行和下行
首先，我們要對騰訊視頻云現(xiàn)有的音視頻體系進(jìn)行拆解和抽象，也就是把整個體系打散成一個個積木，其中最重要的兩塊就是：音視頻上行（push）和音視頻下行（play）。
6.1 音視頻上行（PUSH）
就是把自己手機(jī)上的聲音和畫面實(shí)時的上傳到云端。我們將這部分能力用視頻云 SDK 進(jìn)行實(shí)現(xiàn)，并封裝成一個叫做 的標(biāo)簽。
SDK 內(nèi)部實(shí)現(xiàn)機(jī)制如上圖所示：首先，我們要對攝像頭的畫面進(jìn)行捕獲，對麥克風(fēng)的聲音進(jìn)行采集。但是，原生采集和捕獲的畫面和聲音是需要進(jìn)行預(yù)處理的，直接采集的畫面可能有很多噪點(diǎn)，所以我們要進(jìn)行圖像降噪；比如， 原生采集的人像里，皮膚可能并不符合人們的預(yù)期，所以我們需要進(jìn)行磨皮和美顏；直接采集的聲音可能也有很多的環(huán)境噪音，所以我們需要進(jìn)行前景和后景音的分離然后進(jìn)行底噪抑制。
經(jīng)過預(yù)處理之后的畫面和聲音相比于原始采集的一般會有較大改善，因?yàn)樗械念A(yù)處理都是以“討好”人類的視聽體驗(yàn)為目的，所以這一看似不起眼的部分會吸引很多公司在其上做不少的技術(shù)投入。舉個身邊的例子，以 LCD 平板電視為例，SONY 的 LCD 產(chǎn)品線都沒有自家的液晶面板（以臺灣和大陸液晶面板為主），卻能在總體效果上一直領(lǐng)先其它公司，其背后的秘密就是在圖像處理（基于圖像數(shù)據(jù)庫做超分辨率顯示）和背光技術(shù)（所有動物的眼睛都是對亮度最為敏感）上的不間斷的積累和投入。
畫面和聲音都經(jīng)過“粉飾”之后，就可以送給編碼器進(jìn)行編碼壓縮了。編碼器的工作是將一張張的畫面和一段段的聲音壓縮成 0101001... 的二進(jìn)制數(shù)據(jù)，而壓縮后的體積要遠(yuǎn)小于壓縮前。最后要做的工作就是將編碼后的數(shù)據(jù)通過網(wǎng)絡(luò)模塊發(fā)送出去。在在線直播場景中，一般采用的網(wǎng)絡(luò)協(xié)議都是基于TCP的，而在實(shí)時通話場景中，所采用的網(wǎng)絡(luò)協(xié)議則是 UDP 為主。
6.2 音視頻下行（PLAY）
也叫播放，就是從云端把編碼后的音視頻數(shù)據(jù)實(shí)時下載下來并實(shí)時的播放，這樣一來，您就能看到遠(yuǎn)程的畫面，聽到遠(yuǎn)程的聲音。同樣的，我們將這部分能力用視頻云 SDK 進(jìn)行實(shí)現(xiàn)，并封裝成一個叫做 的標(biāo)簽。
SDK 內(nèi)部實(shí)現(xiàn)機(jī)制如上圖所示：來自云端的數(shù)據(jù)會直接送給網(wǎng)絡(luò)模塊，但網(wǎng)絡(luò)不是完美的，總會有時快時慢的波動，甚至?xí)锌赡馨l(fā)生阻塞和閃斷。如果服務(wù)器來一段數(shù)據(jù)， SDK 就播一段數(shù)據(jù)，那么網(wǎng)絡(luò)稍微一波動，畫面和聲音就會表現(xiàn)出卡頓。我們采用抖動緩沖（VideoJitterBuffer）技術(shù)解決這個問題，就像是為網(wǎng)絡(luò)過來的數(shù)據(jù)準(zhǔn)備一個小的蓄水池，音視頻數(shù)據(jù)先在這里暫存一小會兒再送去播放，這樣就可以在網(wǎng)絡(luò)不穩(wěn)定時有一定的“應(yīng)急”數(shù)據(jù)可以使用。
數(shù)據(jù)經(jīng)過緩沖以后，就可以送給解碼器進(jìn)行解碼，解碼就是把壓縮后的音視頻數(shù)據(jù)還原成圖像和聲音，然后進(jìn)行渲染和播放。我們采用了 openGL 進(jìn)行畫面的渲染，使用 iOS 和 Android 的系統(tǒng)接口來播放聲音。
6.3 信號放大器
有了這兩個簡單的標(biāo)簽，我們就可以進(jìn)行初步的組合，構(gòu)建出第一個最簡單的應(yīng)用場景：在線直播。
在線直播是一個非常經(jīng)典的單向音視頻場景，您只需要簡單的將兩個標(biāo)簽組合在一起即可， 負(fù)責(zé)將本地畫面和聲音實(shí)時上傳到騰訊云， 則負(fù)責(zé)從云端實(shí)時拉取音視頻流。
如果是簡單的一路上行 + 一路下行，那么我們隨便搭建一個中轉(zhuǎn)服務(wù)器就可以解決問題了，但這樣只能在很小的范圍內(nèi)實(shí)現(xiàn)高質(zhì)量的直播服務(wù)，真正要做到高并發(fā)和流暢無卡頓，就需要一個強(qiáng)大的視頻云。
視頻云在這里的作用就像一個**信號放大器**，它負(fù)責(zé)將來自 的一路音視頻進(jìn)行放大，擴(kuò)散到全國各地，讓每一個 都能在離自己比較近的云服務(wù)器上拉取到實(shí)時且流暢的音視頻流。由于原理簡單、穩(wěn)定可靠且支持幾百萬同時在線的高并發(fā)觀看，所以從在線教育到體育賽事，從游戲直播到花椒映客，都是基于這種技術(shù)實(shí)現(xiàn)的。
但在線直播方案只能應(yīng)用于解決單向音視頻問題，因?yàn)樗袀€明顯的問題，就是延時一般都是在 2秒 - 5秒左右，這是使用 標(biāo)簽配合騰訊云視頻云可以達(dá)到的效果。如果是video標(biāo)簽，這個延時會更長，可以到 20 秒以上，那么在一些對時延要求很苛刻的場景下就不再適用了。
7、攻克技術(shù)難關(guān)之把延遲降低
在安防監(jiān)控的場景里，家用 IP 攝像頭一般都帶有云臺旋轉(zhuǎn)的功能，也就是攝像頭的指向會跟隨遠(yuǎn)程的遙控進(jìn)行轉(zhuǎn)動，如果畫面延時比較大，那么觀看端按下操控按鈕到看到畫面運(yùn)動所需要等待的時間就會比較長，這樣用戶體驗(yàn)就會特別不好。
再比如 2017 非常流行的在線夾娃娃場景，如果遠(yuǎn)程玩家視頻畫面的延時非常高，那么遠(yuǎn)程操控娃娃機(jī)就變得不太可能，沒有誰能真正抓到娃娃。
既然要達(dá)到這么低的要求，普通的在線直播技術(shù)就不再適用了，我們需要新引入兩個新的科技點(diǎn)：**延時控制** 和 **UDP加速**。
延時控制：
網(wǎng)絡(luò)不是完美的，網(wǎng)絡(luò)是波動的。在有波動的網(wǎng)絡(luò)下，服務(wù)器上的音視頻數(shù)據(jù)并不是穩(wěn)穩(wěn)的來到您的手機(jī)上，而是忽快忽慢。慢的時候您可能會看到卡頓，快的時候就會產(chǎn)生堆積，而堆積的后果就是延時的增加。所以，我們需要采用延遲控制技術(shù)，它的原理很簡單，當(dāng)網(wǎng)絡(luò)慢的時候就播的慢一點(diǎn)，當(dāng)網(wǎng)絡(luò)快的時候就播得快一點(diǎn)，這樣就起到一定的緩沖作用。當(dāng)然，真正實(shí)現(xiàn)時就會發(fā)現(xiàn)，聲音是個很不聽話的“孩子”，要處理好聲音的效果是一個非常高難度的技術(shù)活。
UDP加速：
既然網(wǎng)絡(luò)不那么完美，總是時快時慢，那我們是不是可以改善一下呢？在經(jīng)典的單向音視頻方案中，一般采用的都是 TCP 協(xié)議，因?yàn)樗唵慰煽壳壹嫒菪詷O好。然而 TCP 的擁塞控制特別注重公平，天然就有時快時慢的壞毛病，所以我們需要用 UDP 協(xié)議替代之，相比于設(shè)計(jì)目標(biāo)定位于可靠傳輸?shù)?TCP 協(xié)議，UDP 可以做得更穩(wěn)且更快。
我們將 延時控制和 UDP 加速技術(shù)加入到 標(biāo)簽里，可以將端到端的延時控制在 500ms 左右。這對于操作延時要求比較苛刻的場景，就可以滿足需求了。
8、攻克技術(shù)難關(guān)之單向變雙向
有了單向低延時技術(shù)，那么雙向視頻通話自然也就比較簡單了，只需要通話的雙方 A 和 B 各自拉通一路低延時鏈路就可以了。
比如在車險(xiǎn)定損的場景里，遇險(xiǎn)的車主通過小程序呼叫保險(xiǎn)公司，這個時候保險(xiǎn)公司內(nèi)部的定損客服只要通過一路低延時的鏈路就可以看到車子的出險(xiǎn)情況。但是僅僅這樣還不夠，視頻內(nèi)容跟圖片一樣，都容易被實(shí)現(xiàn)偽造和作假。所以定損員就需要有一路視頻同樣到達(dá)車主那里，這樣兩路音視頻同時連通，就構(gòu)成了一個典型的視頻通話場景。由于車主和定損員可以通過視頻進(jìn)行交流，因此造假騙保的風(fēng)險(xiǎn)就被極大地降低了。
雖然這樣說是沒錯，但實(shí)現(xiàn)上可不是那么簡單的。恰恰相反，它非常困難，因?yàn)槲覀冞€需要引入額外的很多科技點(diǎn)：
噪聲消除：噪聲抑制的目的是將用戶所處環(huán)境里的背景噪音去除掉，好的噪聲抑制是回音消除的前提，否則聲學(xué)模塊無法從采集的聲音辨別出哪些是回聲，哪些是應(yīng)該被保留的聲音。
回音抑制：在雙向視頻通話中，用戶自己手機(jī)的麥克風(fēng)會把喇叭里播放的聲音再次記錄下來，如果不將其抹除掉，這些聲音會被反送給對端的用戶，從而形成回聲。
Qos流控：網(wǎng)絡(luò)不可能一直都很完美，尤其是中國大陸地區(qū)的上行網(wǎng)速一直都有政策限制。Qos流控的作用就是預(yù)測用戶當(dāng)前的上行網(wǎng)速，并估算出一個適當(dāng)?shù)臄?shù)值反饋給編碼器，這樣一來，編碼器要送出的音視頻數(shù)據(jù)就不會超過當(dāng)前網(wǎng)絡(luò)的傳輸能力，從而減少卡頓的發(fā)生。
丟包恢復(fù)：再好的網(wǎng)絡(luò)也難免會有丟包的情況，尤其是 WiFi 和 4G 等無線網(wǎng)絡(luò)，由于傳輸介質(zhì)本身就不是可以獨(dú)享的，所以一旦受到干擾，或者高速運(yùn)動都會產(chǎn)生大量的丟包，這時就需要引入一些丟包恢復(fù)技術(shù)，將失去的數(shù)據(jù)盡量補(bǔ)救回來。
以上四個科技點(diǎn)，我們也加入到了 和 標(biāo)簽中，并給他們賦予了一個新的模式 RTC（ Real Time Chatting 的 首字母縮寫，有點(diǎn) Chenglish 的味道），這才真正把實(shí)時音視頻通話搞定。
你看，要保持功能到位，又不能跳出標(biāo)簽這種簡單易用的設(shè)計(jì)風(fēng)格，這不容易吧。實(shí)際上這里的四個科技點(diǎn)實(shí)在是太難了，需要很多年的技術(shù)積累和沉淀，以至于我們也不是現(xiàn)用現(xiàn)做的。正所謂站在巨人的肩膀上才能看得更遠(yuǎn)，這里的技術(shù)能力是由騰訊音視頻實(shí)驗(yàn)室的“天籟”引擎所實(shí)現(xiàn)的。
9、攻克技術(shù)難關(guān)之雙向變多人
既然雙人視頻通話已經(jīng)搞定了，是不是多人也就照葫蘆畫瓢就可以了？您看，我們只需要將 A 和 B 之間的 url 置換，變成 A、B、C 甚至更多人之間的 url 置換，不就可以了嗎？
思路依然正確，但是真正要將功能做到好用且成熟，僅依靠簡單的 url 交換是非常粗糙的。我們需要繼續(xù)引入額外的兩個科技點(diǎn)。
房間管理：
以上圖所示的 A B C 之間的多人視頻場景為例，要讓每一個人都很清楚其它人的狀態(tài)（比如播放url，以及當(dāng)前是否有上行等等），這個事情可是非常困難的，搞不好就容易出現(xiàn)各方信息不對齊。對于更復(fù)雜一點(diǎn)的情況，比如當(dāng)有第四個人 D 進(jìn)來的時候，或者第五個人 E 進(jìn)來又出去的時候，這種信息同步幾乎就是一場噩夢。
最好的辦法就是把參會人的狀態(tài)和信息都收攏在服務(wù)器端，構(gòu)造一個 **房間** 的概念，這樣就可以確保參會人都能從服務(wù)端獲得同樣的信息，而不需要各自去維護(hù)。
通知系統(tǒng)：
當(dāng)有新的參與者進(jìn)入房間，或者有人離開時，就需要對房間里的人進(jìn)行信息廣播，這就需要一個不錯的 IM 系統(tǒng)負(fù)責(zé)收發(fā)消息。比如當(dāng) D 進(jìn)入時，就可以向房間內(nèi)的其它成員廣播這個 “I'm coming” 的事件，這樣 A B C 就可以在自己的 UI 上展示 D 的視頻畫面了。
加入房間管理和 通知系統(tǒng)以后，我們就可以將 和 和微信小程序的 websocket 等基礎(chǔ)能力組合在一起，構(gòu)建各種功能強(qiáng)大、邏輯復(fù)雜的小程序應(yīng)用。
10、一路走來
一路走來，大家可以看到我們在小程序音視頻的技術(shù)體系上所做的種種努力可以用如下的技術(shù)圖譜勾勒出來。
總結(jié)一下，我們的實(shí)現(xiàn)思路就是：
1）首先是化繁為簡，將所有的音視頻解決方案拆解成兩個基礎(chǔ)行為：上行和下行，并通過兩個標(biāo)簽 和 的簡單組合，實(shí)現(xiàn)最基本的在線直播功能；
2）之后是通過加速線路和延時控制，將一路音視頻的時延縮短到 500ms 以內(nèi)；
3）再之后，我們通過引入噪聲抑制和回聲消除等聲學(xué)處理模塊，讓一路變兩路成為了可能，這也就構(gòu)成一個最簡單的視頻通話能力；
4）最后，我們又通過加入房間服務(wù)和狀態(tài)同步通知，將雙路音視頻變成了多路音視頻，從而將應(yīng)用范圍進(jìn)一步擴(kuò)大。
圖中的 UI 截圖使我們騰訊視頻云小程序Demo的界面截圖，大家通過在微信小程序里搜索“騰訊視頻云”就可以體驗(yàn)上述基礎(chǔ)功能了。
如果您希望自己也動手來試一試，不妨看一下我們的技術(shù)文檔：
小程序入門導(dǎo)讀：https://cloud.tencent.com/document/product/454/12517
標(biāo)簽使用指引：https://cloud.tencent.com/document/product/454/12518
標(biāo)簽使用指引：https://cloud.tencent.com/document/product/454/12519
雙人或多人音視頻：https://cloud.tencent.com/document/product/454/15364
直播+連麥：https://cloud.tencent.com/document/product/454/15368
WebRTC互通：https://cloud.tencent.com/document/product/454/16914
常見問題：https://cloud.tencent.com/document/product/454/13037
附錄1：微信、QQ的文章匯總
[1] QQ、微信團(tuán)隊(duì)原創(chuàng)技術(shù)文章：
《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》
《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》
《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》
《微信團(tuán)隊(duì)分享：微信移動端的全文檢索多音字問題解決方案》
《騰訊技術(shù)分享：Android版手機(jī)QQ的緩存監(jiān)控與優(yōu)化實(shí)踐》
《微信團(tuán)隊(duì)分享：iOS版微信的高性能通用key-value組件技術(shù)實(shí)踐》
《微信團(tuán)隊(duì)分享：iOS版微信是如何防止特殊字符導(dǎo)致的炸群、APP崩潰的？》
《騰訊技術(shù)分享：Android手Q的線程死鎖監(jiān)控系統(tǒng)技術(shù)實(shí)踐》
《微信團(tuán)隊(duì)原創(chuàng)分享：iOS版微信的內(nèi)存監(jiān)控系統(tǒng)技術(shù)實(shí)踐》
《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》
《iOS后臺喚醒實(shí)戰(zhàn)：微信收款到賬語音提醒技術(shù)總結(jié)》
《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》
《微信團(tuán)隊(duì)分享：視頻圖像的超分辨率技術(shù)原理和應(yīng)用場景》
《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時音視頻聊天背后的技術(shù)解密》
《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》
《QQ音樂團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》
《騰訊團(tuán)隊(duì)分享：手機(jī)QQ中的人臉識別酷炫動畫效果實(shí)現(xiàn)詳解》
《騰訊團(tuán)隊(duì)分享 ：一次手Q聊天界面中圖片顯示bug的追蹤過程分享》
《微信團(tuán)隊(duì)分享：微信Android版小視頻編碼填過的那些坑》
《微信手機(jī)端的本地?cái)?shù)據(jù)全文檢索優(yōu)化之路》
《企業(yè)微信客戶端中組織架構(gòu)數(shù)據(jù)的同步更新方案優(yōu)化實(shí)戰(zhàn)》
《微信團(tuán)隊(duì)披露：微信界面卡死超級bug“15。。。。”的來龍去脈》
《QQ 18年：解密8億月活的QQ后臺服務(wù)接口隔離技術(shù)》
《月活8.89億的超級IM微信是如何進(jìn)行Android端兼容測試的》
《以手機(jī)QQ為例探討移動端IM中的“輕應(yīng)用”》
《一篇文章get微信開源移動端數(shù)據(jù)庫組件WCDB的一切！》
《微信客戶端團(tuán)隊(duì)負(fù)責(zé)人技術(shù)訪談：如何著手客戶端性能監(jiān)控和優(yōu)化》
《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計(jì)實(shí)踐》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信的臃腫之困與模塊化實(shí)踐之路》
《微信后臺團(tuán)隊(duì)：微信后臺異步消息隊(duì)列的優(yōu)化升級實(shí)踐分享》
《微信團(tuán)隊(duì)原創(chuàng)分享：微信客戶端SQLite數(shù)據(jù)庫損壞修復(fù)實(shí)踐》
《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（下篇）》
《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（上篇）》
《微信Mars：微信內(nèi)部正在使用的網(wǎng)絡(luò)層封裝庫，即將開源》
《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》
《開源libco庫：單機(jī)千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]》
《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺保活實(shí)戰(zhàn)分享(進(jìn)程保活篇)》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺保活實(shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》
《Android版微信從300KB到30MB的技術(shù)演進(jìn)(PPT講稿) [附件下載]》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信從300KB到30MB的技術(shù)演進(jìn)》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(PPT講稿) [附件下載]》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《微信海量用戶背后的后臺系統(tǒng)存儲架構(gòu)(視頻+PPT) [附件下載]》
《微信異步化改造實(shí)踐：8億月活、單機(jī)千萬連接背后的后臺解決方案》
《微信朋友圈海量技術(shù)之道PPT [附件下載]》
《微信對網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》
《一份微信后臺技術(shù)架構(gòu)的總結(jié)性筆記》
《架構(gòu)之道：3個程序員成就微信朋友圈日均10億發(fā)布量[有視頻]》
《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》
《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（二）》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android內(nèi)存泄漏監(jiān)控和優(yōu)化技巧總結(jié)》
《全面總結(jié)iOS版微信升級iOS9遇到的各種“坑”》
《微信團(tuán)隊(duì)原創(chuàng)資源混淆工具：讓你的APK立減1M》
《微信團(tuán)隊(duì)原創(chuàng)Android資源混淆工具：AndResGuard [有源碼]》
《Android版微信安裝包“減肥”實(shí)戰(zhàn)記錄》
《iOS版微信安裝包“減肥”實(shí)戰(zhàn)記錄》
《移動端IM實(shí)踐：iOS版微信界面卡頓監(jiān)測方案》
《微信“紅包照片”背后的技術(shù)難題》
《移動端IM實(shí)踐：iOS版微信小視頻功能技術(shù)方案實(shí)錄》
《移動端IM實(shí)踐：Android版微信如何大幅提升交互性能（一）》
《移動端IM實(shí)踐：Android版微信如何大幅提升交互性能（二）》
《移動端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》
《移動端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》
《移動端IM實(shí)踐：谷歌消息推送服務(wù)(GCM)研究（來自微信）》
《移動端IM實(shí)踐：iOS版微信的多設(shè)備字體適配方案探討》
《信鴿團(tuán)隊(duì)原創(chuàng)：一起走過 iOS10 上消息推送(APNS)的坑》
《騰訊信鴿技術(shù)分享：百億級實(shí)時消息推送的實(shí)戰(zhàn)經(jīng)驗(yàn)》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（上篇）》
《IPv6技術(shù)詳解：基本概念、應(yīng)用現(xiàn)狀、技術(shù)實(shí)踐（下篇）》
《騰訊TEG團(tuán)隊(duì)原創(chuàng)：基于MySQL的分布式數(shù)據(jù)庫TDSQL十年鍛造經(jīng)驗(yàn)分享》
《微信多媒體團(tuán)隊(duì)訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》
《了解iOS消息推送一文就夠：史上最全iOS Push技術(shù)詳解》
《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》
>> 更多同類文章 ……
[2] 有關(guān)QQ、微信的技術(shù)故事：
《技術(shù)往事：微信估值已超5千億，雷軍曾有機(jī)會收編張小龍及其Foxmail》
《QQ和微信兇猛成長的背后：騰訊網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的這些年》
《閑話即時通訊：騰訊的成長史本質(zhì)就是一部QQ成長史》
《2017微信數(shù)據(jù)報(bào)告：日活躍用戶達(dá)9億、日發(fā)消息380億條》
《騰訊開發(fā)微信花了多少錢？技術(shù)難度真這么大？難在哪？》
《技術(shù)往事：創(chuàng)業(yè)初期的騰訊——16年前的冬天，誰動了馬化騰的代碼》
《技術(shù)往事：史上最全QQ圖標(biāo)變遷過程，追尋IM巨人的演進(jìn)歷史》
《技術(shù)往事：“QQ群”和“微信紅包”是怎么來的？》
《開發(fā)往事：深度講述2010到2015，微信一路風(fēng)雨的背后》
《開發(fā)往事：微信千年不變的那張閃屏圖片的由來》
《開發(fā)往事：記錄微信3.0版背后的故事（距微信1.0發(fā)布9個月時）》
《一個微信實(shí)習(xí)生自述：我眼中的微信開發(fā)團(tuán)隊(duì)》
《首次揭秘：QQ實(shí)時視頻聊天背后的神秘組織》
《為什么說即時通訊社交APP創(chuàng)業(yè)就是一個坑？》
《微信七年回顧：歷經(jīng)多少質(zhì)疑和差評，才配擁有今天的強(qiáng)大》
《前創(chuàng)始團(tuán)隊(duì)成員分享：盤點(diǎn)微信的前世今生——微信成功的必然和偶然》
《即時通訊創(chuàng)業(yè)必讀：解密微信的產(chǎn)品定位、創(chuàng)新思維、設(shè)計(jì)法則等》
>> 更多同類文章 ……
附錄2：更多音視頻開發(fā)資料
《即時通訊音視頻開發(fā)（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發(fā)（二）：視頻編解碼之?dāng)?shù)字視頻介紹》
《即時通訊音視頻開發(fā)（三）：視頻編解碼之編碼基礎(chǔ)》
《即時通訊音視頻開發(fā)（四）：視頻編解碼之預(yù)測技術(shù)介紹》
《即時通訊音視頻開發(fā)（五）：認(rèn)識主流視頻編碼技術(shù)H.264》
《即時通訊音視頻開發(fā)（六）：如何開始音頻編解碼技術(shù)的學(xué)習(xí)》
《即時通訊音視頻開發(fā)（七）：音頻基礎(chǔ)及編碼原理入門》
《即時通訊音視頻開發(fā)（八）：常見的實(shí)時語音通訊編碼標(biāo)準(zhǔn)》
《即時通訊音視頻開發(fā)（九）：實(shí)時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發(fā)（十）：實(shí)時語音通訊的回音消除技術(shù)詳解》
《即時通訊音視頻開發(fā)（十一）：實(shí)時語音通訊丟包補(bǔ)償技術(shù)詳解》
《即時通訊音視頻開發(fā)（十二）：多人實(shí)時音視頻聊天架構(gòu)探討》
《即時通訊音視頻開發(fā)（十三）：實(shí)時視頻編碼H.264的特點(diǎn)與優(yōu)勢》
《即時通訊音視頻開發(fā)（十四）：實(shí)時音視頻數(shù)據(jù)傳輸協(xié)議介紹》
《即時通訊音視頻開發(fā)（十五）：聊聊P2P與實(shí)時音視頻的應(yīng)用情況》
《即時通訊音視頻開發(fā)（十六）：移動端實(shí)時音視頻開發(fā)的幾個建議》
《即時通訊音視頻開發(fā)（十七）：視頻編碼H.264、VP8的前世今生》
《實(shí)時語音聊天中的音頻處理與編碼壓縮技術(shù)簡述》
《網(wǎng)易視頻云技術(shù)分享：音頻處理與壓縮技術(shù)快速入門》
《學(xué)習(xí)RFC3550：RTP/RTCP實(shí)時傳輸協(xié)議基礎(chǔ)知識》
《基于RTMP數(shù)據(jù)傳輸協(xié)議的實(shí)時流媒體技術(shù)研究（論文全文）》
《聲網(wǎng)架構(gòu)師談實(shí)時音視頻云的實(shí)現(xiàn)難點(diǎn)(視頻采訪)》
《淺談開發(fā)實(shí)時視頻直播平臺的技術(shù)要點(diǎn)》
《還在靠“喂喂喂”測試實(shí)時語音通話質(zhì)量？本文教你科學(xué)的評測方法！》
《實(shí)現(xiàn)延遲低于500毫秒的1080P實(shí)時音視頻直播的實(shí)踐分享》
《移動端實(shí)時視頻直播技術(shù)實(shí)踐：如何做到實(shí)時秒開、流暢不卡》
《如何用最簡單的方法測試你的實(shí)時音視頻方案》
《技術(shù)揭秘：支持百萬級粉絲互動的Facebook實(shí)時視頻直播》
《簡述實(shí)時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端實(shí)時音視頻直播技術(shù)詳解（一）：開篇》
《移動端實(shí)時音視頻直播技術(shù)詳解（二）：采集》
《移動端實(shí)時音視頻直播技術(shù)詳解（三）：處理》
《移動端實(shí)時音視頻直播技術(shù)詳解（四）：編碼和封裝》
《移動端實(shí)時音視頻直播技術(shù)詳解（五）：推流和傳輸》
《移動端實(shí)時音視頻直播技術(shù)詳解（六）：延遲優(yōu)化》
《理論聯(lián)系實(shí)際：實(shí)現(xiàn)一個簡單地基于HTML5的實(shí)時視頻直播》
《IM實(shí)時音視頻聊天時的回聲消除技術(shù)詳解》
《淺談實(shí)時音視頻直播中直接影響用戶體驗(yàn)的幾項(xiàng)關(guān)鍵技術(shù)指標(biāo)》
《如何優(yōu)化傳輸機(jī)制來實(shí)現(xiàn)實(shí)時音視頻的超低延遲？》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《Android直播入門實(shí)踐：動手搭建一套簡單的直播系統(tǒng)》
《網(wǎng)易云信實(shí)時視頻直播在TCP數(shù)據(jù)傳輸層的一些優(yōu)化思路》
《實(shí)時音視頻聊天技術(shù)分享：面向不可靠網(wǎng)絡(luò)的抗丟包編解碼器》
《P2P技術(shù)如何將實(shí)時視頻直播帶寬降低75%？》
《專訪微信視頻技術(shù)負(fù)責(zé)人：微信實(shí)時視頻聊天技術(shù)的演進(jìn)》
《騰訊音視頻實(shí)驗(yàn)室：使用AI黑科技實(shí)現(xiàn)超低碼率的高清實(shí)時視頻聊天》
《微信團(tuán)隊(duì)分享：微信每日億次實(shí)時音視頻聊天背后的技術(shù)解密》
《近期大熱的實(shí)時直播答題系統(tǒng)的實(shí)現(xiàn)思路與技術(shù)難點(diǎn)分享》
《福利貼：最全實(shí)時音視頻開發(fā)要用到的開源工程匯總》
《七牛云技術(shù)分享：使用QUIC協(xié)議實(shí)現(xiàn)實(shí)時視頻直播0卡頓！》
《實(shí)時音視頻聊天中超低延遲架構(gòu)的思考與技術(shù)實(shí)踐》
《理解實(shí)時音視頻聊天中的延時問題一篇就夠》
《實(shí)時視頻直播客戶端技術(shù)盤點(diǎn)：Native、HTML5、WebRTC、微信小程序》
《寫給小白的實(shí)時音視頻技術(shù)入門提綱》
《微信多媒體團(tuán)隊(duì)訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》
《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-1799-1-1.html）