LeanClound消息類型自定義
主要矛盾在于過去接收和發(fā)送的消息類型與現(xiàn)在接收和發(fā)送消息類型完全不一樣，次要矛盾在于過去的消息類型與現(xiàn)在的消息類型對應(yīng)的消息處理邏輯不一樣。
模型架構(gòu)蔫巩。假設(shè)扁平化處理，所有鍵值對都寫成字符串的形式灶平，勢必造成我在構(gòu)建消息往外發(fā)送的時候還需要先構(gòu)建字典，然后再傳入到消息的字典中去记舆，這是我不能忍受的奴潘，是否可以去扁平化逗余，模型本身就是一個整型鍵值對特咆、一個字符串鍵值對、一個字典鍵值對录粱，如此一來構(gòu)建模型至少需要上面的是三個鍵值對又變得特別麻煩了腻格。那如果把字典這種鍵值對也包裝成模型呢，這又變成了構(gòu)建兩個模型的問題了啥繁，MJEXtension將模型轉(zhuǎn)換成字典菜职。
處理邏輯。全局搜索枚舉（枚舉這種單詞還是寫長一點比較搜索起來比較方便）就能把消息類型對應(yīng)的所有處理邏輯搞定旗闽，無論什么消息類型都有一個共同點酬核，都是AVIMMessage消息類型蜜另，需要做的就是根據(jù)消息模型構(gòu)建消息，最好的就是傳入一個模型就發(fā)送消息出去嫡意，反正举瑰，我需要做的就根據(jù)一個模型構(gòu)建一個整體的ChatModel。顯示到聊天框的消息包括：普通禮物蔬螟、特效禮物嘶居、群聊、系統(tǒng)消息促煮、房間消息、第一次的點贊消息整袁、不展示在聊天框的消息包括：來了菠齿、離開、觀眾被動退出（也就是服務(wù)器關(guān)閉直播間消息）坐昙、第一次以外的點贊消息绳匀、紅包消息、彈幕消息炸客。需要主要的是消息顯示有兩種特殊疾棵，一種是禮物連擊和觀眾點贊寫在聊天框的最下面；二種是觀眾進(jìn)入房間顯示到右上角痹仙。至于其他的消息是尔，通通刷新TableView就??了。后臺發(fā)送的消息包括：普通禮物开仰、特效禮物拟枚、紅包消息、服務(wù)器關(guān)閉直播間消息众弓。每次點贊都會發(fā)消息恩溅，但是請求服務(wù)器點贊的接口只能執(zhí)行一次，因此服務(wù)器點贊的Type是7谓娃，需要顯示到聊天框脚乡，用戶第二次點贊的Type是5，不能顯示到聊天框滨达。
接收消息奶稠。接收消息十分簡單，Json字符串一步就變成了大模型弦悉！先確保消息能夠被完整接收窒典，然后才是發(fā)送消息，畢竟只要接收得好稽莉，就不用擔(dān)心因為消息類型不一致所帶來的崩潰呀瀑志。
發(fā)送消息。到底該如何去建立大模型呀，大模型包含小模型屬性的方法極為不科學(xué)劈猪，還是得用字典來做為屬性昧甘。
主播被動關(guān)閉直播間
正常關(guān)閉直播間邏輯。退出分兩步完成战得，嚴(yán)格區(qū)分SDK層和業(yè)務(wù)層充边。先執(zhí)行SDK層的退房邏輯，成功后請求服務(wù)器關(guān)閉業(yè)務(wù)層房間常侦，成功后接收到直播間關(guān)閉的消息浇冰，然后主播和觀眾在接收到這個消息之后都跳轉(zhuǎn)到結(jié)束直播的控制器，同時退出LeanCound聊天室斷開LeanClound連接聋亡。主播點擊退出肘习，關(guān)閉SDK視頻錄制、發(fā)送服務(wù)器請求坡倔、響應(yīng)LeanClound消息漂佩、退出業(yè)務(wù)層、跳轉(zhuǎn)控制器罪塔。
服務(wù)器關(guān)閉業(yè)務(wù)層房間失敗異常處理投蝉。問題在于如果主播請求服務(wù)器關(guān)閉直播時服務(wù)器無回應(yīng)，直接意味著直播關(guān)不了征堪，這很要命的瘩缆，無論服務(wù)器什么錯誤沒回應(yīng)，我都必須響應(yīng)主播的退出按鈕事件佃蚜，都必須跳轉(zhuǎn)控制器咳榜。所以處理就是自己構(gòu)造直播間關(guān)閉的消息群發(fā)，這也正好解決了因為心跳超時直播間斷開的問題爽锥。
關(guān)閉SDK房間視頻錄制失敗異常處理涌韩。心跳失敗必然是網(wǎng)絡(luò)出錯，網(wǎng)絡(luò)出錯意味著：1氯夷、SDK房間沒有視頻幀經(jīng)過臣樱，2、接收不到服務(wù)器發(fā)來的直播間關(guān)閉消息 3腮考、SDK會退出房間并銷毀實例4雇毫、關(guān)閉視頻錄制不會返回ID 5、視頻畫面卡著不動6踩蔚、點擊退出按鈕無法跳轉(zhuǎn)控制器7棚放、所有與網(wǎng)絡(luò)有關(guān)的操作都干不了
