全局創建context？

創建一個全局的context，然后退出SDK層房間時不銷毀只是停止context。

SDK層進房模型？

業務層房間model（波劵數、主播頭像路徑、主播userId、主播昵稱、在線人數、播放URL、發布URl、會話ID、房間ID、觀眾頭像數組）,SDK層房間model（用戶Model(九合ID、主播頭像路徑、主播昵稱、主播身份標識、主播的展示區域)、房間ID、會話ID）。

主播根據SDK層房間Model取出用戶Model、然后判斷用戶身份為主播并全局保存、設置主播特定按鈕、開啟AVSDK、配置房間參數模型(roomID和房間權限)進入SDK層房間、開啟攝像頭、開啟QAVVideoCtrl視頻幀委托、視頻正式渲染之前先預覽Or倒計時、觀眾顯示毛玻璃。

SDK層進房邏輯？

主播：判斷IM已經登錄（否則提示Token失效并返回首頁）、檢查麥克風權限、檢查攝像頭權限、檢查網絡、檢查模擬器、運行context、創建SDK進房模型進入SDK層房間、設置遠程本地視頻幀委托、開啟麥克風、開啟攝像頭、（依賴攝像頭打開）主播業務層進房邏輯

觀眾：判斷IM已經登錄（否則提示Token失效并返回首頁）、檢查網絡、檢查模擬器、運行context、設置遠程本地視頻幀委托、創建SDK進房模型進入SDK層房間、設置遠程本地視頻幀委托、開啟揚聲器、請求遠程主播畫面、觀眾業務層進房邏輯

業務層進房邏輯？

主播：視頻渲染、主播添加倒計時、顯示主播頭像和主播昵稱和觀眾頭像、注冊音頻和APP應用狀態的通知、添加電話監聽、添加網絡監聽、設置BottonBackView可見、開啟旁路直播、請求服務器創建業務層房間（開啟數據定時器、開啟心跳定時器、連接LeanClound）、

觀眾：視頻渲染、觀眾端添加毛玻璃、顯示主播頭像和主播昵稱和觀眾頭像、注冊音頻和APP應用狀態的通知、添加電話監聽、添加網絡監聽、設置viewerBottomBackView可見、請求服務器進入業務層房間（開啟數據定時器、連接LeanClound）

業務層退房邏輯？

主播：斷開LeanClound、銷毀數據定時器、清空禮物隊列、關閉旁路直播（依賴SDK層房間活著）、銷毀心跳定時器、判斷SDK層房間生命狀態決定是否進入SDK層退房邏輯。

觀眾：斷開LeanClound、銷毀數據定時器、清空禮物隊列、復位禮物界面、判斷SDK層房間生命狀態決定是否進入SDK層退房邏輯。

判斷SDK層房間生命狀態決定是否進入SDK層退房邏輯？

判斷SDK層房間活著：執行SDK層的退房邏輯、控制器跳轉邏輯

判斷SDK層房間死亡：控制器跳轉邏輯

SDK層退房邏輯？

主播：判斷攝像頭打開：關閉攝像頭、關閉麥克風揚聲器美顏后退出SDK層房間（停止運行context）。判斷攝像頭關閉：停止運行context。

觀眾：判斷SDK層房間生命狀態。判斷SDK層房間死亡：停止context。判斷SDK層房間活著：取消遠程視頻的繼續請求、關閉麥克風揚聲器后退出SDK房間、停止context。

控制器跳轉邏輯？

移除鍵盤通知應用程序前后臺通知移除音頻中斷通知、移除IM狀態監聽、移除電話狀態監聽、移除網絡狀態監聽、設置音頻為初始狀態、銷毀渲染層

主播：主播請求服務器關閉業務層房間（主播Push到直播結束控制器）

觀眾：觀眾請求服務器退出業務層房間（觀眾POP到首頁）（如果被動退出請求服務器歷史業務層房間信息（觀眾Push到直播結束控制器））

"直播間關閉"消息處理邏輯？

來源一：主播請求服務器關閉業務層房間。來源二：服務器超過30秒沒有監聽到心跳關閉業務層房間。對于主播來說，不想接收來源一的消息，很簡單，把斷開LeanCloud放在主播請求服務器關閉業務層直播間以前，這樣就什么都搞定了。

主播：因為是先斷開LeanClound后請求服務器，所以主播只會接收到來源二的消息。我想要的是，一旦是來源二的消息，就算主播和觀眾同時進入業務層退房邏輯，都是會先斷開LeanClound，這樣就算主播請求服務器關閉業務層房間發送了一個“直播間關閉消息”，觀眾端也已經斷開了LeanClound，根本就搜索不到好吧！所以，直接就進入業務層退房邏輯吧，無論是只有觀眾接收到“直播間關閉”的消息，還是主播和觀眾同時接收到“直播間關閉”的消息，根本都是一點問題都沒有好吧！因為我總是在業務層退房邏輯里面把斷開LeanClound放在首位。

觀眾：來源一和來源二都需要處理，直接進入業務層退房邏輯。

SDK層房間異常關閉邏輯？

判斷身份是主播：業務層退房邏輯。

判斷身份是觀眾：不需要對SDK層邏輯做操作，業務層的邏輯又會在接收到LeanClound類型6的消息后開始執行。

現在有一個巨大的問題就是SDK層房間被異常關閉后，主播和觀眾都會進入業務層退房邏輯，可是按照正常邏輯，關閉業務層房間、關閉SDK層房間，然后有進入業務層退房邏輯，這不是重復了么。得判斷是正常SDK房間退出還是被剔除SDK層房間，兩者最大的區別，就是正常退出SDK層房間會調用exitRoom這個方法。只要調用了exitRoom這個方法，自然就不是被剔除房間了。就不需要再退房的通知進入業務層退房邏輯了。默認就是被剔除SDK層房間，除非在調用exitRoom方法的時候將被剔出SDK層房間的屬性置為NO,自然就不會進入業務層的退房邏輯了。當然這個判斷必須寫在停止銷毀Context之后。當然每次啟動Context的時候都是默認被剔除SDK層房間的屬性為YES，本來想寫在創建Context的代碼里，但是覺得不妥，不一定每次進入SDK層房間都會創建Context，但是有一點可以肯定，無論上一次到底是正常退出SDK層房間還是被剔出SDK層房間，都會重新運行Context。

多次點擊發起直播多次Push直播控制器？

解決方案就是點擊發起直播按鈕，然后直播按鈕位不可點擊狀態，按理說不科學，不是那個HUD就已經可以實現這個功能了么，如果主播正在向秀波服務器請求SDK層房間的ID號，這個時候是一直有一個HUD圈圈在發起直播的控制器上旋轉，這個時候發起直播控制器的所有按鈕應該是不可點擊狀態才對呀，為什么可以連續多次點擊發起直播的按鈕呢，這嚴重不科學，按理說根本就不應該出現這樣的問題才對。

還有退出直播間不顯示？

觀眾業務層退房都會請求服務器退出業務層房間，只要觀眾主動退出就會請求服務器退出業務層房間，只要退出成功，業務層的其它成員就會接收到誰誰誰退出業務層房間，類型為8的消息。這個消息不用顯示出來，僅僅是為了更新觀眾頭像列表來用，只是我一直想測試一下如果我不開啟心跳，然后服務器發來“直播間關閉”的消息，到底哪個主播會不會進入SDK層退房邏輯，這個問題很關鍵呢，直接決定了如果業務層房間被秀波服務器異常關閉，主播能否接收到“直播間關閉”的消息，并作出進一步的處理。現在就用陳于的手機測試一下，到底業務層房間被異常關閉，主播進步進入業務層退房邏輯。還有現在居然有另外一個問題也附帶解決了，就是我不用擔心業務層房間還存在，但是SDK層房間已被關閉的問題了，畢竟，現在只要我推到后臺，永遠都是30秒就把業務層關閉了，然后觀眾就退出了，當然那個主播則會在回到前臺后第一時間處理“直播間關閉”的消息，簡直不要太溜呀。所以說什么嗎等90秒關閉SDK層房間真是看不見了。現在我需要屏蔽不顯示誰退出的消息了。經常出現這么一個情況，就是觀眾快進快出，這樣會帶來的問題表現是，觀眾頭像列表重復出現，換句話說，上一次退出的時候，沒有及時退出業務層的房間，然后進入的時候又請求了進入業務層房間，這樣的問題如此導致頭像重復出現，很明顯就是觀眾退出業務層房間不夠及時，活著退出業務層房間沒有及時發送LeanClound消息來刷新頭像。如此一來，重復加載頭像的問題就是沒有及時請求退出業務層房間的原因。

主播倒計時？

觀眾：添加渲染層、請求遠程視頻、添加了毛玻璃、第一幀視頻畫面出現、移除毛玻璃、開始視頻渲染

區分主播關閉攝像頭到底是臨時中斷直播還是正常結束直播？

當觀眾收到有人關閉攝像頭的通知時，觀眾在這個通知里執行的任務包括重新請求遠程視頻、創建“主播暫停直播”的本地消息顯示到聊天框。那么問題來了，當主播正常結束直播時也會先關閉攝像頭，觀眾也會創建“主播暫停直播”的本地消息，這不是我想看到的結果，說白了就是我想區分主播到底是臨時中斷直播還是正常結束直播。

視頻圖片幀渲染邏輯？

用戶退出SDK層房間之后務必需要注意一點，就是一定要停止渲染、渲染層父視圖移除、將渲染層置空。這個問題很重要，一旦渲染層沒有被正常移除和置空，直接造成控制器的內存釋放不了，意味著下一次進入房間控制器時，新的渲染層直接添加到了舊的渲染層上，重復添加渲染層，問題很嚴重。

房間成員頭像和波劵數量刷新的問題？

數據刷新的問題，自從我融入觀眾請求服務器進入房間和請求服務器退出房間都發送LeanClound的消息之后，現在的我就是1分鐘再刷新一次頭像列表，然后不用刷新房間人數，直接就以頭像的個數為準。而且主播的波劵數量也是1分鐘更新一次，相當于就是1分鐘校正一下數據，包括校正觀眾頭像和主播波劵。在沒有請求數據的時候，觀眾頭像列表和主播波劵全靠服務器發來的消息來刷新，來了和退出都會刷新頭像，禮物消息就刷新波劵數量。

心跳？

主播還有一個心跳定時器不僅要關閉，還要直接銷毀它。那么這里有一個疑問，就是我如果退出房間依然請求服務器心跳，會造成什么問題，因為單例嘛，從APP啟動到APP關閉都是只初始化一次，那么勢必我如果不在正確的時間里停止心跳監聽，APP會一直請求服務器心跳，那么這里面有一個問題，就是到底什么事時間才是結束心跳監聽的最佳時間呢，說實話，當我關閉SDK房間的那一刻，就真的沒有什么必要再去請求服務器監聽心跳了。所以最好的時間就是關閉攝像頭的時候，一談到攝像頭的開關和關閉，必須要考慮一個前提，就是主播關閉攝像頭不一定就是要退出房間，很有可能是退到后臺或鬧鐘電話中斷。除了在SDK攝像頭關閉的回調事件里知道了主播關閉攝像頭以外，其它是啥也不知道呀，如果要區分這個攝像頭關閉的事件到底是因為主播結束直播還是中斷直播，還需要一個附加條件，可是這個附加條件是什么呢？到底是什么附加條件呢？莫非是主播請求服務器結束直播發送過來的LeanClound消息。除了這個消息，還能更加準確地判斷關閉攝像頭的具體意義么？

數據請求單例類？

置空數據請求單例類的委托，這樣就算數據請求單例類請求到了數據，單例類對象想要通過委托屬性調用協議里的方法傳遞網絡請求到的數據也是徒勞的，當然這不是因為什么控制器沒有實現這個協議方法的原因，而是因為數據單例類的委托屬性都是空的呀，有木有！但是假如我們在銷毀控制器的時候，不置空數據單例類的委托屬性，那么好像也沒什么問題，因為本質上，當初是把控制器本身self賦值給數據單例類對象的委托屬性上，現在控制器self都已經銷毀了，就相當于將數據單例類對象的委托屬性銷毀了，還有還什么必要在控制器里置空數據單例類對象的委托屬性呢？當然，可能置空數據單例類對象的委托屬性的唯一價值在于可以在控制器銷毀之前結束數據請求單例類的數據回調。

LeanClound單例幫助類？

對于LeanClound通信來說，同一個用戶本來在A聊天室，如果在沒有退出A聊天室的情況下又進入B聊天室，必然會出現大問題。所以問題的關鍵是究竟在哪個地方來退出Leanclound通信。那需要分析我到底在什么時候不再需要LeanClound了，肯定的，對于主播來說，只要請求服務器退出直播間成功之后即可退出LeanClound。對于觀眾來說，自然就是在接收到服務器發來主播退出直播間消息6之后，直接就退出LeanClound了。

為什么必須在銷毀控制器時移除通知？

音視頻直播控制器需要移除的通知包括鍵盤通知、應用程序前后臺通知、音頻中斷的通知。通知本質上就是傳遞一個委托對象到通知中心去，這個被傳遞的委托對象通常就是控制器self本身。一旦控制器銷毀，相當于在其它地方觸發事件后想要通過這個通過通知傳遞過去的控制器self來調用控制器對象.m文件里面寫的方法，這樣必然造成崩潰呀，因為不僅調用的方法沒有被實現，更是這個控制器self都是空的狀態。這怎么能行，通知一定得注意刪除呀。控制器的通知必須得成雙成對的出現。

直播異常情況的處理？

網絡改變和網絡重連監聽、IM登錄狀態、電話監聽、音頻中斷、APP應用前后臺

音視頻房間邏輯的優化？

1、 AVChatRoom特點: 后臺會控制每秒收到的消息數在一定數量(比如5條/s)，這樣界面就不會頻繁有消息刷新

2、是否支持消息緩存，而不是立即顯示，主要是看大消息量時，立即顯示會導致界面卡頓， 因不清楚各App的消息種類，以及消息類型（是否支持IM等），故放到業務層去處理，各App可依照此處邏輯為0時，立即顯示 為1時，會按固定頻率刷新

3、AVSDK在直播場景下使用，不要頻繁切換context，可以在用戶注銷，或被踢下線的時候才stopContext

4、調試的時候手機距離較近容易產生嘯叫(物理現象：錄音機與揚聲器較近時)

APP旁路直播？

HLS推流（AV_ENCODE_HLS），判斷房間環境是否允許推流-----判斷是否允許重試-------正式開始推流———根據推流的各種參數構建推流請求模型-----通過[IMSdkInt sharedInstance]調用推流的請求———通過推流請求模型接收返回的對象

AVSDK的重試邏輯？

重復操作的邏輯———設定最大嘗試次數——常量整型變量保存當前的嘗試次數——判斷操作失敗—>累加變量——>對比當前嘗試次數和最大嘗試次數—>分線程延時1秒重新請求——>遞歸重新執行此方法

直播的異常處理？

用戶從正在聽QQ音樂和看視頻直播過程中進入直播間，或者說正在直播時出現了鬧鐘，

APP電話監聽？

用戶正在直播間，有人打來QQ電話，電話完畢需要重新進入直播APP，

Delloc方法不調用造成內存泄露？

delegate、Block、定時器

LeanClond私聊？

主播：建立與觀眾A的會話，通過會話發送私聊

視頻錄制？

錄制功能—————IMSDK單例對象——————調用開始視頻錄制的方法——————傳入兩個數據模型作為參數—————房間模型（房間的ID號和聊天室的ID號）———————錄制視頻需要做的一些模型(錄制視頻生成的視頻名稱、視頻的索引標簽、視頻分類的ID、SDK、是否轉碼、是否截圖、是否打水印)

APP定時器？

定時器寫在數據請求工具類，開啟直播間成功后開啟，控制器銷毀時關閉，無論正常退出還是意外退出，工具類如何獲取控制器關閉的事件，delloc方法中告訴工具類，請工具類關閉定時器

APP處理遠程通知？

接收到遠程通知，判斷用戶是否登錄，已經登錄則判斷APP應用的當前狀態，推送的字典aps鍵里面alertBody[aps object:@“alert”]，mesType決定推送消息點擊后的不同執行狀態，mainPage直接就是一個進入房間的字典。如果應用處于前臺正運行狀態，則將遠程消息的內容轉化成本地通知，唯一不科學的就是為什么這本地通知只是出現在通知欄，并不會向餓了么的那個紅包一樣先彈出來一下，這嚴重不科學呀！應用處于后臺和待激活狀態，則判斷推送的消息類型，1和2的類型進入用戶的個人中心，3和4的類型進入直播間。

微信公眾號提現？

發起微信提現，判斷微信的SnsOpenID和SnsUserID是否為空。如果為空，則調用微信登錄，在微信登錄成功的Block回調里面存儲微信的兩個ID到本地，接著調用提現的接口。如果登錄失敗，在Block回調里面提現登錄微信異常的錯誤到提現頁面，同時返回到上一個頁面。如果判斷到本地已經存在了微信的兩個ID號，那么直接發起提現請求，在請求成功后直接Block從單例幫助類回調到提現頁面。發送提現請求失敗有兩種情況：一種就是是未關注公眾號，另一種就是其他錯誤(典型ID失效)。尤其注意微信的兩個ID通常都是有時效性的，除了退出登錄的時候清空微信的兩個ID，還有一種更重要的方法就是要注意一個時間，就實現一個要求，在超出一個時間段之后自動清空這兩個ID。當然現在是通過提現的網絡請求傳入微信的連個ID才可以判斷是否失效的。當然，這里一般也不會失效，因為必須是微信登錄后，兩個ID才有值的。

APP不使用云通信IM而是用LeanClound？

刪除IMCore且初始化IM通信設置為不開啟聊天，更改IM頭文件為只是簡單實用登錄不使用聊天功能的那個頭文件，同時關閉IM云通信的錯誤日志打印，導入LeanCloundSDK 并在APPDelegate初始化開啟SDK，創建一個可用聊天室ID放進房間模型。用戶通過ID使用聊天功能用戶ID初始化laenClound 獲得leanClound對象，然后設置這個Client對象的委托，連接聊天服務器，根據聊天室房間號找到當前的群聊會話，根據返回的會話ID加入當前會話，接收新消息，消息轉模型，特殊消息特殊處理，刷新內容展示，鍵盤監聽，構建消息，設置消息類型（方便解析時不同顏色），發送消息。

APP登錄？

微信：微信登錄后Block返回的兩個ID請求登錄的接口

手機：手機號和密碼請求登錄的接口

登錄的網絡請求成功后返回九合ID和用戶ID和TLS簽名，本地保存TLS簽名、九合ID、用戶ID等其他一些列個人信息，然后dismiss登錄注冊頁面，發送通知進入個人中心的頁面，自然在進入個人中心的頁面就會調用viewWillAppear的方法，這個方法里面請求服務器刷新個人資料，這里特別坑的一點就是，個人中心的資料居然是來源于兩個接口，一個界面的數據來源于來個網絡請求，我一下子就想到了那個RAC的雙信號處理任務依賴呀，當然，用那個操作隊列來實現也是一個特別硬氣的方法。當然在登錄成功獲取到TLS票據之后，最最重要的一點就是登錄IM了。

APP登錄IM?

登錄秀波服務器后會返回一個TLS票據，登錄IM，登錄失敗，然后本地更具九合ID去請求一個新的TLS票據，自然就可以重新登錄了。1、用戶的賬號類型accountType 2、用戶名identifier 3、鑒權TokenuserSig 4、 App用戶使用OAuth授權體系分配的AppidappidAt3rd 5、用戶標識接入SDK的應用IDsdkAppId

APP支付？

支付寶：反饋支付結果到APP，APP請求APP服務器的支付狀態，返回支付失敗，再試一次，回饋結果，返回支付成功，就不在執行第二次，查詢APP服務器支付狀態，構建一個支付寶支付模型，模型的所有屬性的內容拼接成字符串，在給這個字符串拼接上特定格式簽名字符串，通過AlipaySDK實例化一個單例調用方法開始支付，支付結果通過字典反饋，判斷字典的支付狀態的值，判斷支付寶返回的支付結果為真

點擊發起直播？

點擊開始直播，默認分享微信,分享成功之后返回到應用的Block回調里面,跳轉控制器

更新頭像列表？

方案一：觀眾進入直播間，請求服務器就會獲取到當前房間的觀眾，然后定時器每15秒刷新一次數據

方案二:觀眾進入直播間時，請求服務器進入直播間，服務器群發leanClound消息,自帶頭像路徑和用戶ID,更新數據到頭像列表，然后請求數據變成1分鐘一次作為數據矯正。

函數式編程鏈式調用？

好想用一下函數式編程的思想，首先有一個工具類，一個采用鏈式編程思想的工具類，然后就是可以通過Block參數的輸入值將這個工具類的對象傳遞成被操作的對象，這樣就可以把很多操作寫在一個代碼塊里，這多幸福。現在就解決退出直播間這個問題，都需要執行哪些操作，然后通過BlockOperation添加一些列操作，這樣不經邏輯清楚，避免邏輯混亂，更可以為后面的RAC做準備呢！首先就是考慮觀眾退出吧，這個問題好憂傷，弄了這么多次，就沒有成功過，到現在還沒有信心，難道不是很憂傷么，現在 看到有了操作隊列簡直就像遇到救命稻草一般，可以完美的承載我的操作野心，讓我把所有的任務都封裝成一個操作隊列之中，這樣簡直就是完美了，好了，廢話不多說，直接打斷點分析邏輯和思路。找出觀眾退出房間所有應該執行的任務，然后將這些任務通通包裝成操作對象然后添加到隊列之中

APP前后臺切換？

前臺：打開相機，開啟渲染，立馬向服務器發一個心跳搶救回來，重新開啟定時器開啟心跳

后臺：關閉相機，停止渲染，停止定時器，廢棄心跳定時器并置空。iOS進入后臺或鎖屏造成的不活躍狀態，立馬終止了context，主播重新打開，攝像頭和一切麥克風都無法重新恢復，由于context已被銷毀，也無法通過context正常關閉功能和退出房間，對于主播必須先關閉攝像頭，可是現在已經關閉了攝像頭，唯一解決方法是主播進入后臺時不銷毀context，在即將進入后臺的時候繼續攝像頭的錄制和音頻連接，說白了前臺后臺一個樣，直到主播主動關閉攝像頭退出房間才銷毀context。現在問題進入后臺是自動就關閉了context。解決方法更換新的SDK，更新SDK到1.8.1之后推到后臺并未立刻終止context，只是暫停了context，但是一旦推到后臺就會結束服務器心跳的請求，服務器再30秒沒有接收到心跳將會強制關閉房間，使房間的所有成員變成無家可歸的人。而且程序退到后臺會應為渲染的問題造成程序崩潰，我想知道的是推倒后臺之后，攝像頭是否會依然會回調本地視頻幀，這個問題很重要，假如在程序推到后臺后依然回調視頻幀說明程序退到后臺依然正常工作，如果程序在后臺依然運行就會像打電話退到后臺那樣在全屏幕上方顯示一個紅色通知，因此對于渲染層來說，必須在程序進入后臺的時候停止渲染，否則出現視頻回調但是渲染層停止工作的問題，假如程序進入后臺后攝像頭立馬停止工作，應該只是中斷心跳的感覺，現在退到后臺AVSDK暫停。程序進入后臺后，攝像頭停止視頻回調，如果后臺的逗留時間超過80秒，這時候再重新回到前臺的時候，這個房間的所有成員都成為無家可歸的人了，主播如果這時候去執行關閉攝像頭的方法直接就是赤裸裸地找死啊，畢竟房間都已經死了呀。主播現在也不需要去退房了，直接告訴服務器退出房間吧，我覺得這個時候也不再需要去請求退出房間的接口吧，畢竟服務器再關閉異常的主播房間之后會群發一個直播間關閉的消息。然后銷毀context，只有這樣控制器才能delloc方法回收內存，渲染層的delloc回收內存，如果小于30秒則不會出現這樣的問題。

APP權限判斷？

第一次使用APP時系統會彈出Alert框讓用戶選擇是否允許授權，包括攝像頭和麥克風。以后用戶在進入直播間的時候每次都要先判斷權限，如果第一次拒絕了授權需要Alert提示用戶去隱私里面進行設置，同時pop銷毀控制器，只有攝像頭和麥克風都已經授權，才繼續下面的操作。

APP判斷IM登錄狀態？

判斷IM是否是登錄狀態

APP添加電話監聽？

繼承的意義？

繼承重寫父類的初始化方法，調用新增的方法或為新增的屬性賦值。重寫父類的方法，網絡改變和網絡重連監聽、IM登錄狀態、電話監聽、音頻中斷、APP應用前后臺

APP測試?

測試部設備有限，特邀大家一起來測試，各位親，不要錢，免費的喲，玩得不開心還可以提個現，一萬兩萬保證后臺不找你，測試評論時少些情緒，多些細節哈，做一個Nice的人！前方高能，測試重點突出：1、電話中斷 2、網絡切換 3、音頻中斷 4、前后臺切換 5、動畫與內存 6、旁路直播 7、流暢Vs清晰 8、提現+充值 9、三方分享造成的直播中斷 10、定時器的數據刷新 11、內存釋放 12、三方登錄 13、直播間生命周期 14、側彈動畫的隊列排序 15、聊天界面的消息沖突

不使用IM改用leanClound的細節？

用戶ID初始化laenClound 獲得leanClound對象——設置對象委托-----連接聊天服務器——根據聊天室號找到當前群聊會話-----加入當前會話----- 接收新消息——消息轉模型-----特殊消息特殊處理------刷新內容展示———鍵盤監聽——構建消息-----設置消息類型（方便解析時不同顏色）------發送消息

刪除IMCore-----關閉IM通信-------更改IM頭文件———報錯代碼全部關閉———引進LeanCloundSDK ———APPDelegate初始化———創建一個可用聊天室ID放進房間模型——— 用戶通過ID使用聊天功能

研發工程師，視頻娛樂，技術選型，體驗優化，問題解決，單源上傳，小于三秒，美顏濾鏡，采集，錄制，濾鏡，編碼，打包，傳輸，拆包，渲染，播放，CDN，帶寬，加速優化，延遲，開屏時間，卡頓率，秒開，畫面跳躍，聲音不連貫，延遲因素，GOP，組組圖片流，IPB幀，大小小，I幀之后的緩存，請求服務器先拿有I幀的緩存，通信協議，RTSP，TCPUDP混合復雜，部分CDN不支持，RTMP，僅TCP三次握手，簡單，CDN全支持，HLS，Http協議，跨平臺，HTTP—FLV，低延遲，需要播放器。buffer，避免頻繁抖動和卡頓。CDN全國各地分布基點。如何秒開，開屏等待時間，DNS解析，連接服務器，判斷服務器是否有緩存，等關鍵幀解碼，建立連接，等待關鍵幀，播放器渲染，DNS預解析，鏈路檢測，實時更改碼率，網絡優化，CDN加速，負載均衡，視頻轉碼，多種協議，封面截圖，直播錄制，分布式存儲集群，首屏秒開，低卡頓，低延時，多碼率，多格式，多終端，視頻傳輸架構，就近IP，DNS智能解析，IP調度，互聯互通，跨網絡訪問，丟包嚴重，克服物理距離傳輸，丟包重發，接流，錄制，實時截圖，圖片鑒黃，機器學習引擎，標清HLS，流暢FLV,視頻濾鏡，多清晰度，容錯處理，視頻質量大數據分析，系統瓶頸，CPU消耗，內存消耗，線程并發，機房快速遷移，看數據更高效運營