移動直播技術的極限優化與高效研發

劉恆兵（河伯），騰訊前端技術專家，IVWEB 負責人。現騰訊互動視頻業務前端 TeamLeader ，互動視頻、NOW 直播 Web 負責人，負責互動視頻前端總體架構設計和開發。多年 Web & H5 移動開發經驗，對移動監控和優化有深刻研究，同時推進組件生態，致力於打造高複用、高效率的全棧開發體系。OSC 源創會第55期廣州站講師。

1、直播業務的變革

一、直播業務發展

直播業務最先開始於2013年，當時是社區，功能只有簡單的語音聊天。隨後，YY作了不少從社區轉向娛樂的事情，掀起了在娛樂直播行業的一股小高潮。後來，大量的傳統媒體和一些有粉絲體系、名人效應的傳媒介入之後，直播轉變爲基於PGC的一個體系。這個階段的大部分平臺基本偏向於專業作直播這一塊業務的企業在作，業務質量會相對高一點，那時的行業增加達到了300%。再到後面，發現廣大用戶也有直播需求，這個真正帶動了基於社交的直播。

二、直播業務變革

隨着直播業務的快速發展，給技術人員帶來的挑戰是什麼？技術人員要怎麼應對這個業務帶來的技術上的變革？

首先，從原來簡單的直播，到細分娛樂直播、遊戲直播、體育直播等等，再到用戶的實時直播，直播場景在不斷細化，致使涉及到的技術方案也有必定差別。隨着環境複雜度的變化，網絡場景和用戶場景愈來愈複雜，技術人員須要考慮各類細分的場景，以及各類極端的狀況，而不只僅是平均值。同時，硬件的成熟，給技術人員帶來了更多機會，之前作不出來的效果，隨着機器性能的提高逐步實現。網絡條件的成熟，4G/WIFI的普及也讓直播變得更爲流暢。可是，技術人員也須要用更新的技術來知足用戶的訴求。

三、產品體驗變革

隨着硬件和網絡條件的成熟，用戶對產品體驗的要求也愈來愈高。之前的產品主要在PC端，你們只要集中精力把PC端的產品體驗作好閉環就行，放到移動端可能玩不轉。不少移動端的體驗是基於手機的單屏模式，並且用戶很容易切出直播界面，好比忽然來了個微信消息，要切換過去看。這給技術人員帶來了和PC端不一樣的挑戰。也就是說，隨着移動端的發展成熟，除了技術，產品體驗也在變，這就決定了不少技術方案和技術細節須要不斷地去變化。

四、直播技術變革

綜合來看，對於技術上帶來的挑戰就是：

• 對性能有更高的要求：好比之前可能只要20%的用戶有好的體驗，如今可能要達到90%以上的用戶有好的體驗。

• 低端設備更高體驗：低端機並無消亡，若是有看移動端的基礎設備統計會發現，低端機一直存在。企業若不肯放棄這部分用戶，就至少須要能讓他們有降級的體驗。

• 用戶等待容忍度下降/弱網絡良好體驗：用戶的等待容忍度在不斷下降，之前用戶會認爲本身機器很差、網絡很差，能夠等待加載和延時，但如今他們會認爲是業務體驗差。這時如有其它產品作的更好，你的產品就會被卸載，技術門檻就體如今這裏。

• 互動性、實時性/流暢的交互體驗：直播行業對於實時性和互動性的要求會很是高，主播在直播時若是沒法及時獲得觀衆的響應，體驗會很是糟糕。

2、直播極限優化方案

一、深刻掌握極限優化

挑戰已列出，接下來就要想辦法解決。極限優化這個概念，不一樣的人可能有不一樣的理解方式，但最終的目的是同樣的，配合業務作好體驗。

• 首先，得清楚優化的使用場景，最終是要解決什麼問題，是用戶的體驗問題？仍是性能問題？亦或其它，不能悶頭行動。並且，優化方案帶來的實際提高要有預估，根據投入成本進行預估。

• 同時，要深度分析優化方案的可執行性。由於優化每每不是一我的在作，而是一個團隊在作，若是方案自己就不可執行，那浪費的是一個團隊的時間。並且，要找準關鍵的點在哪裏，根據本身業務的瓶頸來作，不要盲目跟着別人的方案來作。事先清楚和找準後，再去進行深度的方案討論。

• 而後，是要儘可能避免過渡優化。怎麼理解？在作優化方案的時候每每會有不少不少方案，有些提高的比例可能沒那麼高，好比從98%提高到99%，但帶來的人工和維護成本很是大，這個時候就要考量用戶的比量，肯定是否值得投入。

二、常見優化方案

每一個團隊所用的技術、方案都不太同樣，因此在優化上面也會有所差別。在此，針對常見的3種方案進行優化分析：

• 先後端分離：最初的大部分的業務應該都是先後端分離的方式，前端就聚焦在前端上面，後端專一於後端的一些接口、數據的調用。這時要怎麼去優化？首先，隨着業務愈來愈複雜，前端要作分層處理、模塊化，以便維護。同時， 要重點作前端資源加載的優化，由於後端只是在作數據拉取，只要可以抗住量，就沒有太大問題。並且，要清楚每一個資源、數據在異常狀況下帶來的影響。舉個列子，你的業務可能有不少不少的資源，當第一個資源失敗，會帶來什麼結果，第二個資源失敗，又會帶來什麼結果，這些都要很是清楚。不然，當用戶把問題反饋過來時，很難第一時間發現問題所在。此外，網絡場景要去細分，瞭解用戶的重點是在哪裏，是在4G網絡，仍是在WIFI網絡，優化重點要進行偏重。

• 重前端MV*：隨着前端的發展，前端MV*框架越發常見，不少業務、團隊都有在用。這種狀況下的前端更重，就須要考慮前端併發，不能讓用戶去等待不少不少的信息。同時要去作同步渲染降級，讓用戶快速看到。還要考慮在業務裏面的SEO，對於瀏覽器來說，當它拉的信息都是同樣的，它會認爲頁面的更新很是低，搜索引擎很難抓取並更新。

• Node全棧研發：在發現訴求愈來愈多的時候，就須要有一個能同時聚焦到先後端的工具，恰好Node就能幫咱們作不少事情。這和先後端分離有點像，但又不徹底一致。能夠當作，前者是前端一我的後端一我的，但更好的狀況是能先後端只有1我的，這樣他會更清楚先後端的邏輯，並且這些邏輯要儘量的在先後端複用，這個時候就要考慮先後端的複用體系。Node自己很強，但還須要注意更深刻的一些東西，好比TCP/UDP協議的解析。由於你後端的數據是來源於它的後端的一些數據調用，若是這個時候可以用node解決，那是最好的，前提是node能撐住這個量的場景。

三、效率至上

優化的同時，要對團隊的效率進行掌握。效率至上來作優化，纔是合理的。對於效率，能夠從如下幾個方面去看：

第一個是剛纔講的複用體系，先後端複用體系怎麼去複用；

第二個就是須要有完整的構建工程體系，如今其實有不少構建工具，在此不作列舉，能用工具解決的事情都不要去用人力去作，哪怕是一個簡單的更改。由於工具解決不會出問題，但人力解決不免會出問題。

第三個是須要有完整的研發技術棧，研發技術棧決定了團隊的統一性，可以幫助新人快速融入和業務的交接。

四、研發生態

雖說效率至上，但也不能只講效率，還要有全部工具體系的一個生態閉環。它能不能自動更新、自動維護，能不能有一個方式去迭代。好比說其中的一個組件，它可能會升級、會改變，升級的方案是什麼？升級後怎麼快速的可以跑起來、用起來，不出問題？這就是生態，生態會有不少方面，把業務裏面的生態創建起來後，團隊的優化纔是最高效的。

3、直播優化實踐

肯定了方案，下一步就要應用到業務中實踐。一樣，每一個業務的狀況都不同，這裏仍是以直播的業務來舉例。

1.一、監控——加載監控體系

首先，要知道你的業務瓶頸，這就是經過業務的監控分析出來的。沒有監控是很難知道業務的瓶頸在哪裏。那到底要監控哪些點呢？可能有人會比較茫然，那麼多業務，哪些點是重點，哪些點是必需要作的點，難道每一個都要監控嗎？

在此，列出了在業務中須要作的點：

無論是從資源的加載，仍是資源的使用，仍是版本的覆蓋，仍是自己的前端的錯誤，這些都是要作的。若是這些都沒有作，那麼說明對業務的掌控是不夠的，你不知道用戶哪裏出了問題。因此說監控是很重要的點， 如今有不少開源工具能夠幫助你去作，也有不少現成的統計工具。

固然，監控不是最終目的，優化業務和提高業務纔是。工具作好以後，就要去在監控中發現問題，最好是能主動發現問題，而不是被動的依靠用戶投訴。

1.二、監控——視頻流監控體系

在直播業務中，還有個很特別的東西就是視頻流。由於它的特色是量很大，加載對用戶的網絡要求很高，在視頻上面對視頻流須要比傳統的資源更細緻的處理。須要去從它的加載、播放等各個方面作監控和完善。作完這些你才知道你的業務問題和瓶頸在哪裏。而後再通過分析，就能知道要從哪裏下手進行優化。

1.三、監控——機器性能指標監控體系

同時，剛纔也有提到，業務對機器的性能要求愈來愈高。有不少的機器甚至可能根本沒辦法支持很高的FPS業務。性能對業務的影響很是大，一樣的性能，A業務能跑起來，B業務若是跑不起來，用戶的感受就是B業務作得爛，團隊不好。性能可以幫助創建業務的影響力和用戶的口碑。

對於性能，其實也有不少辦法能夠去作監控，好比說給業務在機器上作性能的評分，經過評分可以知道機器究竟是什麼狀況，用戶的機器到底能承載多少FPS業務，再根據結果進行降級和升級優化。這就須要統計和分析用戶究竟是處在什麼樣的機器性能什麼。還有給不一樣動畫進行FPS歸類、針對資源分類打包等等方式，都是監控性能比較好的方式。

1.四、監控——前端日誌監控體系

剛剛也有提到，用戶的環境很是複雜，這也是爲何說作前端要去細分到每一個用戶的緣由。不像作服務端，機器上跑什麼版本你是知道的，搞定這個版本怎麼作就ok。但用戶不同，每一個用戶都是不一樣的，出了問題不必定能知道。在大量的數據狀況下，是須要測試才能測出來的。所以，要對用戶的實際狀況進行監控，到底業務走到哪裏了，沒有走到的緣由是什麼？將這些信息所有收集上來。

二、監控體系的自動化

有了這麼多監控方式，天然但願說它們可以自動化去處理。僅僅依靠人力，每一個業務上線都去弄一遍，那很難跑下來，人力成本會十分恐怖。所以須要去作自動化的處理，可以實時的知道業務出了問題，問題出在哪。並且但願可以經過一些前端的染色，畢竟用戶的網絡其實也是有成本的，什麼都上報，流量費用比其它業務高不少，用戶可能會進行投訴，這就須要染色的能力。染色的能力就是說經過配置server去抓取你想要的用戶出錯信息。

3.一、業務優化實踐——節點、場景優化

有了這些自動化以後，就要開始實踐了。在業務中去實踐的時候能夠看到，一個頁面的加載會分爲不少流程。這些流程下面就是須要去針對細化的各個節點，並肯定每一個點到哪一步須要什麼優化方案。還有在各類場景的細分和劃分，針對這些場景進行優化。

3.二、業務優化實踐——移動頁面性能優化

對直播業務來講，移動端的業務量很是大。所以要學會充分利用性能工具來作事情，學會用工具做分析。同時要關注CPU變化趨勢和GPU渲染能力。若是說實在經過H5已經解決不了問題了，就要適當去找你的環境，環境會提供不少native的能力，無論是用React-Native仍是用原生native接口的方式，都只有一個目標，就是經過環境來幫助你業務能夠更好的體驗。

3.三、業務優化實踐——圖片資源優化

在直播行業，有兩個資源比較重要，一個是視頻，一個是圖片。先看圖片要怎麼去作優化。

圖片其實有不少不少方式能夠作，首先要考慮用戶的狀況：第一，這個圖片能不能快速的加載下來；第二，這個圖片在用戶端能不能快速渲染。這些決定了圖片在業務上打開的快慢。

3.四、業務優化實踐——視頻資源優化

在直播行業，通用的視頻架構幾乎都會包含下面這些模塊，每個模塊在處理時都須要時間，而最終都會體如今影響用戶體驗的時延。主播開始直播，從上傳視頻源的這一秒開始計時，到用戶能看到主播說這話的這個時間段就是時延。時延是直播業務很是重要的參考數據，時延過高，互動性會很是差。

舉例來講，主播開播，那他就是視頻的上行，從上行的開始，要去申請不少不少流程，同時要把這個視頻流作一些格式的封裝和解碼，這就須要處理時間。同時，視頻資源比較大， 不能以普通的服務器來承載，要用CDN這種方式來承載，這時流的傳送也是一個時延。

在下行端也同樣，CDN的架構會有不少不少的雲，用戶接入時候須要從異地雲上拉取資源，這也有時間等待。這裏面的時間最終會體如今用戶的拉取時延上面，打開視頻，可能要等3秒、5秒、10秒。

視頻要怎麼優化？互動時延和加載時延的問題要怎麼解決？

直播業務裏面有一個比較關鍵的數據——GOP關鍵幀，就是一組動畫關鍵幀。在播放器播放時，是按關鍵幀解析，非關鍵幀沒法獨立解析，必須依賴關鍵幀才能去渲染。在移動端H5的播放時須要3個HLS分片，分片是關鍵幀在服務端通過轉碼以後打包後出來的。所以，要解決互動時延的問題，其實就是優化關鍵幀的間隔。好比5秒一個HLS分片，3個就是15秒，那主播說一句話，用戶要等15秒後才能聽到。加載時延就是上面提到的流的分配，能不能優化主動去push到這些節點而不是等用戶去拉取。並且上行不少時候是不穩定的，更須要去作不少不少處理，假設丟包了，不少畫面解析不出來，這時候還要補幀。

另外就是回放，回放和直播惟一的不一樣是不須要互動性，主要須要優化加載時延。這涉及到另一個概念，就是MP4的格式。MP4是按個塊封裝，能夠理解爲一個一個的指針，指針的位置是須要相乘，MP4的文件頭須要下載下來才能播，若是指針的信息愈來愈多，索引愈來愈多的話，不利於加載，這就須要在服務端處理。

4、直播高效研發之道

前面既然說了這麼多須要作的優化工做，那天然是但願可以不用每一個業務都去作一遍，這就須要去作一些研發效率方面的事情，幫助技術人員快速去作這些事情。

研發效率怎麼理解？首先須要有完整的構建體系。這個體系裏的工具是根據業務的特色來選擇，沒有好壞之分，沒只有合適之分。同時，須要組件體系來管理組件，你的先後端複用最終都是要以組件的方式存在，組件能夠把業務分解到很是細的密度，利於更好的複用。在組件的使用上面須要更快捷的使用方式，上傳、更新之後，在須要的時候能快速更新到業務裏面去。這些全部的其實都是基於技術棧的統一。

體系創建之後，怎麼在業務中使用呢？

業務組件分兩種：一是基礎組件，就是沒有業務區分、通用的，這種不涉及邏輯，只有UI組件，使用的時候能夠直接引入UI組件。二是業務組件，須要去作合理的拆分。一般的直播間要拆分爲不少不少點，視頻、點贊、送禮等等。拆分後若是之後有業務不須要點贊功能，把點贊組件引用去掉就能夠，這樣就能快速組成新的業務。在引用的時候有3個原則，第一是以快速的搭建爲目標，第二是用戶只要install下來就能用，三是運行要簡單，不須要某個的時候把它幹掉就好。

5、優化無極限

最後，每一個業務都有不一樣的業務要求，做爲技術人員，要思考的點是優化有沒有極限？沒有！可是業務是有極限的，業務的目標是什麼？業務負責人要充分的考慮這些點。

團隊研發也是同樣的，你的目標是要解決什麼問題？最終要讓團隊達到什麼樣的目標或lever，都是須要考慮的。最終在業務裏面使用的時候，要細分到每一個場景，關注每一個細節，根據這些細分的場景和方案，作業務的支持。