直播系統原始碼，ios系統開發的基本架構

架構

直播系統原始碼的業務邏輯不復雜，使用基本的MVC框架即可。

• 部分Controller的業務邏輯較多，獨立的業務可以拆分出去作為一個單獨的Catagory；
• Model的資料變化採用event（notification）的形式通知，便於做多處資料繫結；
• Model之間的相互獨立，如果由業務需要，需要交換Model的資料，由Controller代為處理；
• HTTPService為AFNetworking封裝，回撥Model以Block塊為主，特殊的業務邏輯以event（notification）的形式通知；
  

檢視

1、GiftView

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

2、MessageView

顯示聊天訊息，彈幕訊息。 核心： 聊天tableView，用 NSMutableAttributedString顯示富文字； - (CGRect)boundingRectWithSize:options: attributes:context:計算高度並快取；直播系統原始碼的彈幕訊息用佇列儲存彈幕，UIViewBlock動畫迴圈播放，最多同時顯示條數限制；

3、RoomTableView

顯示直播系統原始碼房間列表 核心： MJRefresh做上下拉重新整理， 以時間為軸；

4、ChatView

直播系統原始碼聊天介面， 直播間內半屏顯示，直播間外全屏顯示； 核心： 用第三方聊天介面，直播間內用 addChildViewController的方式，直接載入第三方ViewController；

控制器

1、ChatViewController

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

2、WatchLiveViewController

觀看直播控制器，包括LivePlayer（影片流播放器），房間業務邏輯相關，接受聊天訊息轉發給MessageView，切換前後臺（APP生命週期）控制；

3、PushLiveViewController

推流直播控制器，包括推流相關邏輯，直播定時器，房間業務邏輯相關，聊天訊息轉發給MessageView，主播離開、切換後臺等控制；

資料層

1、LiveRoom

房間的資料結構，儲存房間資訊，包括管理員、主播ID、房間推流、拉流地址、房間使用者列表等等；

2、LiveUser

直播的使用者資料結構，包括暱稱、頭像、ID、等級、榜單等；

3、ChatUser/Message

聊天的使用者資料結構，包括頭像、暱稱、ID等，Message是訊息型別，包括直播間普通的Message、（節省流量）打包用的QueueMessage，私聊聊天的TextMessage、PhotoMessage等；

服務層

1、IMService

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

2、LiveService

推流和拉流功能，提供錄製、推送影片流到伺服器，拉取影片流和播放影片；

3、LoginService

直播系統原始碼登陸功能，手機號碼登陸，第三方（QQ、微信、新浪）登陸；

4、IAPService

內購功能，蘋果內購；

5、PayService

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

6、PushService

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

7、AnalysisService

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

Pod庫

1、AFNetworking

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

2、GPUImage

採集影片，並對影片流進行美顏處理；

3、RMStore

蘋果內購支援；

4、SDWebImage

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

業務問題分析

1、聊天室訊息過多

產品運營一段時間後，訊息量不斷攀升，最高到100billion，後來IM方最佳化後，量級穩定在10billion，但是訊息量仍舊過大。 透過對訊息歷史記錄進行資料分析，發現瓶頸在enter和exit訊息，佔比為84%。 分析：線上使用者交多，頻繁進出房的動作導致需要不斷髮送enter和exit訊息，可以預計，當房間內人數越來越多之後，將會有更多的進出房訊息，同時增長速度為 平方級別。 總結：直播系統原始碼和伺服器之間的實時訊息過多，同時都是密集操作。 解決方案： 人數較多的房間，等級小於一定級別（ 伺服器下發）則不傳送進出房訊息； 級別較高的使用者進入房間時，會在 進房訊息攜帶資料以同步房間資訊；

2、房間活躍度計算

設有活躍度（禮物G、聊天M） 、 線上人數N、 直播時間T G為本次直播收到的Y幣數 M為本次直播發出的訊息數 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代理工具，篡改直播系統原始碼給伺服器的get引數。舉個例子，使用者點的是豪華禮物，透過HTTP代理工具把傳送給伺服器的請求的禮物ID改為普通禮物的ID。 解決方案： 1、改用HTTPS； 2、新增校驗碼； 解釋下方案2，把所有的get引數，key按照字串順序排序，value用"/"串起來，最後再加一串特定的字元，最終對這串值進行MD5，把MD5的串新增到code欄位。客戶端、伺服器都對核心邏輯收到的訊息，進行一次校驗。

總結

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

宣告：本文由雲豹科技轉發自落影部落格，如有侵權請聯絡作者刪除