知識星球本文是來自美圖的黃及峰（阿不）在 GIAC 2018 深圳站分享的美拍短影片最佳化實踐的演講精華內容。
作者將從成本最佳化，成功率最佳化，播放體驗最佳化等幾個方面，整體介紹下美拍短影片成本減半以及毫秒起播最佳化實踐之路。檢視文末可以下載PPT。
內容概要
近幾年來短影片領域成為網際網路的風口，美拍作為最早的短影片APP，從2014年開始就對短影片技術有持續地投入和研究。4年多來，隨著4G網路的發展以及普通家庭寬頻有跨越式地發展，人們對網際網路資訊的獲取從簡單的文字過渡到內容生動豐富的流媒體內容，極大的促進了流媒體影片技術的發展，同時也給使用者體驗提出更高的要求。
本文將從成本最佳化，成功率最佳化，播放體驗最佳化等幾個方面，整體介紹下美拍短影片成本減半以及毫秒起播最佳化實踐之路。除了這些基礎的使用者體驗改造方面的落地，我們還在持續推進更加極致的使用者體驗最佳化。
技術背景
從痛點出發
在早期，快速落地階段，我們的關註點更加側重產品的需求和使用者增長，以快速滿足使用者需求為主作為我們的產品主要發展標的，這也是網際網路產品基本的發展規律。在早前快速落地階段，短影片播放的情況是：
-
觀看體驗不佳，每個影片在載入前都會有一個比較煩人的1-3秒的轉菊花的過程，即使影片很快起播，菊花也是一閃而過。部分影片還會出現必須要全部下載完之後才能開始播放的情況；
-
起播速度慢，短影片的長度一般在十幾秒到幾分鐘之內，起播速度的快慢直接影響了使用者持續觀看的意願。如上所提到的，在沒有做特殊最佳化的情況下，正常起播時間需要1-3秒以上；
-
下載成本高，CDN頻寬成本是所有影片類服務最大的一筆費用支出，同時也是使用者比較關註的敏感問題。如何最大限度的降低頻寬成本，對企業和使用者體驗而言都是雙贏的。
資料驅動
基於上述情況，我們在成本和體驗等方面做了相應的改造，我們的核心評估標準是資料，必須堅持以資料驅動來推動整體最佳化工作。最佳化類的工作，我們的挑戰在於必須做的比原來更好，並且不能因為最佳化工作給業務帶來可用性方面的風險。因此，構建一套客觀公正的資料體系是我們最重要的工作前提，資料決定方向，用資料來做排程調整決策。
我們的資料體系不是以產品化為標的，總體的建設標的包括：
-
準確性，資料必須要準確，資料不準確，一切都沒有意義；
-
快速落地，在人力有限的情況下，必須要保證足夠快速的落地性；
-
可複製體系，我們不追求完美的產品體驗，標準化的處理流程可以保證讓我們可構建不同維度型別的資料。
有了客觀公正的資料，我們可以利用它來做：
-
最佳化效果評估，用資料來評估最佳化效果是最為直接的，特別是幾十到幾百毫秒的差別依賴人工的判斷通常是比較無感的；
-
實時故障報警，出現故障時，第一時間報警，第一時間處理幹預；
-
質量反饋決策，透過質量我們可以對各種服務提供商的質量有更好評估，作出及時調整；
-
使用者問題排查，使用者反饋的問題如果沒有日誌等資訊，我們無法分析判斷問題。利用一些關鍵的資訊，可以讓我們更好的排查和處理使用者問題。
融合排程系統
基於我們對線上問題的核心痛點的分析，結合我們所要做的一些排程策略，我們構建了一套點播融合排程系統。我們希望透過這套系統的建設，可以更好的與業務松耦合的結合，透過排程服務，提供更加靈活的策略支援，利用質量系統給整體的排程提供可靠的資料支撐。融合排程系統的主要模組和功能包括：
-
排程服務，提供多CDN容災和多位元速率等排程分發機制，同時以後還可以加入更多的策略支援；
-
質量系統，利用客戶端上報的資料，實時處理分析，給排程服務提供自動排程切換決策；
-
雲處理系統，利用熱門檔案分析，對熱門影片做多位元速率檔案處理，提供分發H265，不同解析度檔案等支援。
[圖一：點播融合排程總體架構圖]
成本最佳化
成本最佳化，最直接體現在降低CDN成本，同時也可以降低使用者觀看影片時的資料流量，對平臺和使用者而言是雙贏的。
降低頻寬的手段，最簡單粗暴的手段是透過壓縮降低熱門影片的位元速率。透過位元速率的壓縮，在降低頻寬的同時，也會降低影片的畫質，對使用者體驗以及平臺的聲譽均會帶來較大的負面影響。
我們希望在畫質不變的情況下，降低CDN成本。為此我們做了一個前提假設：使用者有很大的機率是沒有完全播放影片就退出播放，同時如果在出現二次播放的時候，我們希望能夠讓使用者直接透過本地快取可以直接播放，避免多次下載所帶來的頻寬浪費。
要實現限制頻寬標的，也有多種不同的手段包括：
-
利用位元速率資訊，透過限制使用者的下載速度，儘量保持讓使用者以影片匹配的位元速率下載檔案。這種特性一般的CDN都會提供支援，好處是改造簡單。可能帶來的問題就是在部分場景下可能會帶來卡頓，忍受網速波動方面會比較有限。需要保持長HTTP連線，對服務端，請求錯誤率監控，客戶端耗電等方面都會帶來一些影響。
-
透過控制播放器的緩衝區長度，降低使用者無謂的內容下載。比如一個影片長度是60秒，正常情況下播放到10秒的時候，如果沒有限制，可能整個影片都會已經下載完成，如果使用者此時退出，就浪費了後面50秒的下載頻寬。透過緩衝區長度控制，我們可以降低中斷播放所帶來的頻寬浪費，平衡每次下載的時間開銷，合理評估緩衝的長度。
[圖二：基於分片下載和播放器緩衝區控制的下載方案]
透過這個改造，我們取得了超出預期的效果，基本上能夠做到在畫質不變的情況下，整體的頻寬成本下降50%以上。
在此基礎上，還可以透過分發編碼效率更高的多位元速率檔案，比如H265(未來包括AV1)，來降低影片位元速率。多位元速率檔案，依靠我們影片排程服務來做策略分發。依賴於客戶端請求排程的決策資訊，包括：客戶端裝置資訊，解析度，網路速度，是否支援H265等判斷調整來整體上做排程決策。
[圖三：融合排程多位元速率策略總體流程]
成功率提升
對成功率提升，我們需要把握一些主要的關鍵點：
-
重試是關鍵，公網請求一定會受到各種情況下的波動影響。對於公網的使用者請求，短超時，有重試是提高成功率的基礎；
-
規避單點服務問題，CDN業務每天都會有一些區域性的波動，在業務上，儘量需要有容災服務備用方案，降低因為單點問題帶來的區域性和波動性影響；
-
各種技術手段，降低客戶端網路請求的錯誤率。
在提高成功率方面，我們做了一些事情：
-
透過融合排程，下發多CDN，在每個地區至少同時提供兩家以上的CDN服務，在其中一家出現問題後，可以快速切換到另外一家CDN。確保客戶端在非本地網路問題的情況下可以播放成功；
-
透過減少網路請求，降低網路錯誤機率；
-
接入FastDNS，提高解析成功率，降低解析延遲。總體上可以降低60-100ms的網路請求延遲，降低了40%的網路請求失敗率。
透過這些技術改造，提高服務的整體抗波動性，區域性故障甚至是全域性性的CDN故障能力，將總體的播放錯誤率從1%，降低到0.1%。同時也降低了網路的請求延遲，主動提高了請求成功率。
[圖四：融合排程多CDN請求流程]
播放體驗最佳化
播放體驗最佳化的核心標的是加快起播速度，降低卡頓發生。為此，我們做了一些針對性的技術改造，總體上也取得了比較不錯的效果。
faststart
目前主流的流媒體格式基本上都是MP4格式，MP4檔案的格式封裝是以box為基礎，整個檔案的封裝格式是有不同型別的box一級一級巢狀組成。其中，每個MP4檔案必須要有的區段有：
-
FTYP，mp4檔案的基礎元資料，包括版本號，相容特性等資訊；
-
MOOV，包含了流媒體資訊的關鍵基礎資訊，包括編碼資訊，時長等等；
-
MDAT，真正的音影片流媒體資料。
如果沒有特殊的調整，MOOV一般會放在影片檔案的最後部分，在播放影片時可能會需要完整下載影片後才能開始播放，這樣就會很大程度上影響到起播時間。將MOOV調整到檔案的前部分，可以讓播放器最快拿到起播的元資料資訊。
[圖五：moov調整]
播發器調整
因為我們所使用的ijkplayer機制關係，在檢測是否可以開始起播，是有一個定時的檢測機制去做資料是否滿足播放標準檢查。這個時間閾值之前是每500ms檢測一次，這樣極大可能就會浪費500ms的時間重新檢測資料是否滿足播放要求。
在ijkplayer 0.8.1 引入FAST_BUFFERING_CHECK_PER_MILLISECONDS配置，將首次的檢查間隔縮短到50ms，從資料表現上可以降低300ms的起播時間。
預批次排程
引入融合排程，提高策略的靈活性，提高服務的整體容災能力的同時引入了另外一個問題就是下載影片前需要做一次額外的排程請求，會增加大概300ms左右的時間，這個是非常敏感的一個體驗下降。
預批次排程是利用業務掃清feed串列到開始播放影片的時間差，最大限度的做影片批次排程，將批次排程結果快取到本地，使使用者在播放影片的時候直接就可以開始播放。由此就可以解決實時排程所帶來的額外請求問題，同時也可以透過批次排程，合併排程請求，降低排程請求數量。
預批次排程適用於任何的業務場景，不受業務場景限制。在引入預批次排程後，幾乎可以抹平因為融合排程所帶來的300ms的起播時間增加，當然因為部分場景下可能還來不及做預批次排程還是會有一點點影響，不過影響面基本可以接受。
預載入
對於提高起播時間來說，預載入是最後的殺手鐧。前面的最佳化都是在利用一切可能的技術手段，降低請求延遲。受限於網路請求本身就會有最佳化的天花板，能夠達到最快起播速度的做法就是播放時不要去做網路請求。在此思路下，我們也逐步引入了預載入策略，也是整個最佳化手段中的最後一環。
預載入，首先需要分析適用場景，預載入實際，成本開銷評估等方面。從場景分析來看，單列feed的直接播放場景是最為合適的預載入場景，雙列feed也是可以做，只是載入快取的使用命中率上可能會偏低，浪費部分頻寬成本。
[圖六：預載入場景]
對於預載入需要載入位元組數，上圖公司已經給出。 600 bytes 是怎麼評估的？因為MOOV的長度是每個影片都不固定的，而且會跟影片的內容長度有直接關係。我們做了一個簡單的調研評估，MOOV大體的每秒位元組數如下：
[圖七：MOOV每秒位元組數]
由此大概推測一個相對比較折中的數字 600 bytes。
總體來看，預載入策略的引入，是我們做到極致用戶體驗非常關鍵一環。透過這個環節的最佳化，我們將50% 左右的播放起播時間降低到0-250ms的分佈區間之內，資料改善極為明顯。
總結
為了控制篇幅，每個最佳化點都不可能介紹的太細，而且細節點有點多，非常適合做一個總體的小結，每個最佳化環節的資料都能夠體現它的重要性：
-
透過下載最佳化，CDN頻寬成本在影片畫質沒有明顯變化的前提下下降50%；
-
減少一次range 0-1 的請求，減少100-200ms左右；
-
FastDNS接入，減少60-100ms左右；
-
融合排程請求，增加300ms左右。播放錯誤率從 1% 左右下降到 0.1% 左右；
-
播放器引數調整，減少300ms左右；
-
批次預排程，減少200-300ms左右；
-
預載入，45%影片在250ms之內，85%影片在750ms之內開始播放。
當前我們也根據我們業務的發展情況，持續在做一些更深層次的最佳化。也希望能夠在畫質最佳化、窄帶高畫質等新興技術方面有更多的嘗試和發展。
阿不老師（黃及峰）在GIAC2018深圳站發表《美拍短影片成本減半及毫秒起播最佳化實踐》，本文是該演講的簡要總結。GIAC大會2018深圳站ppt地址如下https://pan.baidu.com/s/1vSCjttT_KV9YZKJvBZnUQQ
號外
廈門的同學註意啦：美圖網際網路沙龍將於本週六（6月9日）舉行。本期技術沙龍，邀請了來自美圖公司的技術專家與新加坡國立大學的教授，將分享美圖在基於深度學習的推薦排序模型上的一些嘗試和思考，並介紹如何應用機器學習技術進行內容聚類和使用者興趣點挖掘，同時也會分享和機器學習關係密切的最最佳化理論及其在垂直領域的應用。希望能從不同角度帶給大家帶來更多人工智慧與最佳化演演算法在工業界落地的啟發。
想不想和這些有著豐富經驗的一線工程師以及專家學者面對面交流？想不想在週末的時間給自己充點電？
報名正確姿勢，點選“閱讀原文”。
欲瞭解更多美圖技術，請關註下麵的公眾號。
轉載本文請註明出處，技術原創及架構實踐文章，歡迎透過公眾號選單「聯絡我們」進行投稿。
高可用架構
改變網際網路的構建方式
長按二維碼 關註「高可用架構」公眾號
