前言

做直播APP也有一段時間，自身是多年直播觀眾，總結下這段時間研發(fā)的收獲以及業(yè)務介紹。

歡迎關注文集-直播Live：

• 直播APP的性能優(yōu)化-禮物篇
• 使用VideoToolbox硬編碼H.264
• 使用VideoToolbox硬解碼H.264
• 使用AudioToolbox編碼AAC
• 使用AudioToolbox播放AAC
• HLS點播實現（H.264和AAC碼流）
• HLS推流的實現（iOS和OS X系統）

功能介紹

直播APP的常用業(yè)務如下。

1、聊天

私聊、聊天室、點亮、推送、黑名單等；

2、禮物

普通禮物、豪華禮物、紅包、排行榜、第三方充值、內購、禮物動態(tài)更新、提現等；

3、直播列表

關注、熱門、最新、分類直播用戶列表等；

4、自己直播

錄制、推流、解碼、播放、美顏、心跳、后臺切換、主播對管理員操作、管理員對用戶等；

5、房間邏輯

創(chuàng)建房間、進入房間、退出房間、關閉房間、切換房間、房間管理員設置、房間用戶列表等；

6、用戶邏輯

普通登陸、第三方登陸、注冊、搜索、修改個人信息、關注列表、粉絲列表、忘記密碼、查看個人信息、收入榜、關注和取關、檢索等；

7、觀看直播

聊天信息、滾屏彈幕、禮物顯示、加載界面等；

8、統計

APP業(yè)務統計、第三方統計等；

9、超管

禁播、隱藏、審核等；

架構

直播APP的業(yè)務邏輯不復雜，使用基本的MVC框架即可。

• 部分Controller的業(yè)務邏輯較多，獨立的業(yè)務可以拆分出去作為一個單獨的Catagory；
• Model的數據變化采用event（notification）的形式通知，便于做多處數據綁定；
• Model之間的相互獨立，如果由業(yè)務需要，需要交換Model的數據，由Controller代為處理；
• HTTPService為AFNetworking封裝，回調Model以Block塊為主，特殊的業(yè)務邏輯以event（notification）的形式通知；

具體模塊

視圖

1、GiftView

顯示禮物，管理小禮物與豪華禮物動畫；
核心：
小禮物連擊效果，隊列存儲豪華禮物消息，播放完畢回調。
小禮物用CAAnimation動畫和UIView Block動畫；
豪華禮物用CAAnimation動畫和UIView Block動畫+GCD協調；

2、MessageView

顯示聊天消息，彈幕消息。
核心：
聊天tableView，用NSMutableAttributedString顯示富文本；
- (CGRect)boundingRectWithSize:options: attributes:context:計算高度并緩存；
彈幕消息用隊列存儲彈幕，UIViewBlock動畫循環(huán)播放，最多同時顯示條數限制；

3、RoomTableView

顯示房間列表
核心：
MJRefresh做上下拉刷新，以時間為軸；

4、ChatView

聊天界面，直播間內半屏顯示，直播間外全屏顯示；
核心：
用第三方聊天界面，直播間內用addChildViewController的方式，直接加載第三方ViewController；

控制器

1、ChatViewController

第三方聊天控制器做基類，自定義業(yè)務邏輯，包括私聊送禮物、廣告屏蔽等，包括ChatListViewController和ChatDetailViewController。

2、WatchLiveViewController

觀看直播控制器，包括LivePlayer（視頻流播放器），房間業(yè)務邏輯相關，接受聊天消息轉發(fā)給MessageView，切換前后臺（APP生命周期）控制；

3、PushLiveViewController

推流直播控制器，包括推流相關邏輯，直播定時器，房間業(yè)務邏輯相關，聊天消息轉發(fā)給MessageView，主播離開、切換后臺等控制；

數據層

1、LiveRoom

房間的數據結構，存儲房間信息，包括管理員、主播ID、房間推流、拉流地址、房間用戶列表等等；

2、LiveUser

直播的用戶數據結構，包括昵稱、頭像、ID、等級、榜單等；

3、ChatUser/Message

聊天的用戶數據結構，包括頭像、昵稱、ID等，Message是消息類型，包括直播間普通的Message、（節(jié)省流量）打包用的QueueMessage，私聊聊天的TextMessage、PhotoMessage等；

服務層

1、IMService

IM功能，提供私聊，直播間消息廣播等。

2、LiveService

推流和拉流功能，提供錄制、推送視頻流到服務器，拉取視頻流和播放視頻；

3、LoginService

登陸功能，手機號碼登陸，第三方（QQ、微信、新浪）登陸；

4、IAPService

內購功能，蘋果內購；

5、PayService

第三方支付，微信支付和支付寶支付；

6、PushService

推送功能，聊天消息推送，直播開播推送，活動推送等；

7、AnalysisService

統計功能，APP自身統計上傳到服務器，第三方統計；

Pod庫

1、AFNetworking

負責所有Http請求，業(yè)務層會封裝Manager；

2、GPUImage

采集視頻，并對視頻流進行美顏處理；

3、RMStore

蘋果內購支持；

4、SDWebImage

負責加載圖片，包括頭像、禮物圖片等；

業(yè)務問題分析

1、聊天室消息過多

產品運營一段時間后，消息量不斷攀升，最高到100billion，后來IM方優(yōu)化后，量級穩(wěn)定在10billion，但是消息量仍舊過大。
通過對消息歷史記錄進行數據分析，發(fā)現瓶頸在enter和exit消息，占比為84%。
分析：在線用戶交多，頻繁進出房的動作導致需要不斷發(fā)送enter和exit消息，可以預計，當房間內人數越來越多之后，將會有更多的進出房消息，同時增長速度為平方級別。
總結：客戶端和服務器之間的實時消息過多，同時都是密集操作。
解決方案：
人數較多的房間，等級小于一定級別（服務器下發(fā)）則不發(fā)送進出房消息；
級別較高的用戶進入房間時，會在進房消息攜帶數據以同步房間信息；

2、房間活躍度計算

設有活躍度（禮物G、聊天M） 、 在線人數N、 直播時間T
G為本次直播收到的Y幣數
M為本次直播發(fā)出的消息數
N為本次直播在線人數
T為本次直播的分鐘數
本次直播的成本為N * k1 + M * k2，k1為帶寬成本常數，k2為IM成本常數。
聊天成本暫不考慮，那么成本為N * k1。

視頻帶寬的價格20元/M每個月，用戶觀看的速度為150k/s左右，那么每個用戶高峰成本為7元每個月，每日成本為2.3元。用戶人均每日觀看2小時，那么每分鐘的成本為0.02元。
我們的最高在線/活躍人數是0.18，那么一個普通用戶每分鐘的期望成本k1 = 0.18*0.02 = 0.004元。

我們的每分鐘收入為x = G / T * 0.66 - N * 0.004
對于一個已經在直播的主播，如果x 大于0，那么屬于為平臺賺錢主播，可以放在列表前面。

預計：
按照目前的水平，假設一個1000人觀看的主播，每天2個小時的直播，收入應該在10000Y幣。
每小時應該有5000Y幣，每分鐘應該有84個Y幣。我們的收入有5.6元。
那么對于一個新開直播的主播，她的預設x值為1.6。

總結：
每分鐘按照收入x排序,
如果是已經開播的主播，x = G / T * 0.66 - N * 0.004；
如果是剛開未滿一分鐘的主播，x=1.6。

3、HTTP代理篡改get參數

通過HTTP代理工具，篡改移動端發(fā)給服務器的get參數。舉個例子，用戶點的是豪華禮物，通過HTTP代理工具把發(fā)送給服務器的請求的禮物ID改為普通禮物的ID。
解決方案：
1、改用HTTPS；
2、添加校驗碼；
解釋下方案2，把所有的get參數，key按照字符串順序排序，value用"/"串起來，最后再加一串特定的字符，最終對這串值進行MD5，把MD5的串添加到code字段。客戶端、服務器都對核心邏輯收到的消息，進行一次校驗。

總結

時間有限，大多數核心邏輯沒有深入介紹。感興趣的可以在評論區(qū)交流。

• GPUImage文集是閑暇之余閱讀GPUImage源碼的收獲；
• OpenGL ES文集同樣是閑暇之余學習OpenGL ES的總結；

GPUImage僅是目前iOS用到的圖像處理庫，OpenGL ES是自己為下一波熱潮的預熱。