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

雲豹科技阿星發表於2021-07-29

架構

直播系統原始碼的業務邏輯不復雜,使用基本的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欄位。客戶端、伺服器都對核心邏輯收到的訊息,進行一次校驗。

總結

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

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


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69982461/viewspace-2784142/,如需轉載,請註明出處,否則將追究法律責任。

相關文章