看了許多直播優(yōu)化的方案，寫此文記錄一下，涉及少分部服務端方案，不涉及具體代碼。
具體方案分為三個部分：
1、直播大廳的優(yōu)化。
2、直播間內的優(yōu)化。
3、私信消息模塊的優(yōu)化。
直播大廳的優(yōu)化：
直播列表的刷新
問題：
1、作為App的入口，其高可用性十分重要。
2、用戶點擊進入直播間后，發(fā)現(xiàn)直播已經結束，體驗不好。
3、主播們的及時露臉、吸引粉絲的需求。
方案
1、多種刷新機制相結合
- 全量刷新。
- 頂部刷新，按滑動屏幕的偏移量。
- 局部刷新，對直播流進行分組，只更新用戶當前界面的直播流，便于服務端實施緩存策略。
- 刷新的時間間隔可配置。
2、用戶體驗方面
- 用戶當前正在滑動屏幕時，延遲刷新當前頁面。
進入直播間速度的優(yōu)化
常見現(xiàn)象：
1、用戶點擊某個直播之后，進入直播間頁面較慢。
2、直播間內的視頻遲遲加載不出。
3、主播開播后反映人氣一直上不去。
原因分析：
1、獲取視頻流時建立網(wǎng)絡連接的耗時。
2、直播間內業(yè)務模塊眾多，界面初始化耗時。
方案
- 在直播間大廳預先解析視頻流地址，從而加快獲取視頻數(shù)據(jù)的速度。
- 對房間內部分UI模塊使用懶加載方式，如：公聊、用戶列表等。
B57D20E2-A3FB-4F5A-A689-612E60E8BA2E.png
直播間內的優(yōu)化：
定時器事件調度
8CD488F8-576B-4EA7-805C-EF412CBD619C.png
房間內長連接消息的處理（公聊消息列表刷新）
問題現(xiàn)象：
熱門直播間大量的公聊消息使得列表持續(xù)快速刷新，導致主線程CPU占用較高，影響整體頁面交互。
優(yōu)化思路：
- 將處理長鏈接消息的SocketIO庫中的block執(zhí)行線程設置為非主線程，緩解主線程的CPU占用。
EC21793A-D738-48F7-A2D1-EF45CFD549BB.png- 實時統(tǒng)計單位時間內收到的消息數(shù)目，在性能較低的機型上，動態(tài)調整公聊列表的刷新頻率。
- 使用隊列暫存消息，每條公聊消息到來時不直接刷新列表。
- 批量地pop隊列中的消息，只保留最近收到的一些消息進行滾動刷新。
動畫流暢
問題現(xiàn)象：
大量的禮物動畫如何進行流暢的展示。
優(yōu)化思路：
- 動畫進行隊列分優(yōu)先級排列，對于同個時間段內的動畫根據(jù)優(yōu)先級高的的優(yōu)先顯示，其余可延遲或者拋棄動畫顯示。
主播端體驗優(yōu)化
問題現(xiàn)象：
主播直播了很久，好不容易上了熱門，發(fā)生App崩潰如何處理。
優(yōu)化思路：
- 開始直播時保存推流地址信息, App崩潰后，再次啟動可以繼續(xù)直播,恢復效果上相當于一次切后臺的操作。
問題現(xiàn)象：
如何應對運營活動時的房間內消息壓力，短時間內服務器廣播消息壓力非常大，公聊和禮物消息持續(xù)刷屏，主播直播嚴重受干擾。
優(yōu)化思路：
- 服務降級，下發(fā)限制客戶端公聊和禮物消息發(fā)送頻率的命令。
- 限制點贊和部分禮物的動畫展示
減輕服務端并發(fā)請求方面的優(yōu)化
問題現(xiàn)象：
1、用戶關注關系的拉?。好看芜M入直播間，都需要請求用戶列表中的關注關系；主播結束直播時，用戶都需要拉取和主播的關注關系。
2、推送消息：明星用戶開播全量推送時，大量客戶端同時拉取大廳直播列表。
優(yōu)化思路：
- 對用戶profile、關注關系等信息進行緩存。
- 收到直播推送時，不立即刷新直播列表，延遲到退出直播間后再啟動大廳刷新機制。
客戶端首次啟動方面的優(yōu)化
問題現(xiàn)象：
用戶安裝App后首次啟動，點擊登錄按鈕出現(xiàn)卡頓。
原因分析：
需要下載大量的圖片資源，網(wǎng)絡請求和文件操作頻繁。
優(yōu)化思路：
- 對部分禮物和等級圖標資源進行內置，增量下載更新。
私信消息模塊的優(yōu)化：
D807EDF8-66E8-4A2C-96BE-11E549AE879F.png
問題現(xiàn)象：
私信聊天頁面的打開速度和消息瀏覽的體驗。
優(yōu)化思路：
- 內存中只緩存少量的幾十條數(shù)據(jù)用于展示，滑動屏幕瀏覽時，動態(tài)更新緩存內容。
