摘要: 近兩年，直播業(yè)務(wù)爆發(fā)式增長，出現(xiàn)了大量做直播業(yè)務(wù)的企業(yè)和團隊。其中，移動直播更是百家爭鳴，風(fēng)光無兩。這時，各家的產(chǎn)品及業(yè)務(wù)優(yōu)化將很大程度決定市場的認(rèn)可度和口碑。移動直播技術(shù)要如何優(yōu)化？團隊要怎么高效研發(fā)？來聽聽大咖怎么說。
劉恒兵（河伯），騰訊前端技術(shù)專家，IVWEB 負(fù)責(zé)人?，F(xiàn)騰訊互動視頻業(yè)務(wù)前端 TeamLeader ，互動視頻、NOW 直播 Web 負(fù)責(zé)人，負(fù)責(zé)互動視頻前端整體架構(gòu)設(shè)計和開發(fā)。多年 Web & H5 移動開發(fā)經(jīng)驗，對移動監(jiān)控和優(yōu)化有深入研究，同時推動組件生態(tài)，致力于打造高復(fù)用、高效率的全棧開發(fā)體系。OSC 源創(chuàng)會第55期廣州站講師。
一、直播業(yè)務(wù)的變革
1、直播業(yè)務(wù)發(fā)展
直播業(yè)務(wù)最早開始于2013年，當(dāng)時是社區(qū)，功能只有簡單的語音聊天。隨后，YY做了很多從社區(qū)轉(zhuǎn)向娛樂的事情，掀起了在娛樂直播行業(yè)的一股小高潮。后來，大量的傳統(tǒng)媒體和一些有粉絲體系、名人效應(yīng)的傳媒介入以后，直播轉(zhuǎn)變?yōu)榛赑GC的一個體系。這個階段的大部分平臺基本偏向于專業(yè)做直播這一塊業(yè)務(wù)的企業(yè)在做，業(yè)務(wù)質(zhì)量會相對高一點，那時的行業(yè)增長達(dá)到了300%。再到后面，發(fā)現(xiàn)廣大用戶也有直播需求，這個真正帶動了基于社交的直播。
2、直播業(yè)務(wù)變革
隨著直播業(yè)務(wù)的快速發(fā)展，給技術(shù)人員帶來的挑戰(zhàn)是什么？技術(shù)人員要怎么應(yīng)對這個業(yè)務(wù)帶來的技術(shù)上的變革？
首先，從原來簡單的直播，到細(xì)分娛樂直播、游戲直播、體育直播等等，再到用戶的實時直播，直播場景在不斷細(xì)化，導(dǎo)致涉及到的技術(shù)方案也有一定差異。隨著環(huán)境復(fù)雜度的變化，網(wǎng)絡(luò)場景和用戶場景越來越復(fù)雜，技術(shù)人員需要考慮各種細(xì)分的場景，以及各種極端的情況，而不僅僅是平均值。同時，硬件的成熟，給技術(shù)人員帶來了更多機會，以前做不出來的效果，隨著機器性能的提升逐步實現(xiàn)。網(wǎng)絡(luò)條件的成熟，4G/WIFI的普及也讓直播變得更為流暢。但是，技術(shù)人員也需要用更新的技術(shù)來滿足用戶的訴求。
3、產(chǎn)品體驗變革
隨著硬件和網(wǎng)絡(luò)條件的成熟，用戶對產(chǎn)品體驗的要求也越來越高。以前的產(chǎn)品主要在PC端，大家只要集中精力把PC端的產(chǎn)品體驗做好閉環(huán)就行，放到移動端可能玩不轉(zhuǎn)。很多移動端的體驗是基于手機的單屏模式，而且用戶很容易切出直播界面，比如突然來了個微信消息，要切換過去看。這給技術(shù)人員帶來了和PC端不同的挑戰(zhàn)。也就是說，隨著移動端的發(fā)展成熟，除了技術(shù)，產(chǎn)品體驗也在變，這就決定了很多技術(shù)方案和技術(shù)細(xì)節(jié)需要不斷地去變化。
4、直播技術(shù)變革
綜合來看，對于技術(shù)上帶來的挑戰(zhàn)就是：
對性能有更高的要求：比如以前可能只要20%的用戶有好的體驗，現(xiàn)在可能要達(dá)到90%以上的用戶有好的體驗。
低端設(shè)備更高體驗：低端機并沒有消亡，如果有看移動端的基礎(chǔ)設(shè)備統(tǒng)計會發(fā)現(xiàn)，低端機一直存在。企業(yè)若不愿放棄這部分用戶，就至少需要能讓他們有降級的體驗。
用戶等待容忍度降低/弱網(wǎng)絡(luò)良好體驗：用戶的等待容忍度在不斷降低，以前用戶會認(rèn)為自己機器不好、網(wǎng)絡(luò)不好，可以等待加載和延時，但現(xiàn)在他們會認(rèn)為是業(yè)務(wù)體驗差。這時若有其它產(chǎn)品做的更好，你的產(chǎn)品就會被卸載，技術(shù)門檻就體現(xiàn)在這里。
互動性、實時性/流暢的交互體驗：直播行業(yè)對于實時性和互動性的要求會非常高，主播在直播時如果無法及時得到觀眾的響應(yīng)，體驗會非常糟糕。
二、直播極限優(yōu)化方案
1、深入掌握極限優(yōu)化
挑戰(zhàn)已列出，接下來就要想辦法解決。極限優(yōu)化這個概念，不同的人可能有不同的理解方式，但最終的目的是一樣的，配合業(yè)務(wù)做好體驗。
首先，得清楚優(yōu)化的使用場景，最終是要解決什么問題，是用戶的體驗問題？還是性能問題？亦或其它，不能悶頭行動。而且，優(yōu)化方案帶來的實際提升要有預(yù)估，根據(jù)投入成本進行預(yù)估。
同時，要深度分析優(yōu)化方案的可執(zhí)行性。因為優(yōu)化往往不是一個人在做，而是一個團隊在做，如果方案本身就不可執(zhí)行，那浪費的是一個團隊的時間。而且，要找準(zhǔn)關(guān)鍵的點在哪里，根據(jù)自己業(yè)務(wù)的瓶頸來做，不要盲目跟著別人的方案來做。事先清楚和找準(zhǔn)后，再去進行深度的方案討論。
然后，是要盡量避免過渡優(yōu)化。怎么理解？在做優(yōu)化方案的時候往往會有很多很多方案，有些提升的比例可能沒那么高，比如從98%提升到99%，但帶來的人工和維護成本非常大，這個時候就要考量用戶的比量，確定是否值得投入。
2、常見優(yōu)化方案
每個團隊所用的技術(shù)、方案都不太一樣，所以在優(yōu)化上面也會有所差異。在此，針對常見的3種方案進行優(yōu)化分析：
前后端分離：最初的大部分的業(yè)務(wù)應(yīng)該都是前后端分離的方式，前端就聚焦在前端上面，后端專注于后端的一些接口、數(shù)據(jù)的調(diào)用。這時要怎么去優(yōu)化？首先，隨著業(yè)務(wù)越來越復(fù)雜，前端要做分層處理、模塊化，以便維護。同時， 要重點做前端資源加載的優(yōu)化，因為后端只是在做數(shù)據(jù)拉取，只要能夠抗住量，就沒有太大問題。而且，要清楚每個資源、數(shù)據(jù)在異常情況下帶來的影響。舉個列子，你的業(yè)務(wù)可能有很多很多的資源，當(dāng)?shù)谝粋€資源失敗，會帶來什么結(jié)果，第二個資源失敗，又會帶來什么結(jié)果，這些都要非常清楚。否則，當(dāng)用戶把問題反饋過來時，很難第一時間發(fā)現(xiàn)問題所在。此外，網(wǎng)絡(luò)場景要去細(xì)分，了解用戶的重點是在哪里，是在4G網(wǎng)絡(luò)，還是在WIFI網(wǎng)絡(luò)，優(yōu)化重點要進行偏重。
重前端MV：隨著前端的發(fā)展，前端MV框架愈加常見，很多業(yè)務(wù)、團隊都有在用。這種情況下的前端更重，就需要考慮前端并發(fā)，不能讓用戶去等待很多很多的信息。同時要去做同步渲染降級，讓用戶快速看到。還要考慮在業(yè)務(wù)里面的SEO，對于瀏覽器來講，當(dāng)它拉的信息都是一樣的，它會認(rèn)為頁面的更新非常低，搜索引擎很難抓取并更新。
Node全棧研發(fā)：在發(fā)現(xiàn)訴求越來越多的時候，就需要有一個能同時聚焦到前后端的工具，剛好Node就能幫我們做很多事情。這和前后端分離有點像，但又不完全一致?？梢钥闯?，前者是前端一個人后端一個人，但更好的情況是能前后端只有1個人，這樣他會更清楚前后端的邏輯，而且這些邏輯要盡可能的在前后端復(fù)用，這個時候就要考慮前后端的復(fù)用體系。Node本身很強，但還需要注意更深入的一些東西，比如TCP/UDP協(xié)議的解析。因為你后端的數(shù)據(jù)是來源于它的后端的一些數(shù)據(jù)調(diào)用，如果這個時候能夠用node解決，那是最好的，前提是node能撐住這個量的場景。
3、效率至上
優(yōu)化的同時，要對團隊的效率進行掌握。效率至上來做優(yōu)化，才是合理的。對于效率，可以從以下幾個方面去看：
第一個是剛才講的復(fù)用體系，前后端復(fù)用體系怎么去復(fù)用；
第二個就是需要有完整的構(gòu)建工程體系，現(xiàn)在其實有很多構(gòu)建工具，在此不做列舉，能用工具解決的事情都不要去用人力去做，哪怕是一個簡單的更改。因為工具解決不會出問題，但人力解決難免會出問題。
第三個是需要有完整的研發(fā)技術(shù)棧，研發(fā)技術(shù)棧決定了團隊的統(tǒng)一性，能夠幫助新人快速融入和業(yè)務(wù)的交接。
4、研發(fā)生態(tài)
雖然說效率至上，但也不能只講效率，還要有所有工具體系的一個生態(tài)閉環(huán)。它能不能自動更新、自動維護，能不能有一個方式去迭代。比如說其中的一個組件，它可能會升級、會改變，升級的方案是什么？升級后怎么快速的能夠跑起來、用起來，不出問題？這就是生態(tài)，生態(tài)會有很多方面，把業(yè)務(wù)里面的生態(tài)建立起來后，團隊的優(yōu)化才是最高效的。
三、直播優(yōu)化實踐
確定了方案，下一步就要應(yīng)用到業(yè)務(wù)中實踐。同樣，每個業(yè)務(wù)的情況都不一樣，這里還是以直播的業(yè)務(wù)來舉例。
1.1、監(jiān)控——加載監(jiān)控體系
首先，要知道你的業(yè)務(wù)瓶頸，這就是通過業(yè)務(wù)的監(jiān)控分析出來的。沒有監(jiān)控是很難知道業(yè)務(wù)的瓶頸在哪里。那到底要監(jiān)控哪些點呢？可能有人會比較茫然，那么多業(yè)務(wù)，哪些點是重點，哪些點是必須要做的點，難道每個都要監(jiān)控嗎？
在此，列出了在業(yè)務(wù)中需要做的點：
不管是從資源的加載，還是資源的使用，還是版本的覆蓋，還是本身的前端的錯誤，這些都是要做的。如果這些都沒有做，那么說明對業(yè)務(wù)的掌控是不夠的，你不知道用戶哪里出了問題。所以說監(jiān)控是很重要的點， 現(xiàn)在有很多開源工具可以幫助你去做，也有很多現(xiàn)成的統(tǒng)計工具。
當(dāng)然，監(jiān)控不是最終目的，優(yōu)化業(yè)務(wù)和提升業(yè)務(wù)才是。工具做好之后，就要去在監(jiān)控中發(fā)現(xiàn)問題，最好是能主動發(fā)現(xiàn)問題，而不是被動的依靠用戶投訴。
1.2、監(jiān)控——視頻流監(jiān)控體系
在直播業(yè)務(wù)中，還有個很特別的東西就是視頻流。因為它的特點是量很大，加載對用戶的網(wǎng)絡(luò)要求很高，在視頻上面對視頻流需要比傳統(tǒng)的資源更細(xì)致的處理。需要去從它的加載、播放等各個方面做監(jiān)控和完善。做完這些你才知道你的業(yè)務(wù)問題和瓶頸在哪里。然后再經(jīng)過分析，就能知道要從哪里下手進行優(yōu)化。
1.3、監(jiān)控——機器性能指標(biāo)監(jiān)控體系
同時，剛才也有提到，業(yè)務(wù)對機器的性能要求越來越高。有很多的機器甚至可能根本沒辦法支持很高的FPS業(yè)務(wù)。性能對業(yè)務(wù)的影響非常大，同樣的性能，A業(yè)務(wù)能跑起來，B業(yè)務(wù)如果跑不起來，用戶的感覺就是B業(yè)務(wù)做得爛，團隊很差。性能能夠幫助建立業(yè)務(wù)的影響力和用戶的口碑。
對于性能，其實也有很多辦法可以去做監(jiān)控，比如說給業(yè)務(wù)在機器上做性能的評分，通過評分能夠知道機器到底是什么情況，用戶的機器到底能承載多少FPS業(yè)務(wù)，再根據(jù)結(jié)果進行降級和升級優(yōu)化。這就需要統(tǒng)計和分析用戶到底是處在什么樣的機器性能什么。還有給不同動畫進行FPS歸類、針對資源分類打包等等方式，都是監(jiān)控性能比較好的方式。
1.4、監(jiān)控——前端日志監(jiān)控體系
剛剛也有提到，用戶的環(huán)境非常復(fù)雜，這也是為什么說做前端要去細(xì)分到每個用戶的原因。不像做服務(wù)端，機器上跑什么版本你是知道的，搞定這個版本怎么做就ok。但用戶不一樣，每個用戶都是不同的，出了問題不一定能知道。在大量的數(shù)據(jù)情況下，是需要測試才能測出來的。因此，要對用戶的實際情況進行監(jiān)控，到底業(yè)務(wù)走到哪里了，沒有走到的原因是什么？將這些信息全部收集上來。
2、監(jiān)控體系的自動化
有了這么多監(jiān)控方式，自然希望說它們能夠自動化去處理。僅僅依靠人力，每個業(yè)務(wù)上線都去弄一遍，那很難跑下來，人力成本會十分恐怖。因此需要去做自動化的處理，能夠?qū)崟r的知道業(yè)務(wù)出了問題，問題出在哪。而且希望能夠通過一些前端的染色，畢竟用戶的網(wǎng)絡(luò)其實也是有成本的，什么都上報，流量費用比其它業(yè)務(wù)高很多，用戶可能會進行投訴，這就需要染色的能力。染色的能力就是說通過配置server去抓取你想要的用戶出錯信息。
3.1、業(yè)務(wù)優(yōu)化實踐——節(jié)點、場景優(yōu)化
有了這些自動化之后，就要開始實踐了。在業(yè)務(wù)中去實踐的時候可以看到，一個頁面的加載會分為很多流程。這些流程下面就是需要去針對細(xì)化的各個節(jié)點，并確定每個點到哪一步需要什么優(yōu)化方案。還有在各種場景的細(xì)分和劃分，針對這些場景進行優(yōu)化。
3.2、業(yè)務(wù)優(yōu)化實踐——移動頁面性能優(yōu)化
對直播業(yè)務(wù)來說，移動端的業(yè)務(wù)量非常大。因此要學(xué)會充分利用性能工具來做事情，學(xué)會用工具作分析。同時要關(guān)注CPU變化趨勢和GPU渲染能力。如果說實在通過H5已經(jīng)解決不了問題了，就要適當(dāng)去找你的環(huán)境，環(huán)境會提供很多native的能力，不管是用React-Native還是用原生native接口的方式，都只有一個目標(biāo)，就是通過環(huán)境來幫助你業(yè)務(wù)可以更好的體驗。
3.3、業(yè)務(wù)優(yōu)化實踐——圖片資源優(yōu)化
在直播行業(yè)，有兩個資源比較重要，一個是視頻，一個是圖片。先看圖片要怎么去做優(yōu)化。
圖片其實有很多很多方式可以做，首先要考慮用戶的情況：第一，這個圖片能不能快速的加載下來；第二，這個圖片在用戶端能不能快速渲染。這些決定了圖片在業(yè)務(wù)上打開的快慢。
3.4、業(yè)務(wù)優(yōu)化實踐——視頻資源優(yōu)化
在直播行業(yè)，通用的視頻架構(gòu)幾乎都會包含下面這些模塊，每一個模塊在處理時都需要時間，而最終都會體現(xiàn)在影響用戶體驗的時延。主播開始直播，從上傳視頻源的這一秒開始計時，到用戶能看到主播說這話的這個時間段就是時延。時延是直播業(yè)務(wù)非常重要的參考數(shù)據(jù)，時延太高，互動性會非常差。
舉例來說，主播開播，那他就是視頻的上行，從上行的開始，要去申請很多很多流程，同時要把這個視頻流做一些格式的封裝和解碼，這就需要處理時間。同時，視頻資源比較大， 不能以普通的服務(wù)器來承載，要用CDN這種方式來承載，這時流的傳送也是一個時延。
在下行端也一樣，CDN的架構(gòu)會有很多很多的云，用戶接入時候需要從異地云上拉取資源，這也有時間等待。這里面的時間最終會體現(xiàn)在用戶的拉取時延上面，打開視頻，可能要等3秒、5秒、10秒。
視頻要怎么優(yōu)化？互動時延和加載時延的問題要怎么解決？
直播業(yè)務(wù)里面有一個比較關(guān)鍵的數(shù)據(jù)——GOP關(guān)鍵幀，就是一組動畫關(guān)鍵幀。在播放器播放時，是按關(guān)鍵幀解析，非關(guān)鍵幀無法獨立解析，必須依賴關(guān)鍵幀才能去渲染。在移動端H5的播放時需要3個HLS分片，分片是關(guān)鍵幀在服務(wù)端經(jīng)過轉(zhuǎn)碼之后打包后出來的。因此，要解決互動時延的問題，其實就是優(yōu)化關(guān)鍵幀的間隔。比如5秒一個HLS分片，3個就是15秒，那主播說一句話，用戶要等15秒后才能聽到。加載時延就是上面提到的流的分配，能不能優(yōu)化主動去push到這些節(jié)點而不是等用戶去拉取。而且上行很多時候是不穩(wěn)定的，更需要去做很多很多處理，假設(shè)丟包了，很多畫面解析不出來，這時候還要補幀。
另外就是回放，回放和直播唯一的不同是不需要互動性，主要需要優(yōu)化加載時延。這涉及到另外一個概念，就是MP4的格式。MP4是按個塊封裝，可以理解為一個一個的指針，指針的位置是需要相乘，MP4的文件頭需要下載下來才能播，如果指針的信息越來越多，索引越來越多的話，不利于加載，這就需要在服務(wù)端處理。
四、直播高效研發(fā)之道
前面既然說了這么多需要做的優(yōu)化工作，那自然是希望能夠不用每個業(yè)務(wù)都去做一遍，這就需要去做一些研發(fā)效率方面的事情，幫助技術(shù)人員快速去做這些事情。
研發(fā)效率怎么理解？首先需要有完整的構(gòu)建體系。這個體系里的工具是根據(jù)業(yè)務(wù)的特點來選擇，沒有好壞之分，沒只有合適之分。同時，需要組件體系來管理組件，你的前后端復(fù)用最終都是要以組件的方式存在，組件可以把業(yè)務(wù)分解到非常細(xì)的密度，利于更好的復(fù)用。在組件的使用上面需要更快捷的使用方式，上傳、更新以后，在需要的時候能快速更新到業(yè)務(wù)里面去。這些所有的其實都是基于技術(shù)棧的統(tǒng)一。
體系建立以后，怎么在業(yè)務(wù)中使用呢？
業(yè)務(wù)組件分兩種：一是基礎(chǔ)組件，就是沒有業(yè)務(wù)區(qū)分、通用的，這種不涉及邏輯，只有UI組件，使用的時候可以直接引入UI組件。二是業(yè)務(wù)組件，需要去做合理的拆分。通常的直播間要拆分為很多很多點，視頻、點贊、送禮等等。拆分后如果以后有業(yè)務(wù)不需要點贊功能，把點贊組件引用去掉就可以，這樣就能快速組成新的業(yè)務(wù)。在引用的時候有3個原則，第一是以快速的搭建為目標(biāo)，第二是用戶只要install下來就能用，三是運行要簡單，不需要某個的時候把它干掉就好。
五、優(yōu)化無極限
最后，每個業(yè)務(wù)都有不同的業(yè)務(wù)要求，作為技術(shù)人員，要思考的點是優(yōu)化有沒有極限？沒有！但是業(yè)務(wù)是有極限的，業(yè)務(wù)的目標(biāo)是什么？業(yè)務(wù)負(fù)責(zé)人要充分的考慮這些點。
團隊研發(fā)也是一樣的，你的目標(biāo)是要解決什么問題？最終要讓團隊達(dá)到什么樣的目標(biāo)或lever，都是需要考慮的。最終在業(yè)務(wù)里面使用的時候，要細(xì)分到每個場景，關(guān)注每個細(xì)節(jié)，根據(jù)這些細(xì)分的場景和方案，做業(yè)務(wù)的支持。
? 著作權(quán)歸作者所有
分類：OSC源創(chuàng)會
字?jǐn)?shù)：5356
