圖片其實有很多很多方式可以做，首先要考慮用戶的情況：第一，這個圖片能不能快速的加載下來；第二，這個圖片在用戶端能不能快速渲染。這些決定了圖片在業(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é)人要充分的考慮這些點。