全局創(chuàng)建context？

創(chuàng)建一個全局的context拨扶，然后退出SDK層房間時不銷毀只是停止context。

SDK層進(jìn)房模型茁肠？

業(yè)務(wù)層房間model（波劵數(shù)患民、主播頭像路徑、主播userId垦梆、主播昵稱匹颤、在線人數(shù)、播放URL托猩、發(fā)布URl印蓖、會話ID、房間ID京腥、觀眾頭像數(shù)組）,SDK層房間model（用戶Model(九合ID赦肃、主播頭像路徑、主播昵稱公浪、主播身份標(biāo)識他宛、主播的展示區(qū)域)、房間ID欠气、會話ID）厅各。

主播根據(jù)SDK層房間Model取出用戶Model、然后判斷用戶身份為主播并全局保存预柒、設(shè)置主播特定按鈕队塘、開啟AVSDK袁梗、配置房間參數(shù)模型(roomID和房間權(quán)限)進(jìn)入SDK層房間、開啟攝像頭憔古、開啟QAVVideoCtrl視頻幀委托遮怜、視頻正式渲染之前先預(yù)覽Or倒計時、觀眾顯示毛玻璃投放。

SDK層進(jìn)房邏輯奈泪？

主播：判斷IM已經(jīng)登錄（否則提示Token失效并返回首頁）、檢查麥克風(fēng)權(quán)限灸芳、檢查攝像頭權(quán)限涝桅、檢查網(wǎng)絡(luò)、檢查模擬器烙样、運行context冯遂、創(chuàng)建SDK進(jìn)房模型進(jìn)入SDK層房間、設(shè)置遠(yuǎn)程本地視頻幀委托谒获、開啟麥克風(fēng)蛤肌、開啟攝像頭、（依賴攝像頭打開）主播業(yè)務(wù)層進(jìn)房邏輯

觀眾：判斷IM已經(jīng)登錄（否則提示Token失效并返回首頁）批狱、檢查網(wǎng)絡(luò)裸准、檢查模擬器、運行context赔硫、設(shè)置遠(yuǎn)程本地視頻幀委托炒俱、創(chuàng)建SDK進(jìn)房模型進(jìn)入SDK層房間、設(shè)置遠(yuǎn)程本地視頻幀委托爪膊、開啟揚聲器权悟、請求遠(yuǎn)程主播畫面、觀眾業(yè)務(wù)層進(jìn)房邏輯

業(yè)務(wù)層進(jìn)房邏輯推盛？

主播：視頻渲染峦阁、主播添加倒計時、顯示主播頭像和主播昵稱和觀眾頭像耘成、注冊音頻和APP應(yīng)用狀態(tài)的通知榔昔、添加電話監(jiān)聽、添加網(wǎng)絡(luò)監(jiān)聽瘪菌、設(shè)置BottonBackView可見件豌、開啟旁路直播、請求服務(wù)器創(chuàng)建業(yè)務(wù)層房間（開啟數(shù)據(jù)定時器控嗜、開啟心跳定時器茧彤、連接LeanClound）、

觀眾：視頻渲染疆栏、觀眾端添加毛玻璃曾掂、顯示主播頭像和主播昵稱和觀眾頭像惫谤、注冊音頻和APP應(yīng)用狀態(tài)的通知、添加電話監(jiān)聽珠洗、添加網(wǎng)絡(luò)監(jiān)聽溜歪、設(shè)置viewerBottomBackView可見、請求服務(wù)器進(jìn)入業(yè)務(wù)層房間（開啟數(shù)據(jù)定時器许蓖、連接LeanClound）

業(yè)務(wù)層退房邏輯蝴猪？

主播：斷開LeanClound、銷毀數(shù)據(jù)定時器膊爪、清空禮物隊列自阱、關(guān)閉旁路直播（依賴SDK層房間活著）、銷毀心跳定時器米酬、判斷SDK層房間生命狀態(tài)決定是否進(jìn)入SDK層退房邏輯沛豌。

觀眾：斷開LeanClound、銷毀數(shù)據(jù)定時器赃额、清空禮物隊列加派、復(fù)位禮物界面、判斷SDK層房間生命狀態(tài)決定是否進(jìn)入SDK層退房邏輯跳芳。

判斷SDK層房間生命狀態(tài)決定是否進(jìn)入SDK層退房邏輯芍锦？

判斷SDK層房間活著：執(zhí)行SDK層的退房邏輯、控制器跳轉(zhuǎn)邏輯

判斷SDK層房間死亡：控制器跳轉(zhuǎn)邏輯

SDK層退房邏輯飞盆？

主播：判斷攝像頭打開：關(guān)閉攝像頭娄琉、關(guān)閉麥克風(fēng)揚聲器美顏后退出SDK層房間（停止運行context）。判斷攝像頭關(guān)閉：停止運行context桨啃。

觀眾：判斷SDK層房間生命狀態(tài)。判斷SDK層房間死亡：停止context檬输。判斷SDK層房間活著：取消遠(yuǎn)程視頻的繼續(xù)請求照瘾、關(guān)閉麥克風(fēng)揚聲器后退出SDK房間、停止context丧慈。

控制器跳轉(zhuǎn)邏輯析命？

移除鍵盤通知應(yīng)用程序前后臺通知移除音頻中斷通知、移除IM狀態(tài)監(jiān)聽逃默、移除電話狀態(tài)監(jiān)聽鹃愤、移除網(wǎng)絡(luò)狀態(tài)監(jiān)聽、設(shè)置音頻為初始狀態(tài)完域、銷毀渲染層

主播：主播請求服務(wù)器關(guān)閉業(yè)務(wù)層房間（主播Push到直播結(jié)束控制器）

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

"直播間關(guān)閉"消息處理邏輯软吐？

來源一：主播請求服務(wù)器關(guān)閉業(yè)務(wù)層房間。來源二：服務(wù)器超過30秒沒有監(jiān)聽到心跳關(guān)閉業(yè)務(wù)層房間吟税。對于主播來說凹耙，不想接收來源一的消息姿现，很簡單，把斷開LeanCloud放在主播請求服務(wù)器關(guān)閉業(yè)務(wù)層直播間以前肖抱，這樣就什么都搞定了备典。

主播：因為是先斷開LeanClound后請求服務(wù)器，所以主播只會接收到來源二的消息意述。我想要的是提佣，一旦是來源二的消息，就算主播和觀眾同時進(jìn)入業(yè)務(wù)層退房邏輯荤崇，都是會先斷開LeanClound拌屏，這樣就算主播請求服務(wù)器關(guān)閉業(yè)務(wù)層房間發(fā)送了一個“直播間關(guān)閉消息”，觀眾端也已經(jīng)斷開了LeanClound天试，根本就搜索不到好吧槐壳！所以，直接就進(jìn)入業(yè)務(wù)層退房邏輯吧喜每，無論是只有觀眾接收到“直播間關(guān)閉”的消息务唐，還是主播和觀眾同時接收到“直播間關(guān)閉”的消息，根本都是一點問題都沒有好吧带兜！因為我總是在業(yè)務(wù)層退房邏輯里面把斷開LeanClound放在首位枫笛。

觀眾：來源一和來源二都需要處理，直接進(jìn)入業(yè)務(wù)層退房邏輯刚照。

SDK層房間異常關(guān)閉邏輯刑巧？

判斷身份是主播：業(yè)務(wù)層退房邏輯。

判斷身份是觀眾：不需要對SDK層邏輯做操作无畔，業(yè)務(wù)層的邏輯又會在接收到LeanClound類型6的消息后開始執(zhí)行啊楚。

現(xiàn)在有一個巨大的問題就是SDK層房間被異常關(guān)閉后，主播和觀眾都會進(jìn)入業(yè)務(wù)層退房邏輯浑彰，可是按照正常邏輯恭理，關(guān)閉業(yè)務(wù)層房間、關(guān)閉SDK層房間郭变，然后有進(jìn)入業(yè)務(wù)層退房邏輯颜价，這不是重復(fù)了么。得判斷是正常SDK房間退出還是被剔除SDK層房間诉濒，兩者最大的區(qū)別周伦，就是正常退出SDK層房間會調(diào)用exitRoom這個方法。只要調(diào)用了exitRoom這個方法未荒，自然就不是被剔除房間了专挪。就不需要再退房的通知進(jìn)入業(yè)務(wù)層退房邏輯了。默認(rèn)就是被剔除SDK層房間，除非在調(diào)用exitRoom方法的時候?qū)⒈惶蕹鯯DK層房間的屬性置為NO,自然就不會進(jìn)入業(yè)務(wù)層的退房邏輯了狈蚤。當(dāng)然這個判斷必須寫在停止銷毀Context之后困肩。當(dāng)然每次啟動Context的時候都是默認(rèn)被剔除SDK層房間的屬性為YES，本來想寫在創(chuàng)建Context的代碼里脆侮，但是覺得不妥锌畸，不一定每次進(jìn)入SDK層房間都會創(chuàng)建Context，但是有一點可以肯定靖避，無論上一次到底是正常退出SDK層房間還是被剔出SDK層房間潭枣，都會重新運行Context。

多次點擊發(fā)起直播多次Push直播控制器幻捏？

解決方案就是點擊發(fā)起直播按鈕盆犁，然后直播按鈕位不可點擊狀態(tài)，按理說不科學(xué)篡九，不是那個HUD就已經(jīng)可以實現(xiàn)這個功能了么谐岁，如果主播正在向秀波服務(wù)器請求SDK層房間的ID號，這個時候是一直有一個HUD圈圈在發(fā)起直播的控制器上旋轉(zhuǎn)榛臼，這個時候發(fā)起直播控制器的所有按鈕應(yīng)該是不可點擊狀態(tài)才對呀伊佃，為什么可以連續(xù)多次點擊發(fā)起直播的按鈕呢，這嚴(yán)重不科學(xué)沛善，按理說根本就不應(yīng)該出現(xiàn)這樣的問題才對航揉。

還有退出直播間不顯示？

觀眾業(yè)務(wù)層退房都會請求服務(wù)器退出業(yè)務(wù)層房間金刁，只要觀眾主動退出就會請求服務(wù)器退出業(yè)務(wù)層房間帅涂，只要退出成功，業(yè)務(wù)層的其它成員就會接收到誰誰誰退出業(yè)務(wù)層房間尤蛮，類型為8的消息媳友。這個消息不用顯示出來，僅僅是為了更新觀眾頭像列表來用产捞，只是我一直想測試一下如果我不開啟心跳醇锚，然后服務(wù)器發(fā)來“直播間關(guān)閉”的消息，到底哪個主播會不會進(jìn)入SDK層退房邏輯轧葛，這個問題很關(guān)鍵呢搂抒，直接決定了如果業(yè)務(wù)層房間被秀波服務(wù)器異常關(guān)閉艇搀，主播能否接收到“直播間關(guān)閉”的消息尿扯，并作出進(jìn)一步的處理。現(xiàn)在就用陳于的手機(jī)測試一下焰雕，到底業(yè)務(wù)層房間被異常關(guān)閉衷笋，主播進(jìn)步進(jìn)入業(yè)務(wù)層退房邏輯。還有現(xiàn)在居然有另外一個問題也附帶解決了矩屁，就是我不用擔(dān)心業(yè)務(wù)層房間還存在辟宗，但是SDK層房間已被關(guān)閉的問題了爵赵，畢竟，現(xiàn)在只要我推到后臺泊脐，永遠(yuǎn)都是30秒就把業(yè)務(wù)層關(guān)閉了空幻，然后觀眾就退出了，當(dāng)然那個主播則會在回到前臺后第一時間處理“直播間關(guān)閉”的消息容客，簡直不要太溜呀秕铛。所以說什么嗎等90秒關(guān)閉SDK層房間真是看不見了。現(xiàn)在我需要屏蔽不顯示誰退出的消息了缩挑。經(jīng)常出現(xiàn)這么一個情況但两，就是觀眾快進(jìn)快出，這樣會帶來的問題表現(xiàn)是供置，觀眾頭像列表重復(fù)出現(xiàn)谨湘，換句話說，上一次退出的時候芥丧，沒有及時退出業(yè)務(wù)層的房間紧阔，然后進(jìn)入的時候又請求了進(jìn)入業(yè)務(wù)層房間，這樣的問題如此導(dǎo)致頭像重復(fù)出現(xiàn)娄柳，很明顯就是觀眾退出業(yè)務(wù)層房間不夠及時寓辱，活著退出業(yè)務(wù)層房間沒有及時發(fā)送LeanClound消息來刷新頭像。如此一來赤拒，重復(fù)加載頭像的問題就是沒有及時請求退出業(yè)務(wù)層房間的原因秫筏。

主播倒計時？

觀眾：添加渲染層挎挖、請求遠(yuǎn)程視頻这敬、添加了毛玻璃、第一幀視頻畫面出現(xiàn)蕉朵、移除毛玻璃崔涂、開始視頻渲染

區(qū)分主播關(guān)閉攝像頭到底是臨時中斷直播還是正常結(jié)束直播？

當(dāng)觀眾收到有人關(guān)閉攝像頭的通知時始衅，觀眾在這個通知里執(zhí)行的任務(wù)包括重新請求遠(yuǎn)程視頻冷蚂、創(chuàng)建“主播暫停直播”的本地消息顯示到聊天框。那么問題來了汛闸，當(dāng)主播正常結(jié)束直播時也會先關(guān)閉攝像頭蝙茶，觀眾也會創(chuàng)建“主播暫停直播”的本地消息，這不是我想看到的結(jié)果诸老，說白了就是我想?yún)^(qū)分主播到底是臨時中斷直播還是正常結(jié)束直播隆夯。

視頻圖片幀渲染邏輯？

用戶退出SDK層房間之后務(wù)必需要注意一點，就是一定要停止渲染蹄衷、渲染層父視圖移除忧额、將渲染層置空。這個問題很重要愧口，一旦渲染層沒有被正常移除和置空睦番，直接造成控制器的內(nèi)存釋放不了，意味著下一次進(jìn)入房間控制器時耍属，新的渲染層直接添加到了舊的渲染層上抡砂，重復(fù)添加渲染層，問題很嚴(yán)重恬涧。

房間成員頭像和波劵數(shù)量刷新的問題注益？

數(shù)據(jù)刷新的問題，自從我融入觀眾請求服務(wù)器進(jìn)入房間和請求服務(wù)器退出房間都發(fā)送LeanClound的消息之后溯捆，現(xiàn)在的我就是1分鐘再刷新一次頭像列表丑搔，然后不用刷新房間人數(shù)，直接就以頭像的個數(shù)為準(zhǔn)提揍。而且主播的波劵數(shù)量也是1分鐘更新一次啤月，相當(dāng)于就是1分鐘校正一下數(shù)據(jù)，包括校正觀眾頭像和主播波劵劳跃。在沒有請求數(shù)據(jù)的時候谎仲，觀眾頭像列表和主播波劵全靠服務(wù)器發(fā)來的消息來刷新，來了和退出都會刷新頭像刨仑，禮物消息就刷新波劵數(shù)量郑诺。

心跳？

主播還有一個心跳定時器不僅要關(guān)閉杉武，還要直接銷毀它辙诞。那么這里有一個疑問，就是我如果退出房間依然請求服務(wù)器心跳轻抱，會造成什么問題飞涂，因為單例嘛，從APP啟動到APP關(guān)閉都是只初始化一次祈搜，那么勢必我如果不在正確的時間里停止心跳監(jiān)聽较店，APP會一直請求服務(wù)器心跳，那么這里面有一個問題容燕，就是到底什么事時間才是結(jié)束心跳監(jiān)聽的最佳時間呢梁呈，說實話，當(dāng)我關(guān)閉SDK房間的那一刻缰趋，就真的沒有什么必要再去請求服務(wù)器監(jiān)聽心跳了捧杉。所以最好的時間就是關(guān)閉攝像頭的時候，一談到攝像頭的開關(guān)和關(guān)閉秘血，必須要考慮一個前提味抖，就是主播關(guān)閉攝像頭不一定就是要退出房間，很有可能是退到后臺或鬧鐘電話中斷灰粮。除了在SDK攝像頭關(guān)閉的回調(diào)事件里知道了主播關(guān)閉攝像頭以外仔涩，其它是啥也不知道呀，如果要區(qū)分這個攝像頭關(guān)閉的事件到底是因為主播結(jié)束直播還是中斷直播粘舟，還需要一個附加條件熔脂，可是這個附加條件是什么呢？到底是什么附加條件呢柑肴？莫非是主播請求服務(wù)器結(jié)束直播發(fā)送過來的LeanClound消息霞揉。除了這個消息，還能更加準(zhǔn)確地判斷關(guān)閉攝像頭的具體意義么晰骑？

數(shù)據(jù)請求單例類适秩？

置空數(shù)據(jù)請求單例類的委托，這樣就算數(shù)據(jù)請求單例類請求到了數(shù)據(jù)硕舆，單例類對象想要通過委托屬性調(diào)用協(xié)議里的方法傳遞網(wǎng)絡(luò)請求到的數(shù)據(jù)也是徒勞的秽荞，當(dāng)然這不是因為什么控制器沒有實現(xiàn)這個協(xié)議方法的原因，而是因為數(shù)據(jù)單例類的委托屬性都是空的呀抚官，有木有扬跋！但是假如我們在銷毀控制器的時候，不置空數(shù)據(jù)單例類的委托屬性凌节，那么好像也沒什么問題钦听，因為本質(zhì)上，當(dāng)初是把控制器本身self賦值給數(shù)據(jù)單例類對象的委托屬性上倍奢，現(xiàn)在控制器self都已經(jīng)銷毀了彪见，就相當(dāng)于將數(shù)據(jù)單例類對象的委托屬性銷毀了，還有還什么必要在控制器里置空數(shù)據(jù)單例類對象的委托屬性呢娱挨？當(dāng)然余指，可能置空數(shù)據(jù)單例類對象的委托屬性的唯一價值在于可以在控制器銷毀之前結(jié)束數(shù)據(jù)請求單例類的數(shù)據(jù)回調(diào)。

LeanClound單例幫助類跷坝？

對于LeanClound通信來說酵镜，同一個用戶本來在A聊天室，如果在沒有退出A聊天室的情況下又進(jìn)入B聊天室柴钻，必然會出現(xiàn)大問題淮韭。所以問題的關(guān)鍵是究竟在哪個地方來退出Leanclound通信。那需要分析我到底在什么時候不再需要LeanClound了贴届，肯定的靠粪，對于主播來說蜡吧，只要請求服務(wù)器退出直播間成功之后即可退出LeanClound。對于觀眾來說占键，自然就是在接收到服務(wù)器發(fā)來主播退出直播間消息6之后昔善，直接就退出LeanClound了。

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

音視頻直播控制器需要移除的通知包括鍵盤通知君仆、應(yīng)用程序前后臺通知、音頻中斷的通知牲距。通知本質(zhì)上就是傳遞一個委托對象到通知中心去返咱，這個被傳遞的委托對象通常就是控制器self本身。一旦控制器銷毀牍鞠，相當(dāng)于在其它地方觸發(fā)事件后想要通過這個通過通知傳遞過去的控制器self來調(diào)用控制器對象.m文件里面寫的方法咖摹，這樣必然造成崩潰呀，因為不僅調(diào)用的方法沒有被實現(xiàn)难述，更是這個控制器self都是空的狀態(tài)楞艾。這怎么能行裤唠，通知一定得注意刪除呀李破。控制器的通知必須得成雙成對的出現(xiàn)呵哨。

直播異常情況的處理择同？

網(wǎng)絡(luò)改變和網(wǎng)絡(luò)重連監(jiān)聽两入、IM登錄狀態(tài)、電話監(jiān)聽敲才、音頻中斷裹纳、APP應(yīng)用前后臺

音視頻房間邏輯的優(yōu)化？

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

2、是否支持消息緩存阻星，而不是立即顯示朋鞍，主要是看大消息量時，立即顯示會導(dǎo)致界面卡頓妥箕， 因不清楚各App的消息種類滥酥，以及消息類型（是否支持IM等），故放到業(yè)務(wù)層去處理畦幢，各App可依照此處邏輯為0時坎吻，立即顯示 為1時，會按固定頻率刷新

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

4诸尽、調(diào)試的時候手機(jī)距離較近容易產(chǎn)生嘯叫(物理現(xiàn)象：錄音機(jī)與揚聲器較近時)

APP旁路直播原杂？

HLS推流（AV_ENCODE_HLS），判斷房間環(huán)境是否允許推流-----判斷是否允許重試-------正式開始推流———根據(jù)推流的各種參數(shù)構(gòu)建推流請求模型-----通過[IMSdkInt sharedInstance]調(diào)用推流的請求———通過推流請求模型接收返回的對象

AVSDK的重試邏輯弦讽？

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

直播的異常處理？

用戶從正在聽QQ音樂和看視頻直播過程中進(jìn)入直播間膀哲，或者說正在直播時出現(xiàn)了鬧鐘往产，

APP電話監(jiān)聽？

用戶正在直播間某宪，有人打來QQ電話仿村，電話完畢需要重新進(jìn)入直播APP，

Delloc方法不調(diào)用造成內(nèi)存泄露兴喂？

delegate蔼囊、Block、定時器

LeanClond私聊衣迷？

主播：建立與觀眾A的會話畏鼓，通過會話發(fā)送私聊

視頻錄制？

錄制功能—————IMSDK單例對象——————調(diào)用開始視頻錄制的方法——————傳入兩個數(shù)據(jù)模型作為參數(shù)—————房間模型（房間的ID號和聊天室的ID號）———————錄制視頻需要做的一些模型(錄制視頻生成的視頻名稱壶谒、視頻的索引標(biāo)簽云矫、視頻分類的ID、SDK汗菜、是否轉(zhuǎn)碼让禀、是否截圖、是否打水印)

APP定時器陨界？

定時器寫在數(shù)據(jù)請求工具類巡揍，開啟直播間成功后開啟，控制器銷毀時關(guān)閉菌瘪，無論正常退出還是意外退出腮敌，工具類如何獲取控制器關(guān)閉的事件，delloc方法中告訴工具類俏扩，請工具類關(guān)閉定時器

APP處理遠(yuǎn)程通知缀皱？

接收到遠(yuǎn)程通知，判斷用戶是否登錄动猬，已經(jīng)登錄則判斷APP應(yīng)用的當(dāng)前狀態(tài)啤斗，推送的字典aps鍵里面alertBody[aps object:@“alert”]，mesType決定推送消息點擊后的不同執(zhí)行狀態(tài)赁咙，mainPage直接就是一個進(jìn)入房間的字典钮莲。如果應(yīng)用處于前臺正運行狀態(tài)免钻，則將遠(yuǎn)程消息的內(nèi)容轉(zhuǎn)化成本地通知，唯一不科學(xué)的就是為什么這本地通知只是出現(xiàn)在通知欄崔拥，并不會向餓了么的那個紅包一樣先彈出來一下极舔，這嚴(yán)重不科學(xué)呀！應(yīng)用處于后臺和待激活狀態(tài)链瓦，則判斷推送的消息類型拆魏，1和2的類型進(jìn)入用戶的個人中心，3和4的類型進(jìn)入直播間慈俯。

微信公眾號提現(xiàn)渤刃？

發(fā)起微信提現(xiàn)，判斷微信的SnsOpenID和SnsUserID是否為空贴膘。如果為空卖子，則調(diào)用微信登錄，在微信登錄成功的Block回調(diào)里面存儲微信的兩個ID到本地刑峡，接著調(diào)用提現(xiàn)的接口洋闽。如果登錄失敗，在Block回調(diào)里面提現(xiàn)登錄微信異常的錯誤到提現(xiàn)頁面突梦，同時返回到上一個頁面诫舅。如果判斷到本地已經(jīng)存在了微信的兩個ID號，那么直接發(fā)起提現(xiàn)請求宫患，在請求成功后直接Block從單例幫助類回調(diào)到提現(xiàn)頁面骚勘。發(fā)送提現(xiàn)請求失敗有兩種情況：一種就是是未關(guān)注公眾號，另一種就是其他錯誤(典型ID失效)撮奏。尤其注意微信的兩個ID通常都是有時效性的俏讹，除了退出登錄的時候清空微信的兩個ID，還有一種更重要的方法就是要注意一個時間畜吊，就實現(xiàn)一個要求泽疆，在超出一個時間段之后自動清空這兩個ID。當(dāng)然現(xiàn)在是通過提現(xiàn)的網(wǎng)絡(luò)請求傳入微信的連個ID才可以判斷是否失效的玲献。當(dāng)然殉疼，這里一般也不會失效，因為必須是微信登錄后捌年，兩個ID才有值的瓢娜。

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

刪除IMCore且初始化IM通信設(shè)置為不開啟聊天礼预，更改IM頭文件為只是簡單實用登錄不使用聊天功能的那個頭文件眠砾，同時關(guān)閉IM云通信的錯誤日志打印，導(dǎo)入LeanCloundSDK 并在APPDelegate初始化開啟SDK托酸，創(chuàng)建一個可用聊天室ID放進(jìn)房間模型褒颈。用戶通過ID使用聊天功能用戶ID初始化laenClound 獲得leanClound對象柒巫，然后設(shè)置這個Client對象的委托，連接聊天服務(wù)器谷丸，根據(jù)聊天室房間號找到當(dāng)前的群聊會話堡掏，根據(jù)返回的會話ID加入當(dāng)前會話，接收新消息刨疼，消息轉(zhuǎn)模型泉唁，特殊消息特殊處理，刷新內(nèi)容展示揩慕，鍵盤監(jiān)聽亭畜，構(gòu)建消息，設(shè)置消息類型（方便解析時不同顏色）漩绵，發(fā)送消息贱案。

APP登錄肛炮？

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

手機(jī)：手機(jī)號和密碼請求登錄的接口

登錄的網(wǎng)絡(luò)請求成功后返回九合ID和用戶ID和TLS簽名止吐，本地保存TLS簽名、九合ID侨糟、用戶ID等其他一些列個人信息碍扔，然后dismiss登錄注冊頁面，發(fā)送通知進(jìn)入個人中心的頁面秕重，自然在進(jìn)入個人中心的頁面就會調(diào)用viewWillAppear的方法不同，這個方法里面請求服務(wù)器刷新個人資料，這里特別坑的一點就是溶耘，個人中心的資料居然是來源于兩個接口二拐，一個界面的數(shù)據(jù)來源于來個網(wǎng)絡(luò)請求，我一下子就想到了那個RAC的雙信號處理任務(wù)依賴呀凳兵，當(dāng)然百新，用那個操作隊列來實現(xiàn)也是一個特別硬氣的方法。當(dāng)然在登錄成功獲取到TLS票據(jù)之后庐扫，最最重要的一點就是登錄IM了饭望。

APP登錄IM?

登錄秀波服務(wù)器后會返回一個TLS票據(jù)，登錄IM形庭，登錄失敗铅辞，然后本地更具九合ID去請求一個新的TLS票據(jù)，自然就可以重新登錄了萨醒。1斟珊、用戶的賬號類型accountType 2、用戶名identifier 3富纸、鑒權(quán)TokenuserSig 4倍宾、 App用戶使用OAuth授權(quán)體系分配的AppidappidAt3rd 5雏节、用戶標(biāo)識接入SDK的應(yīng)用IDsdkAppId

APP支付？

支付寶：反饋支付結(jié)果到APP高职，APP請求APP服務(wù)器的支付狀態(tài)钩乍，返回支付失敗，再試一次怔锌，回饋結(jié)果寥粹，返回支付成功，就不在執(zhí)行第二次埃元，查詢APP服務(wù)器支付狀態(tài)涝涤，構(gòu)建一個支付寶支付模型，模型的所有屬性的內(nèi)容拼接成字符串岛杀，在給這個字符串拼接上特定格式簽名字符串阔拳，通過AlipaySDK實例化一個單例調(diào)用方法開始支付，支付結(jié)果通過字典反饋类嗤，判斷字典的支付狀態(tài)的值糊肠，判斷支付寶返回的支付結(jié)果為真

點擊發(fā)起直播？

點擊開始直播遗锣，默認(rèn)分享微信,分享成功之后返回到應(yīng)用的Block回調(diào)里面,跳轉(zhuǎn)控制器

更新頭像列表货裹？

方案一：觀眾進(jìn)入直播間，請求服務(wù)器就會獲取到當(dāng)前房間的觀眾精偿，然后定時器每15秒刷新一次數(shù)據(jù)

方案二:觀眾進(jìn)入直播間時弧圆，請求服務(wù)器進(jìn)入直播間，服務(wù)器群發(fā)leanClound消息,自帶頭像路徑和用戶ID,更新數(shù)據(jù)到頭像列表笔咽，然后請求數(shù)據(jù)變成1分鐘一次作為數(shù)據(jù)矯正搔预。

函數(shù)式編程鏈?zhǔn)秸{(diào)用？

好想用一下函數(shù)式編程的思想叶组，首先有一個工具類拯田，一個采用鏈?zhǔn)骄幊趟枷氲墓ぞ哳悾缓缶褪强梢酝ㄟ^Block參數(shù)的輸入值將這個工具類的對象傳遞成被操作的對象扶叉，這樣就可以把很多操作寫在一個代碼塊里勿锅，這多幸福≡嫜酰現(xiàn)在就解決退出直播間這個問題溢十，都需要執(zhí)行哪些操作，然后通過BlockOperation添加一些列操作达吞，這樣不經(jīng)邏輯清楚张弛，避免邏輯混亂，更可以為后面的RAC做準(zhǔn)備呢！首先就是考慮觀眾退出吧吞鸭，這個問題好憂傷寺董，弄了這么多次，就沒有成功過刻剥，到現(xiàn)在還沒有信心遮咖，難道不是很憂傷么，現(xiàn)在 看到有了操作隊列簡直就像遇到救命稻草一般造虏，可以完美的承載我的操作野心御吞，讓我把所有的任務(wù)都封裝成一個操作隊列之中，這樣簡直就是完美了漓藕，好了陶珠，廢話不多說，直接打斷點分析邏輯和思路享钞。找出觀眾退出房間所有應(yīng)該執(zhí)行的任務(wù)揍诽，然后將這些任務(wù)通通包裝成操作對象然后添加到隊列之中

APP前后臺切換？

前臺：打開相機(jī)栗竖，開啟渲染暑脆，立馬向服務(wù)器發(fā)一個心跳搶救回來，重新開啟定時器開啟心跳

后臺：關(guān)閉相機(jī)划滋，停止渲染饵筑，停止定時器埃篓，廢棄心跳定時器并置空处坪。iOS進(jìn)入后臺或鎖屏造成的不活躍狀態(tài)，立馬終止了context架专，主播重新打開同窘，攝像頭和一切麥克風(fēng)都無法重新恢復(fù)，由于context已被銷毀部脚，也無法通過context正常關(guān)閉功能和退出房間想邦，對于主播必須先關(guān)閉攝像頭，可是現(xiàn)在已經(jīng)關(guān)閉了攝像頭委刘，唯一解決方法是主播進(jìn)入后臺時不銷毀context丧没，在即將進(jìn)入后臺的時候繼續(xù)攝像頭的錄制和音頻連接，說白了前臺后臺一個樣锡移，直到主播主動關(guān)閉攝像頭退出房間才銷毀context∨煌現(xiàn)在問題進(jìn)入后臺是自動就關(guān)閉了context。解決方法更換新的SDK淆珊，更新SDK到1.8.1之后推到后臺并未立刻終止context夺饲，只是暫停了context，但是一旦推到后臺就會結(jié)束服務(wù)器心跳的請求，服務(wù)器再30秒沒有接收到心跳將會強(qiáng)制關(guān)閉房間往声，使房間的所有成員變成無家可歸的人擂找。而且程序退到后臺會應(yīng)為渲染的問題造成程序崩潰，我想知道的是推倒后臺之后浩销，攝像頭是否會依然會回調(diào)本地視頻幀贯涎，這個問題很重要，假如在程序推到后臺后依然回調(diào)視頻幀說明程序退到后臺依然正常工作慢洋，如果程序在后臺依然運行就會像打電話退到后臺那樣在全屏幕上方顯示一個紅色通知柬采，因此對于渲染層來說，必須在程序進(jìn)入后臺的時候停止渲染且警，否則出現(xiàn)視頻回調(diào)但是渲染層停止工作的問題粉捻，假如程序進(jìn)入后臺后攝像頭立馬停止工作，應(yīng)該只是中斷心跳的感覺斑芜，現(xiàn)在退到后臺AVSDK暫停肩刃。程序進(jìn)入后臺后，攝像頭停止視頻回調(diào)杏头，如果后臺的逗留時間超過80秒盈包，這時候再重新回到前臺的時候，這個房間的所有成員都成為無家可歸的人了醇王，主播如果這時候去執(zhí)行關(guān)閉攝像頭的方法直接就是赤裸裸地找死啊呢燥，畢竟房間都已經(jīng)死了呀。主播現(xiàn)在也不需要去退房了寓娩，直接告訴服務(wù)器退出房間吧叛氨，我覺得這個時候也不再需要去請求退出房間的接口吧，畢竟服務(wù)器再關(guān)閉異常的主播房間之后會群發(fā)一個直播間關(guān)閉的消息棘伴。然后銷毀context寞埠，只有這樣控制器才能delloc方法回收內(nèi)存，渲染層的delloc回收內(nèi)存焊夸，如果小于30秒則不會出現(xiàn)這樣的問題仁连。

APP權(quán)限判斷？

第一次使用APP時系統(tǒng)會彈出Alert框讓用戶選擇是否允許授權(quán)阱穗，包括攝像頭和麥克風(fēng)饭冬。以后用戶在進(jìn)入直播間的時候每次都要先判斷權(quán)限，如果第一次拒絕了授權(quán)需要Alert提示用戶去隱私里面進(jìn)行設(shè)置揪阶，同時pop銷毀控制器昌抠，只有攝像頭和麥克風(fēng)都已經(jīng)授權(quán)，才繼續(xù)下面的操作遣钳。

APP判斷IM登錄狀態(tài)扰魂？

判斷IM是否是登錄狀態(tài)

APP添加電話監(jiān)聽麦乞？

繼承的意義？

繼承重寫父類的初始化方法劝评，調(diào)用新增的方法或為新增的屬性賦值姐直。重寫父類的方法，網(wǎng)絡(luò)改變和網(wǎng)絡(luò)重連監(jiān)聽蒋畜、IM登錄狀態(tài)声畏、電話監(jiān)聽、音頻中斷姻成、APP應(yīng)用前后臺

APP測試?

測試部設(shè)備有限插龄，特邀大家一起來測試，各位親科展，不要錢均牢，免費的喲，玩得不開心還可以提個現(xiàn)才睹，一萬兩萬保證后臺不找你徘跪，測試評論時少些情緒，多些細(xì)節(jié)哈琅攘，做一個Nice的人垮庐！前方高能，測試重點突出：1坞琴、電話中斷 2哨查、網(wǎng)絡(luò)切換 3、音頻中斷 4剧辐、前后臺切換 5寒亥、動畫與內(nèi)存 6、旁路直播 7浙于、流暢Vs清晰 8护盈、提現(xiàn)+充值 9挟纱、三方分享造成的直播中斷 10羞酗、定時器的數(shù)據(jù)刷新 11、內(nèi)存釋放 12紊服、三方登錄 13、直播間生命周期 14欺嗤、側(cè)彈動畫的隊列排序 15煎饼、聊天界面的消息沖突

不使用IM改用leanClound的細(xì)節(jié)讹挎？

用戶ID初始化laenClound 獲得leanClound對象——設(shè)置對象委托-----連接聊天服務(wù)器——根據(jù)聊天室號找到當(dāng)前群聊會話-----加入當(dāng)前會話----- 接收新消息——消息轉(zhuǎn)模型-----特殊消息特殊處理------刷新內(nèi)容展示———鍵盤監(jiān)聽——構(gòu)建消息-----設(shè)置消息類型（方便解析時不同顏色）------發(fā)送消息

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

研發(fā)工程師，視頻娛樂，技術(shù)選型马篮，體驗優(yōu)化怜奖，問題解決浑测，單源上傳，小于三秒歪玲，美顏濾鏡，采集滥崩，錄制钙皮，濾鏡，編碼崇摄，打包，傳輸逐抑，拆包厕氨，渲染汹粤，播放，CDN国葬，帶寬芹壕，加速優(yōu)化踢涌，延遲，開屏?xí)r間背苦，卡頓率，秒開疫剃，畫面跳躍硼讽，聲音不連貫，延遲因素壤躲，GOP备燃，組組圖片流，IPB幀漏麦，大小小撕贞，I幀之后的緩存测垛，請求服務(wù)器先拿有I幀的緩存，通信協(xié)議号涯，RTSP锯七，TCPUDP混合復(fù)雜眉尸，部分CDN不支持，RTMP地消，僅TCP三次握手畏妖，簡單戒劫，CDN全支持，HLS巫橄，Http協(xié)議茵典，跨平臺统阿，HTTP—FLV，低延遲帆离，需要播放器结澄。buffer，避免頻繁抖動和卡頓们妥。CDN全國各地分布基點王悍。如何秒開餐曼，開屏等待時間，DNS解析集惋，連接服務(wù)器刮刑，判斷服務(wù)器是否有緩存养渴，等關(guān)鍵幀解碼，建立連接翘紊，等待關(guān)鍵幀帆疟，播放器渲染，DNS預(yù)解析自赔，鏈路檢測柳琢，實時更改碼率柬脸，網(wǎng)絡(luò)優(yōu)化，CDN加速孤页，負(fù)載均衡涩馆，視頻轉(zhuǎn)碼魂那，多種協(xié)議，封面截圖鲜结，直播錄制活逆，分布式存儲集群蔗候，首屏秒開，低卡頓纫事，低延時所灸，多碼率爬立，多格式，多終端知纷，視頻傳輸架構(gòu)琅轧，就近IP踊挠，DNS智能解析效床，IP調(diào)度，互聯(lián)互通憋沿，跨網(wǎng)絡(luò)訪問沪猴，丟包嚴(yán)重运嗜，克服物理距離傳輸，丟包重發(fā)砸民，接流岭参，錄制尝艘，實時截圖利耍，圖片鑒黃，機(jī)器學(xué)習(xí)引擎程癌，標(biāo)清HLS轴猎，流暢FLV,視頻濾鏡捻脖，多清晰度中鼠，容錯處理援雇，視頻質(zhì)量大數(shù)據(jù)分析椎扬，系統(tǒng)瓶頸蚕涤，CPU消耗，內(nèi)存消耗茴丰，線程并發(fā)贿肩，機(jī)房快速遷移失仁，看數(shù)據(jù)更高效運營