本篇文章內(nèi)容來自2016年TOP100summitQQ空間客戶端研發(fā)總監(jiān) 騰訊 王輝的案例分享。
編輯：Cynthia
王輝：騰訊SNG社交平臺部研發(fā)總監(jiān)、騰訊QQ空間移動客戶端技術(shù)負(fù)責(zé)人高級工程師。09年起負(fù)責(zé)QQ空間技術(shù)研發(fā)，經(jīng)歷從Web時代到移動客戶端技術(shù)的轉(zhuǎn)變拘荡，在Web、移動終端上都有不錯的技術(shù)積累撬陵。
導(dǎo)讀：移動互聯(lián)網(wǎng)飛速發(fā)展珊皿，2016年，社交網(wǎng)絡(luò)對視頻技術(shù)的應(yīng)用得到爆發(fā)式的增長袱结，短視頻亮隙、視頻直播、視頻濾鏡垢夹、視頻人臉動效溢吻、音樂、K歌果元、變聲促王、連麥等功能陸續(xù)在產(chǎn)品中上線，如何在快速上線功能的同時而晒，保證穩(wěn)定流暢的體驗蝇狼，成為挑戰(zhàn)。
主要面臨的挑戰(zhàn)如下：
1倡怎、復(fù)雜的網(wǎng)絡(luò)環(huán)境下迅耘，如何保證視頻播放的成功率，如何保證直播的流暢度监署，減少卡頓颤专？
2、體驗上钠乏，如何保證快速流暢的播放體驗栖秕，如何實現(xiàn)直播秒開，即點即播晓避？
3簇捍、性能上，直播中濾鏡俏拱、美容暑塑、人臉動效，效果全開锅必，如何保證主播端的性能梯投？
4、億級海量并發(fā)用戶情況下，如何更好的保障質(zhì)量分蓖，柔性帶寬的策略如何做到極致尔艇？
本案例圍繞上述挑戰(zhàn)進(jìn)行，揭秘騰訊QQ空間團隊在挑戰(zhàn)中的一些優(yōu)化嘗試么鹤。
一终娃、案例介紹
QQ空間目前是國內(nèi)最大的SNS社區(qū)，日高峰上傳5億張圖片蒸甜，播放10億個視頻棠耕，6.3億用戶在這里分享生活，留住感動柠新，其中主流人群正是95后的年輕人窍荧。
也正因為是年輕人，且年輕人是生活方式轉(zhuǎn)變的主要推動力恨憎，不滿足于現(xiàn)在圖片+視頻傳統(tǒng)的分享方式蕊退，他們希望通過直播的方式讓你“現(xiàn)在、立刻憔恳、馬上”看到我瓤荔。這就是內(nèi)容消費的升級，同時伴隨著手機硬件的升級钥组、流量費用的下降输硝，于是手機直播變?yōu)榭赡堋?/p>
而我們的直播產(chǎn)品定位也是基于目標(biāo)用戶生活的內(nèi)容，外加社交的傳播力量程梦，有別于現(xiàn)在主流的網(wǎng)絡(luò)+游戲直播的模式点把。
帶來的好處是：用戶創(chuàng)造的內(nèi)容更多元化，更貼近生活屿附，更能在好友間產(chǎn)生共鳴和傳播郎逃；
帶來的問題是：我們要兼容的移動終端也是海量的，性能問題是我們重點關(guān)注的內(nèi)容拿撩。
在以上背景下衣厘，我們開始做直播了如蚜。目標(biāo)是一個月內(nèi)構(gòu)建直播的閉環(huán)能力压恒，也就是快速上線。需要實現(xiàn)發(fā)起直播错邦、觀看直播（1人發(fā)起探赫，多人觀看）、回看直播（回放）撬呢、直播互動（直播間中的評論伦吠、送禮等）、直播沉淀（Feeds沉淀、分享直播等）等功能（可參考圖1）毛仪；且同時支持Android搁嗓、iOS、Html5三大平臺（即方案成熟）箱靴，并且支持空間以及手機QQ內(nèi)的空間腺逛。
首先我們就面臨項目工期緊張、團隊直播技術(shù)積累不夠的問題衡怀。雖然如此棍矛，但我們?nèi)匀挥仓^皮繼續(xù)與各大相關(guān)技術(shù)提供商進(jìn)行交流，根據(jù)我們的標(biāo)準(zhǔn)以及提供商的建議進(jìn)行技術(shù)選型抛杨，我們的標(biāo)準(zhǔn)如下：
●專業(yè)度好（直播低時延遲够委，支持全平臺、基礎(chǔ)服務(wù)建設(shè)好）怖现；
●開放源代碼茁帽；
●支持度高，有問題可以隨時溝通解決真竖；
●支持動態(tài)擴容脐雪。
最后根據(jù)標(biāo)準(zhǔn)選擇了騰訊云提供的ILVB直播解決方案，尤其音視頻相關(guān)組在這塊有多年技術(shù)積累恢共，并且同部門可合作共贏战秋。
這其中值得一提的是我們的閉環(huán)研發(fā)模式也促使我們以及合作伙伴不斷提升產(chǎn)品質(zhì)量。首先快速上線（完成產(chǎn)品需求讨韭，并完善監(jiān)控）脂信，再在上線后查看監(jiān)控數(shù)據(jù)（分析數(shù)據(jù)），接著應(yīng)用到優(yōu)化工作（跟進(jìn)數(shù)據(jù)透硝、專項優(yōu)化）狰闪，最后進(jìn)行灰度驗證（灰度一部分用戶驗證優(yōu)化效果），根據(jù)效果再決定是否正式應(yīng)用到產(chǎn)品中（如圖2）濒生。
最后埋泵，我們?nèi)缭笇崿F(xiàn)了1個月上線，同時支持QQ空間和手機QQ(結(jié)合版QQ空間)罪治，到目前為止已經(jīng)迭代12+版本丽声。觀看量也從5月份的百萬級到8月份的千萬級、到現(xiàn)在的億級觉义，成為用戶參與的大眾化全民直播雁社。產(chǎn)品數(shù)據(jù)也跟隨用戶的需求一直在飆升，隨之而來的是各種各樣的問題反饋晒骇，尤其是性能問題霉撵，這也是本文要重點討論的話題磺浙。
二、直播架構(gòu)
在介紹直播架構(gòu)前徒坡，我想有必要給大家再復(fù)習(xí)一下H264編碼撕氧，目前市面上直播的視頻編碼基本都是H.264。H264有三種幀類型：完整編碼的幀叫I幀喇完、參考之前的I幀生成的只包含差異部分編碼的幀叫P幀呵曹、還有一種參考前后的幀編碼的幀叫B幀。H264的壓縮流程為分組（把幾幀數(shù)據(jù)分為一個GOP何暮，一個幀序列）奄喂、定義幀類型、預(yù)測幀（以I幀做為基礎(chǔ)幀,以I幀預(yù)測P幀,再由I幀和P幀預(yù)測B幀）海洼、數(shù)據(jù)傳輸跨新。
用簡單的例子來解釋視頻模型，如果把一個GOP(Group of pictures)當(dāng)做一列拉貨的火車坏逢，那一段視頻就是N輛火車組成的貨運車隊（圖3）域帐。
直播就是視頻數(shù)據(jù)的流動，邊拍攝是整、邊傳輸肖揣、邊播放的數(shù)據(jù)流動過程。數(shù)據(jù)由主播生產(chǎn)裝車浮入，經(jīng)過網(wǎng)絡(luò)（鐵路）龙优，再到觀眾端卸貨并進(jìn)行播放消費。
火車需要調(diào)度事秀，視頻流也一樣彤断，這就是視頻流協(xié)議，即通過協(xié)議控制視頻有序的傳輸給觀眾易迹。
常見協(xié)議如圖4：
我們采用的是騰訊云基于UDP開發(fā)的QAVSDK協(xié)議宰衙。
前面講了協(xié)議相關(guān)的內(nèi)容，下面講講我們的直播模型睹欲，如圖5：
視頻房間（視頻流）以及業(yè)務(wù)房間（相關(guān)業(yè)務(wù)邏輯互動）大致結(jié)構(gòu)差不多供炼，差別在于數(shù)據(jù)流動（注意圖5中箭頭）。
視頻房間數(shù)據(jù)由主播通過視頻流協(xié)議流向視頻服務(wù)器窘疮，而視頻服務(wù)器也通過視頻流協(xié)議把數(shù)據(jù)下發(fā)給觀眾袋哼，觀眾端解碼并播放。主播只上傳考余，觀眾只下載先嬉。而業(yè)務(wù)房間任何人都需要給服務(wù)器發(fā)送相關(guān)的業(yè)務(wù)請求（如評論轧苫，當(dāng)然客戶端會屏蔽一些特殊邏輯楚堤，如主播不可送禮給自己）疫蔓。更詳細(xì)的結(jié)構(gòu)如圖6：
注：iOS手Q觀眾采用RTMP協(xié)議不是因為不支持QAVSDK，而是因為手Q有減包壓力身冬，而QAVSDK相關(guān)的SDK占用空間較大衅胀。
三、技術(shù)優(yōu)化
接下來進(jìn)入本文的重頭戲：技術(shù)優(yōu)化酥筝。技術(shù)優(yōu)化分為四個方面：秒開優(yōu)化（耗時類優(yōu)化實踐）滚躯、性能優(yōu)化（性能優(yōu)化實踐）、卡頓優(yōu)化（問題分析類實踐）嘿歌、回放優(yōu)化（成本類優(yōu)化實踐）掸掏。
在優(yōu)化之前，我們的必要工作是監(jiān)控統(tǒng)計先行宙帝，我們會對我們關(guān)心的數(shù)據(jù)點進(jìn)行前期的統(tǒng)計丧凤，并做相關(guān)報表和告警，以輔助優(yōu)化分析步脓。
監(jiān)控分為以下五部分：
●成功率愿待，發(fā)起直播成功率、觀看直播成功率靴患、錯誤占比列表仍侥；
●耗時，發(fā)起直播耗時鸳君、進(jìn)入直播耗時农渊；
●直播質(zhì)量，卡幀率或颊、0幀率腿时；
●問題定位，各步驟流水饭宾、直播2s流水批糟、客戶端日志；
●實時告警看铆，短信徽鼎、微信等方式。
通過這些弹惦，我們實現(xiàn)了數(shù)據(jù)的查看否淤、分析定位、以及實時的告警棠隐，從而更方便地解決問題石抡。
四、秒開優(yōu)化
幾乎所有人都在吐槽“為什么直播打開很慢助泽，競品比我們快多了浮：烤！”隐解，我們自己也覺得不能忍鞍帝。我們要讓觀看直播達(dá)到秒開（從點擊直播到看到畫面，耗時在1秒以內(nèi)）煞茫，而統(tǒng)計到的外網(wǎng)平均打開耗時為4.27秒帕涌，離秒開還有一定的差距。
于是我們梳理從點開到渲染第一幀畫面這一段時間的時序關(guān)系续徽，同時統(tǒng)計各階段的耗時蚓曼。流程圖和耗時大致如圖7 ：
通過流程分析和數(shù)據(jù)分析發(fā)現(xiàn)兩個耗時原因是：獲取首幀數(shù)據(jù)耗時太長、核心邏輯串行钦扭。接下來我們針對這兩個問題進(jìn)行優(yōu)化辟躏。
首幀耗時太長。核心問題在于加速首個GOP到達(dá)觀眾的時間土全。
我們的優(yōu)化方案是：讓接口機緩存首幀數(shù)據(jù)捎琐，同時對播放器進(jìn)行改造，解析到I幀就開始播放裹匙。這樣大大加快了觀眾看到首幀的時間瑞凑。
核心邏輯串行。這部分我們主要通過以下流程：
●預(yù)加載概页，提前準(zhǔn)備環(huán)境和數(shù)據(jù)籽御，如在feeds中提前預(yù)拉起直播進(jìn)程，提前獲取接口機IP數(shù)據(jù)惰匙；
●延遲加載技掏，對UI、評論等其他邏輯進(jìn)行延遲加載项鬼，讓出系統(tǒng)資源給首幀哑梳；
●緩存，如緩存接口機IP數(shù)據(jù)绘盟，一段時間內(nèi)復(fù)用鸠真；
●串行變并行，同時拉取數(shù)據(jù)龄毡，節(jié)省時間吠卷；
●對單步驟耗時邏輯進(jìn)行優(yōu)化和梳理，減少單步耗時沦零。
優(yōu)化后的流程和耗時大致如圖8所示祭隔，耗時降低到680ms，目標(biāo)達(dá)成路操！
五疾渴、性能優(yōu)化
產(chǎn)品不斷迭代千贯，直播的玩法也越來越豐富了，同時一些性能問題也不斷暴露出來程奠。尤其我們后來增加了動效貼紙、濾鏡祭钉、變聲等功能瞄沙，大量用戶反饋直播很卡。
通過統(tǒng)計發(fā)現(xiàn)：主播短幀率很低慌核，畫面不連續(xù)距境，主觀感覺卡；另外垮卓，用戶使用設(shè)備中也有大量的低端機垫桂。如圖9所示。
通過分析發(fā)現(xiàn)幀率低的主要原因是單幀圖像處理耗時過長導(dǎo)致粟按，而編碼所占因素較低诬滩。一般總耗時=處理工作量*單幀耗時。于是我們逐漸對這兩方面進(jìn)行優(yōu)化灭将。
減少圖像處理工作量
●采集分辨率與處理分辨率一致疼鸟，比如編碼為960*540，由于有些手機可能不支持這個采集分辨率庙曙，采集一般都是1280*1024空镜，之前處理是先處理再縮放，現(xiàn)在先縮放再處理捌朴，減少圖像在濾鏡吴攒、動效貼紙中的處理耗時。如圖10：
●處理幀前丟幀砂蔽。雖然我們對系統(tǒng)相機設(shè)置了采集幀率洼怔，但是很多機型并不生效，于是我們通過策略對額外的幀進(jìn)行丟棄左驾，減少圖像處理的幀數(shù)茴厉。比如我們設(shè)置采集幀率為15，但實際有25什荣，這多余的10幀處理了在編碼的時候也會浪費矾缓，之前就丟棄，可減少資源消耗稻爬。
●機型分檔位嗜闻，不同的機型根據(jù)不同的硬件能力采用不用的采集幀率和編碼幀率，保證流暢桅锄；同時在過熱的時候以及回歸正常時動態(tài)調(diào)整幀率去調(diào)整資源消耗琉雳。
●人臉識別采集優(yōu)化样眠，每幀識別改為兩幀識別一次人臉，既不會產(chǎn)生人臉漂移也可以減少處理耗時翠肘。
減少單幀耗時
●采集流程改造檐束，減少了大約33%的不必要耗時，如圖11.
●動效貼紙多GL線程渲染束倍，貼紙渲染放在另外一個OffScreenThread進(jìn)行渲染被丧，完全不占用整個美化處理過程的時間，效果如圖12：
●動效貼紙采用OpenGL混合模式绪妹；
●圖像處理算法優(yōu)化甥桂，如ShareBuffer優(yōu)化（實現(xiàn)在GPU與內(nèi)存之間快速拷貝數(shù)據(jù)，排除CPU介入邮旷，節(jié)省紋理轉(zhuǎn)RGBA時間黄选；耗時幾乎降低一半，F(xiàn)PS也至少提升2-3幀左右）婶肩，濾鏡LUT優(yōu)化办陷，如圖13.
除了以上兩個大的優(yōu)化點，我們還推動更多的機器采用硬件編碼律歼。首先編碼穩(wěn)定懂诗，幀率不會波動；其次苗膝，占用CPU會有一定降低殃恒。
以上是我們大致的一些優(yōu)化點，優(yōu)化之后辱揭，用戶直播投訴大量減少唧龄。
六叭莫、卡頓優(yōu)化
我們先看一些相關(guān)的定義：
卡頓用戶定義：（卡頓時長/總時長）>5%定義為卡頓用戶殿漠，卡頓率＝卡頓用戶/總用戶傻寂。
主播卡頓點定義：上行大畫面編碼后幀率<5的點數(shù)。
觀眾卡頓點定義：解碼后幀率<5的點數(shù)域庇。
我們的目標(biāo)就是讓卡頓率達(dá)到50%以下嵌戈。
當(dāng)然上行發(fā)生卡頓時，會造成所有用戶卡頓听皿，而下行卡頓時熟呛，只有單個觀眾才會卡頓。
我們看看會造成卡頓的原因尉姨，見圖14 ：
大概有主播端庵朝、網(wǎng)絡(luò)、觀眾端三個大的模塊可能會導(dǎo)致卡頓問題，而主播端的性能優(yōu)化基本解決了九府，那就看下網(wǎng)絡(luò)以及觀眾端的椎瘟。
從統(tǒng)計數(shù)據(jù)發(fā)現(xiàn)網(wǎng)絡(luò)質(zhì)量影響占比達(dá)到50%左右，這明顯要優(yōu)化侄旬。于是網(wǎng)絡(luò)上行優(yōu)化我們做了圖15的事情肺蔚，減少單幀中的數(shù)據(jù)以及減少幀數(shù)，用火車的例子就是減少貨物以及控制火車數(shù)量儡羔。
而用戶端下行優(yōu)化則是囤積貨物宣羊，丟掉貨物，如圖16 笔链。
如圖17段只，我們來看優(yōu)化后的效果腮猖，與競品相比優(yōu)勢十分明顯：
同時鉴扫，主播卡頓率也下降到30%，觀眾卡頓率下降到40%澈缺，目標(biāo)算是達(dá)成了坪创。
七、回放優(yōu)化
如圖18姐赡，我們先來看看直播回看（回放）的大致流程：
回放同樣也存在一些問題莱预，主要體現(xiàn)在兩個方面：
●回放直播質(zhì)量：服務(wù)器器端保存，回看視頻質(zhì)量受主播短網(wǎng)絡(luò)影響較大
●服務(wù)器成本：服務(wù)器除了需要推一個私有協(xié)議流项滑，另外還需要對私有流進(jìn)行轉(zhuǎn)碼成HLS和MP4以便回放使用
在方案選擇上依沮，MP4具有播放方案成熟、速度快枪狂、用戶體驗佳等優(yōu)點危喉；而HLS系統(tǒng)支持差、用戶等待時間也長州疾。那是否意味著我們要直接選擇MP4方案呢辜限？
其實回看采用HLS以及MP4都是可以的，但是直播觀看時由于數(shù)據(jù)是在變化的严蓖，HTML5只能使用HLS薄嫡，如果我們回看的時候使用MP4，那就等于服務(wù)器需要對私有協(xié)議流分別轉(zhuǎn)碼成MP4和HLS颗胡，那這明顯不經(jīng)濟毫深。這就致使我們選擇HLS，服務(wù)器只需要轉(zhuǎn)碼一次流為HLS即可毒姨。
既然選擇HLS费什，我們就要針對性地解決HLS存在的問題。
在Android平臺上，Android 3.0開始支持HLS鸳址，后來因為Google官方想推DASH取代HLS瘩蚪，對HLS的支持便慢慢減弱了，在官方文檔上甚至找不到一點兒關(guān)于HLS的說明稿黍。經(jīng)實踐發(fā)現(xiàn)Android原生播放器對HLS的支持程度僅僅是能播疹瘦，完全沒有任何優(yōu)化。這樣不僅會有多余的m3u8文件請求巡球，而且啟動播放后整個流程是串行的言沐，非常影響視頻畫面的首幀可見耗時（平均耗時4.5s左右）。
我們可以通過本地代理提前下載來解決這個問題酣栈，接入下載代理后险胰，在代理層可以對m3u8文件的內(nèi)容進(jìn)行掃描，并觸發(fā)對ts分片的并行下載矿筝，把ts數(shù)據(jù)緩存起來起便。經(jīng)過這樣的處理后，雖然播放器的層面還是串行下載窖维，由于我們已經(jīng)提前準(zhǔn)備好了數(shù)據(jù)榆综，數(shù)據(jù)會很快返回給播放器，這樣就實現(xiàn)了我們降低首幀耗時的效果铸史，經(jīng)實驗接入后平均首幀可見耗時降低到了2s左右鼻疮。
優(yōu)化前后流程圖見圖19：
緩存策略上，HLS的緩存業(yè)界目前還沒有成熟方案琳轿。我們實現(xiàn)了對圖20中三種模式的自動偵測與支持判沟，使用方完全不需要關(guān)心底層的緩存與下載邏輯。
最后崭篡，服務(wù)器成本方面節(jié)省了50%的轉(zhuǎn)碼計算和存儲成本挪哄；另外，回放的加載速度也變快了媚送。
八中燥、案例總結(jié)
通過之前的案例和相關(guān)優(yōu)化分析，總結(jié)出三種大致的問題模式塘偎，以及相應(yīng)的優(yōu)化思路疗涉。
●速度類：理清時序，統(tǒng)計各階段耗時吟秩，各個擊破咱扣；
●性能類：通過Trace，明確性能損耗點涵防，各個擊破闹伪；
問題解決類：建立模型，初步分析，統(tǒng)計上報偏瓤，確認(rèn)問題杀怠，各個擊破。
總結(jié)成一個套路就是圖21 ：
在案例中也體現(xiàn)了以下一些參考點：
●快速迭代厅克，小步快跑
●監(jiān)控驅(qū)動優(yōu)化
●建立模型赔退，抽象問題直觀分析
●產(chǎn)品定位決定優(yōu)化的方向
● 海量服務(wù)，以小省大
最后证舟，以一張空間直播的拓補圖作為結(jié)束本文（圖22）硕旗。
TOP100大會將于11月9日-12日在北京國家會議中心舉辦，在現(xiàn)場通過對案例的復(fù)盤總結(jié)女责，分享成功者背后的經(jīng)驗和方法漆枚。大會開幕式單天體驗票免費入口。
