4月18日QCon性能優(yōu)化面面觀專題會議上，騰訊研發(fā)總監(jiān)王輝以“十億級視頻播放技術(shù)優(yōu)化揭秘”為主題，用QQ空間的日均播放量一年內(nèi)從***突破到十億級所面臨的嚴(yán)峻考驗(yàn)為切入點(diǎn)，為大家分享視頻團(tuán)隊(duì)在視頻組件的整體架構(gòu)、優(yōu)化效果衡量、帶寬優(yōu)化、秒開優(yōu)化、緩沖優(yōu)化、成功率優(yōu)化等六個方面的技術(shù)實(shí)踐。

王輝：大家早上好!我叫王輝，來自騰訊，從2009年開始從事QQ空間技術(shù)研發(fā)，近期主要關(guān)注手機(jī)短視頻、視頻直播、AI智能硬件。很高興能在QCon上與大家一起分享和交流。我今天的話題是“十億級視頻播放技術(shù)優(yōu)化揭密”。主要介紹我們團(tuán)隊(duì)在去年一年短視頻風(fēng)口上，我們的視頻播放量從5000萬到十億級過程中的一些技術(shù)實(shí)踐，希望我的介紹能給大家做一些借鑒和參考。

眾所周知，短視頻去年是一個風(fēng)口，起因是來自Facebook 2015年Q3的財(cái)報(bào)，財(cái)報(bào)表明在Facebook平臺上每天有80億次短視頻播放，給Facebook帶來了強(qiáng)勁的廣告收入，正是這個數(shù)據(jù)給國內(nèi)核心大公司和創(chuàng)業(yè)公司帶來的一些新的突破口。其實(shí)短視頻已經(jīng)不是一個新的概念，從2006年開始國內(nèi)就有很多公司在做短視頻。隨著Facebook吹起短視頻風(fēng)，去年在短視頻行業(yè)有近百款應(yīng)用出現(xiàn)，中國網(wǎng)民里面每5個里面就有1個是短視頻的用戶，短視頻成為互聯(lián)網(wǎng)的流量入口。

QQ空間也在這個風(fēng)口中，從2015年11月份的每天5000萬視頻播放量，經(jīng)過一年的耕耘細(xì)作，徒增到2016年12月份的10億量級，現(xiàn)在還在不斷增長。

我的演講主要是按照我們產(chǎn)品迭代的幾個關(guān)鍵步驟展開：

首先是快速上線，2015年我也是跟隨著大家的體驗(yàn)快速上線了新短視頻的體驗(yàn)。

其次面臨的是成本問題，在做的過程中做了一些成本的優(yōu)化工作。

然后是體驗(yàn)優(yōu)化。在解決成本問題之后，短視頻的觀看體驗(yàn)要做到***。比如說視頻的秒開、不產(chǎn)生緩沖、不卡、成功率的提升。

快速上線

在開始之前，我先介紹一下我們的團(tuán)隊(duì)職責(zé)，我們團(tuán)隊(duì)負(fù)責(zé)手機(jī)QQ和手機(jī)QQ空間兩個APP，每個APP有iOS和Android兩個團(tuán)隊(duì)，一共四個團(tuán)隊(duì)，四個團(tuán)隊(duì)負(fù)責(zé)兩個APP。在這個項(xiàng)目中，我們四個團(tuán)隊(duì)要針對兩個平臺實(shí)現(xiàn)四套邏輯，這里的效率是存在一定的問題。

關(guān)于短視頻體驗(yàn)，在這之前，我們也只是做到能播放而已，沒有做很精細(xì)的工作，并且這里的產(chǎn)品觀感體驗(yàn)也不是很一致，也不是很好。

技術(shù)上，之前也只是做很基礎(chǔ)的架構(gòu)，直接由播放器連接服務(wù)器下載數(shù)據(jù)，達(dá)到能播放就可以。之前我們沒有積極去做這個事情，導(dǎo)致播放成功率低、失敗原因未知、不支持邊下邊播、緩沖時間比較長等問題，流量浪費(fèi)也比較嚴(yán)重。在產(chǎn)品上要解決的，是在整個APP里面把所有產(chǎn)品的體驗(yàn)做到一致，比如說每個功能的觀看體驗(yàn)，視頻浮層的體驗(yàn)，統(tǒng)一觀看體驗(yàn)也為我們項(xiàng)目清除了很多障礙。

而這里的技術(shù)上的要點(diǎn)是非常關(guān)鍵的，***個是邊下邊播，這是基礎(chǔ)的要求，是為了加快視頻播放速度。第二個是流量的控制，這么大的平臺，之前只是做5000萬的播放量，如果沒有流量控制的云策略，可能到后面流量是無法把控的。第三，剛才講到團(tuán)隊(duì)的現(xiàn)狀，團(tuán)隊(duì)要負(fù)責(zé)兩個APP，這里要做代碼復(fù)用，不可能再像之前一樣四個團(tuán)隊(duì)維護(hù)四套代碼，第四，我們支持第三方的視頻源。第五，需要完善監(jiān)控上報(bào)，對業(yè)務(wù)知根知底。

可以看到，完成核心技術(shù)要點(diǎn)最核心的一點(diǎn)是如何控制視頻的下載，傳統(tǒng)的方式是播放器直接塞播放地址給播放器，它就可以直接播放，這其實(shí)是一個黑盒。我們在中間加了一個本地代理，播放器與服務(wù)器的數(shù)據(jù)請求，我們完全可以把控。在這個過程中，比如說播放器要數(shù)據(jù)時，可以給它更多的數(shù)據(jù)，這樣能解決它緩沖的問題。有了這層代理之后，架構(gòu)也更清晰一點(diǎn)。

基于這樣的架構(gòu)，在MODEL一層做一些業(yè)務(wù)的邏輯，在VideoController這一層做控制視頻的播放和下載。有了下載代理之后，就可以通過代理管理下載，在APP里面有很多的視頻請求，VideoProxy可以管理這些請求，做流量控制，做預(yù)加載，還可以做優(yōu)先級調(diào)度和做監(jiān)控上報(bào)，下載邏輯層則主要關(guān)注怎么優(yōu)化服務(wù)器，對接緩存管理層，同時我們抽象出了一個數(shù)據(jù)層，我的數(shù)據(jù)源可以是HTTPDataSource，也可以讀本地，也可以是來來自騰訊視頻的數(shù)據(jù)源，也可以是第三方APP的數(shù)據(jù)源，協(xié)議層主要是HTTP、HTTPS、HTTP2的解決。

在VideoController的邏輯里，其實(shí)都可以放到C層來實(shí)現(xiàn)，這樣安卓和iOS完全可以通用，這一層的邏輯可以在QQ和QQ空間兩個APP里面使用，相當(dāng)于是我們一套邏輯可以完全復(fù)用，不用再開發(fā)四套邏輯，我們團(tuán)隊(duì)的職能也做了相應(yīng)調(diào)整，之前可能是按團(tuán)隊(duì)劃分，四個團(tuán)隊(duì)負(fù)責(zé)四個終端，現(xiàn)在可能是按FT的方式劃分做視頻的團(tuán)隊(duì)，iOS做視頻的團(tuán)隊(duì)可能負(fù)責(zé)QQ和QQ空間里的業(yè)務(wù)，安卓也是如此。直播的FT也可以這樣劃分，iOS的負(fù)責(zé)iOS的兩個APP，安卓的負(fù)責(zé)安卓的兩個APP，這樣代碼復(fù)用更清晰一點(diǎn)，我的團(tuán)隊(duì)更專注一點(diǎn)。視頻的團(tuán)隊(duì)專注視頻的研發(fā)。

監(jiān)控上報(bào)，肯定是不可缺少的，這是一個成熟的項(xiàng)目必備的要素。

***， 問題定位，老板跟用戶反饋說我這個視頻播不了，要有一套成熟的問題定位的方式。

第二， 耗時統(tǒng)計(jì)，用戶播放這個視頻花多長時間播出來，這也是要了解到的。

第三， 成功率統(tǒng)計(jì)，外網(wǎng)用戶播放視頻的成功率是多少?還要通過實(shí)時報(bào)警，才能及時知道外網(wǎng)發(fā)生一些故障。

傳統(tǒng)的撈Log方式大家都有，但是這種方式效率太低，需要等用戶上線之后才能撈到Log，Log撈到之后還得花時間去分析。我們做法的是在關(guān)鍵問題上做一些插裝，把每一類錯誤和每一個具體的子錯誤都能定義出來，這樣一看錯誤碼就知道播放錯誤是由什么原因?qū)е碌?。還可以把每次播放視頻的鏈路所有關(guān)鍵流水上報(bào)到統(tǒng)計(jì)系統(tǒng)里來，每一次播放都是一組流水，每一條流水里面就包含了例如***緩沖發(fā)生的Seek，或下載的鏈接是多少，下載的時間是多少，有了這些流水之后，用戶反饋播放失敗，我首先可以用流水看發(fā)生了什么錯誤?錯誤在哪一步?每一步信息是什么?幾秒鐘就可以定位到問題。

有了這個數(shù)據(jù)上報(bào)之后，還可以做一些報(bào)表。比如說可以做錯誤碼的報(bào)表，有了報(bào)表之后就可以跟進(jìn)哪個錯誤是在TOP的，負(fù)責(zé)人是誰，原因是什么，都可以看到。

我們也有自己實(shí)時的曲線，可以看到各項(xiàng)數(shù)據(jù)的情況。在告警方面，基于成功率和失敗率的統(tǒng)計(jì)，進(jìn)行實(shí)時告警。一出現(xiàn)錯誤碼，微信立即可以收到提醒，提醒說是什么原因?qū)е逻@次告警，全自動。

成本優(yōu)化

上線一個月之后，一個壞消息一個好消息。好消息是播放量漲了4倍，壞消息是帶寬漲了6倍。帶寬優(yōu)化是每個做視頻的人必須要面臨的問題，我們也分析這個過程中的原因，發(fā)現(xiàn)因?yàn)楦臑檫呄逻叢ブ笥脩粲^看視頻的意愿比較強(qiáng)，用戶有挑選心理，不是每個視頻都去看，看了一下之后不喜歡就劃走了，之前下載的那部分其實(shí)是浪費(fèi)的。

如果之前不做限速的話，一點(diǎn)開視頻就瘋狂的下數(shù)據(jù)，帶寬有多大就下多少的數(shù)據(jù)，這樣浪費(fèi)很嚴(yán)重。

我們采取的***個策略是進(jìn)行流量控制。在高峰期播放到第10秒時，預(yù)下載N秒數(shù)據(jù)，下載到N秒就停下來。然后，可以做多級限速。一開始不限速，下載到合適時機(jī)做1倍碼率限速。高峰期時預(yù)加載的數(shù)據(jù)會少一些，防止高峰期時帶寬占用明顯，這是初級的策略。最終我們也有碼率切換的策略。這對用戶的觀看體驗(yàn)影響比較大，這也是之前必備的一個策略。

上線這個策略之后，對帶寬的優(yōu)化還是比較明顯的。在高峰期時從18：00到凌晨1點(diǎn)帶寬下降25.4%，這個是我們不斷灰度最終確定的值。這個值會影響播放緩沖，因?yàn)閿?shù)據(jù)少的話必定會卡頓，在卡頓之間和流量之間取了一個***值，最終是25.4%。

但這樣肯定是不夠的，因?yàn)榱髁繚q的還是很明顯的，我們想到H.265，壓縮率相對于H.264提升了30%-50%，但它的復(fù)雜度也是呈指數(shù)級上升。復(fù)雜度導(dǎo)致它的編解碼耗時更長，占用資源也更長。如果把H.265用在客戶端上的話，可能要評估一些點(diǎn)，比如說在編碼上面，現(xiàn)在手機(jī)上沒有做H.265硬件支持的，相對于H.264的耗時3-7倍，之前耗時可能是10分鐘，而現(xiàn)在可能需要到70分鐘左右。解碼的硬件支持H.265的也很少，耗時差不多是一樣的。解碼是可行的，你可以采用軟解的方式，這個帶來的問題是CPU占用非常高，可能之前H.264占20%的CPU，H.265占70%、80%左右，帶來的問題是發(fā)熱和耗電。

結(jié)論，解碼是可行的，但是編碼不用考慮，在移動客戶端不可行的情況下，那編碼就要放在后臺來做了。

為了解決如何在我們手機(jī)上能夠解碼的問題，對手機(jī)的解碼能力做一次評估。我在合適的時機(jī)做一次大規(guī)模的浮點(diǎn)數(shù)運(yùn)算，將數(shù)據(jù)上傳到后臺服務(wù)器進(jìn)行云適配。如果當(dāng)前的指數(shù)滿足H.265條件的話，可以給你下載H.265視頻給你播放。從而保證軟件解碼柔性可用，針對視頻源規(guī)格按機(jī)型適配降級，保證用戶視頻播放體驗(yàn)。

經(jīng)過我們的統(tǒng)計(jì)，外網(wǎng)上有94%的手機(jī)還是支持H.265解碼的。支持1080P手機(jī)的解碼占46%。

編碼只能在后臺做，如果在視頻后臺進(jìn)行全面編碼的話，是不現(xiàn)實(shí)的。因?yàn)榫幋a復(fù)雜度呈指數(shù)級上升，拿后臺服務(wù)器進(jìn)行編碼也是不可行的。我們的做法是只用熱點(diǎn)視頻進(jìn)行后臺轉(zhuǎn)碼，不是所有視頻都去編碼，對觀看量在TOP N的視頻進(jìn)行編碼，只需要編碼少量的視頻就可以帶來流量優(yōu)化效果，因?yàn)門OP N就占了全網(wǎng)80-90%的流量。

因?yàn)闊狳c(diǎn)視頻的熱點(diǎn)轉(zhuǎn)化很快，可能前幾分鐘是熱點(diǎn)，后幾分鐘就不是熱點(diǎn)，因?yàn)樯缃痪W(wǎng)絡(luò)的傳播非?？?。我們給后臺的要求是轉(zhuǎn)碼速度一定要快，在之前沒有優(yōu)化時，轉(zhuǎn)一個10分鐘的視頻要半個小時左右。后來我們做了分布式處理之后，轉(zhuǎn)10分鐘的視頻只用兩三分鐘。一些短視頻最長5分鐘左右，只要監(jiān)測到這個視頻很熱的話，1分鐘之內(nèi)就能轉(zhuǎn)出來，就是H.265了。

同樣，在H.265編碼器上做了一些優(yōu)化，比如說編碼速度和碼率的都會有提升。

上線H.265優(yōu)化之后，我們的帶寬進(jìn)一步下降，節(jié)省了31%左右。

秒開優(yōu)化

帶寬問題解決之后，面臨的下一個問題是體驗(yàn)優(yōu)化。用戶最想要的是視頻能立馬播出來。我們定了一個秒開技術(shù)指標(biāo)，只要這個視頻從到我的視野范圍，到視頻播出來之間的耗時在一秒以內(nèi)。這也是對標(biāo)Facebook的體驗(yàn)，F(xiàn)acebook一打開動態(tài)，視頻是能立即播出來的，不需要等待就能播，這個體驗(yàn)其實(shí)很順暢。核心的流程主要是三個步驟：1、客戶端的耗時;2、下載數(shù)據(jù);3、等待播放。

這里主要有兩個大的耗時點(diǎn)，***下載視頻數(shù)據(jù)耗時;第二個是客戶端的耗時，下載視頻數(shù)據(jù)耗時的話，主要是下載數(shù)據(jù)量和下載的速度。

這里有一個很直接的問題，播放器需要下載多少數(shù)據(jù)才能播放?我們可以看一下MP4，MP4其實(shí)是一個比較靈活的容器格式，每個東西都是用Box表達(dá)的，每個Box又可以嵌入到另外一個Box。MP4主要由MOOV和Mdata組成，MOOV是囊括了所有的視頻關(guān)鍵信息，肯定是先把MOOV下載完之后才能找視頻數(shù)據(jù)才能播起來。不巧的是，在我們外網(wǎng)會發(fā)現(xiàn)有5%左右用戶上傳的視頻，它的MOOV是在尾部的。后來也發(fā)現(xiàn)，有很多安卓手機(jī)比如說山寨機(jī)，一些攝像頭處理的廠商可能比較偷懶，因?yàn)樗麄冎挥性谀悴杉晷畔⒅蟛拍苤浪械男畔?，他可能把所有的信息放在尾部。對于MP4來說，一開始把頭部下載了，下載頭部時可能找不到這個MOOV，就猜測這個MOOV在尾部，我可能就有一次請求去探測這個頭部到底在哪?這個探測的話基本做法是去尾部探測。如果MOOV在其他地方的話，這次播放肯定是失敗的?，F(xiàn)在主流的系統(tǒng)都是去尾部進(jìn)行一次探測。

比如安卓某些手機(jī)是無法自定義Range，那就需要下載完整個文件才能播放。我們的處理方式，用戶在后臺做一次轉(zhuǎn)碼修復(fù)，客戶端采集后做一次轉(zhuǎn)碼修復(fù)。

再看一下Mdata，這是視頻的原數(shù)據(jù)。目前大部分是H.264編碼，H.264通過真預(yù)測的方式來進(jìn)行視頻編碼，這里有一個GOP概念，也是在直播里面經(jīng)常談的。一般的視頻需要下載歌完整的GOP數(shù)據(jù)才可以播，可以看到在這個里面需要下載多少數(shù)據(jù)才能播呢?每個播放器的行為也不一樣。大家可以看到iOS要下載一個完整的GOP才可以播。像FFmpegBasedPlayer的話我可能只需要關(guān)鍵幀就可以播出來。安卓是比較尷尬的一個系統(tǒng)，在6.0級以下，可能需要5秒視頻數(shù)據(jù)才可以播起來。如果說是需要下載5秒數(shù)據(jù)才可以播起來的話，那肯定是非常慢的。我們這里的一個策略會采用FFmpegBasedPlayer自己來做解碼，這里要關(guān)注功能性和耗電的問題。

解決了Mdata之后，你會發(fā)現(xiàn)如果我的數(shù)據(jù)在頭部，拿關(guān)鍵信息進(jìn)行播放的話，其實(shí)我播放的數(shù)據(jù)量非常小的。

對于下載優(yōu)化的話，會有一個防盜鏈的請求，通過HTTP拿到真實(shí)的才可以下載數(shù)據(jù)。在手機(jī)上執(zhí)行HTTP請求是非常耗時的，這里我們走私有長連接通道做這個事情。

關(guān)于優(yōu)化下載鏈路，這里也是談的比較多的，一般也是直接輸出IP地址，利用IP地址做跑馬的策略，兼顧性能的效率，這個是用的比較多的方式。

進(jìn)一步思考，按照普遍600K碼率的話，我們統(tǒng)計(jì)到現(xiàn)在APP上面下載的平均速度是400K左右，這樣計(jì)算的話，可能在安卓上面播放一個視頻的話，需要將近0.9秒左右才可以下載到你需要的數(shù)據(jù)。如果碼率再進(jìn)一步提升的話，可能會更大，這其實(shí)我們也做了一些場景分析，會發(fā)現(xiàn)我們是社交網(wǎng)站，它有好友動態(tài)，視頻在好友動態(tài)里播放，或者是在視頻浮層里播放，我們的選擇是預(yù)加載的策略，這也是常見的策略。我們會在當(dāng)前看的這條動態(tài)時會預(yù)加載后面視頻的關(guān)鍵信息，比如說會加載頭部信息和需要播放的數(shù)據(jù)，來進(jìn)行預(yù)加載。比如說在播放當(dāng)前視頻時，我的視頻在加載一定數(shù)據(jù)之后會加載下一秒預(yù)加載數(shù)據(jù)，這些都可以做到的。

預(yù)加載有一個問題，我們之前踩了一個坑，可能預(yù)加載視頻時還是要優(yōu)先圖片的。視頻當(dāng)然重要，但是社交網(wǎng)絡(luò)上的圖片也更重要，可能在預(yù)加載視頻時會考慮到圖片的一些任務(wù)，還有視頻封面之類。

優(yōu)化效果也是比較明顯，經(jīng)過剛才幾個策略，一個是我們對頭和播放器的處理，我們對防盜鏈的處理，還有對下載鏈路的處理和預(yù)加載，這樣我們的耗時大幅度減少了，之前是1.8秒降到0.6秒左右?？蛻舳说男阅芤彩亲屓巳菀缀鲆暤膯栴}，發(fā)現(xiàn)有些用戶雖然有視頻的緩存，但是播起來還是很慢，這其實(shí)是客戶端性能的影響。因?yàn)橐曨l涉及到的BU和流程比較多，在這個過程中還要更關(guān)注到客戶端的影響，要分析下客戶端是哪些在搶占你的視頻播放資源，我們之前犯過一些錯誤，md5會卡住一些流程，或者是HttpParser會阻止你的任務(wù)，會導(dǎo)致視頻播放更慢。

在優(yōu)化視頻播放過程中，我們在4月份也做直播。直播這里面插入個事情，我們要播放直播的視頻流，是HLS的視頻，在好友動態(tài)里面可以觀看直播的內(nèi)容。HLS在安卓上面體驗(yàn)非常差，因?yàn)榘沧?.0之后對HLS基本沒有做的優(yōu)化工作，這里每次安卓上播放HLS需要等待6-9秒。分析發(fā)現(xiàn)它的處理也不是很得當(dāng)，因?yàn)榘沧肯到y(tǒng)請求鏈路較長，串行下載，需要下載3-4片TS才能啟動播放，下載3個分片的話，耗時就會很久。之前提到我們這里有代理，有了代理之后做事情方便很多了，通過里獲取M3U8，解析M3U8里面有哪些文件，可以做并行下載，只讓他下載一次M3U8，這樣下載速度大幅度提升?；氐絼偛偶軜?gòu)上，有了下載代理層的話，你可以做HLS的加速和管理，可以加入HLS的視頻源。

HLS緩沖耗時也是很明顯的，之前需要6秒左右，現(xiàn)在1.6秒左右就可以播起來。整體從之前的2秒左右現(xiàn)在優(yōu)化到700m秒，80%用戶都可以在1秒內(nèi)播視頻。

還有一個是用戶比較關(guān)注的問題，觀看視頻時卡，觀看一會卡了一下，loading數(shù)據(jù)，loading完以后又卡，這個體驗(yàn)非常差，我們希望所有的視頻都不卡。其實(shí)這有兩個播放場景，一個是正常場景，邊下邊看，數(shù)據(jù)在下載。對于正常場景下載時會做一些帶寬調(diào)整，在低速時會做切換IP的處理，比如說當(dāng)前連通IP的耗時比較久的話，會做一些處理，也會對網(wǎng)絡(luò)進(jìn)行速度限制。

針對Seek場景的話，如果用戶拖動的話，文件緩存系統(tǒng)是連續(xù)存儲系統(tǒng)的話，必然會造成拖到這里時，后面的緩存數(shù)據(jù)是沒有辦法下載到系統(tǒng)里面來的。

我們就對存儲做了一次重構(gòu)，支持文件空洞。會按照一兆的方式對文件進(jìn)行碎片劃分，好處是我可以分段存儲，我可以允許邏輯空洞的，拖動的話也可以在后面存儲，也不需要數(shù)據(jù)庫，我可以知道這是從哪個位置到哪個位置的存儲。這樣淘汰緩存也高效一點(diǎn)，并可以制定更靈活的緩存策略。這里可以淘汰更低密度的文件，還可以做的事情是對文件加密。這里產(chǎn)生卡頓的用戶里面，90%是因?yàn)檫M(jìn)行拖動，拖動之后又沒有緩存數(shù)據(jù)，所以這里有可能導(dǎo)致發(fā)生緩沖。統(tǒng)計(jì)效果也是比較明顯的，上了分片緩存之后，之前的緩存概率是4.6%左右，***下降到0.48%，基本上看不到發(fā)生緩沖的場景。

成功率優(yōu)化，也是我們比較關(guān)鍵的指標(biāo)。成功率優(yōu)化沒有捷徑，可能是Case by Case各個擊破。之前我們進(jìn)行編碼，有幾百個錯誤碼，錯誤碼原因進(jìn)行上報(bào)，每次進(jìn)行循環(huán)，一個個錯誤碼進(jìn)行解決。下載常見的錯誤碼，DNS劫持是比較多的，一些網(wǎng)絡(luò)運(yùn)營商會劫持你的請求。

這個在國內(nèi)是比較常見的劫持，有的小運(yùn)營商按月會劫持你的視頻內(nèi)容，可能直接污染你的DNS讓你查找不到CDN，這是比較多的，還有一些網(wǎng)絡(luò)不穩(wěn)定的影響導(dǎo)致。更隱藏的會直接污染你的視頻內(nèi)容，讓你視頻內(nèi)容是錯誤的。播放比較多的可能是一些編碼的原因，剛才提到一些手機(jī)采集出來的視頻在低端手機(jī)上播不出來，我們會對這些視頻進(jìn)行修復(fù)。

邏輯上的問題，因?yàn)椴シ牌饔袪顟B(tài)的，可能開發(fā)人員比較多，每個人過來加一個邏輯的話，會導(dǎo)致播放狀態(tài)出現(xiàn)問題。

我們做的播放器錯誤解決方法：

HOOK播放器接口與回調(diào)，實(shí)現(xiàn)播放器狀態(tài)機(jī)，監(jiān)控插放器API的調(diào)用是否合法，不合法直接告警或Crash。幫助開發(fā)快速定位問題，同時減輕測試同事的負(fù)擔(dān)，封裝成UI組件，使其它開發(fā)不必理解播放器。

最終優(yōu)化的成果是這樣的，下載成功率優(yōu)化前是97.1%，優(yōu)化后是99.9%。播放成功率優(yōu)化前是97.0%，優(yōu)化后是99.9%。***緩沖耗時優(yōu)化前是1.95s，優(yōu)化后是0.7s。二次緩沖概率優(yōu)化前是4.63%，優(yōu)化后是0.48%。數(shù)據(jù)還是很可觀的。

我的演講基本是這些，歡迎大家關(guān)注我們團(tuán)隊(duì)的公眾賬號，也會分享一些技術(shù)文章。

謝謝大家!

提問：剛才您提到已經(jīng)開始嘗試用265了，能透露一下265你們播放的在整體中占多大的比例?

王輝：現(xiàn)在熱視頻里面80%都是H.265。10億里面會有70%、80%左右。

提問：推進(jìn)的還是挺靠前的。剛才你提到要判斷手機(jī)的H.265能力，用大規(guī)模的浮點(diǎn)運(yùn)算，首先我先了解一下你們用的什么浮點(diǎn)運(yùn)算的Mark?其次，為什么要用浮點(diǎn)運(yùn)算?其實(shí)視頻編解碼里面幾乎全部都是整數(shù)運(yùn)算。

王輝：浮點(diǎn)運(yùn)算能代表你這個手機(jī)性能，其實(shí)我們是評估性能的，不是評估H.265轉(zhuǎn)碼，如果性能達(dá)到的話，解碼也是可以達(dá)到的。

提問：如果想針對解碼做評估的話，我建議整數(shù)運(yùn)算。你可以確認(rèn)一下，首先視頻編解碼的標(biāo)準(zhǔn)規(guī)定是沒有浮點(diǎn)運(yùn)算，不同的編解碼時限可能會插入少量的浮點(diǎn)運(yùn)算，大部分是整數(shù)運(yùn)算。

王輝：我們初步做的時候是判斷手機(jī)有沒有運(yùn)算能力來做的浮點(diǎn)運(yùn)算判斷。

主持人：感謝各位嘉賓的提問，感謝王輝老師給大家?guī)淼闹v解。