本次項目更新，需要做IMSDK的版本更新，所以將IMSDK和移動直播SDK更新到了V1最高版本，見http://www.itdecent.cn/p/2a694736e588
本文章記錄一下SDK更新后遇到的一些問題，和解決方式：
1、修復(fù)首頁不顯示未讀消息數(shù)的問題
【問題排查】
排查發(fā)現(xiàn)，新SDK獲取消息數(shù)的API改為異步，之前是同步，會卡住主線程，使其及其卡頓，并且邏輯混亂無法正常獲取消息數(shù)
【解決方案】
通過dispatch_group，加notify的方式，開辟多個子線程，將過濾消息的for邏輯丟入到組中，最后通過notify的方式再回調(diào)到主線程實現(xiàn)。此方式不會卡住app，用戶正常使用，當(dāng)API處理完畢后，會回調(diào)到主線程，并在UI上展示消息數(shù)

2、停留在首頁，收到新消息時，消息數(shù)顯示不正確
【問題排查】
慢速收消息數(shù)量顯示正確，但是消息發(fā)快了，數(shù)量增加的就不正確了，例如快速發(fā)送6條消息，消息數(shù)只增加了5。
因為之前處理接受消息數(shù)是在主線程處理的，很容易造成線程沖突，容易導(dǎo)致計數(shù)錯誤。
【解決方案】
現(xiàn)在將增加計數(shù)的邏輯處理放到子線程，處理之后再回調(diào)到主線程中。
處理之后，增加了1.1s的延遲，因為SDK的回調(diào)會有一些延遲，立即執(zhí)行有時會過快，導(dǎo)致調(diào)用getUnReadMessageNum，拿不到實際的未讀消息數(shù)(SDK的問題)。

3、修復(fù)私信列表不顯示消息的問題
【問題排查】
初步斷定存在2個問題：
(1)由于之前獲取會話里面的消息是同步方法，新SDK改為異步方法，就無法同步執(zhí)行下面的代碼。
(2)之前獲取我們自己的followsid的接口和獲取用戶列表信息的接口，都是使用同步網(wǎng)絡(luò)請求，該操作結(jié)合SDK后都會卡住主線程，導(dǎo)致整個項目卡頓無法操作，也就無法獲取到私信列表
【解決方案】
原項目代碼構(gòu)成：2個for循環(huán)中，第一個for中每次循環(huán)嵌套一個同步的獲取消息方法，第二個for中每次循環(huán)嵌套一個同步獲取消息的方法，循環(huán)之前有一個獲取FollowIds的同步請求，2個for之間有一個獲取用戶信息列表的同步請求。
通過dispatch_group解決此問題

4、修復(fù)切到其他頁面再切回主頁會卡住不動的問題
【問題排查】
因為獲取未讀消息數(shù)，是寫在首頁viewDidAppear里面的，所以獲取消息數(shù)會卡住主線程，同問題1

5、直播間久置會導(dǎo)致嚴重卡頓，導(dǎo)致cpu負荷從20%漲到100%+
【問題排查】
程序控制臺一直打印《[+[CustomElemCmd parseCustom:] Line 47]自定義消息不是CustomElemCmd類型》這個警告，未更新IMSDK和移動直播SDK之前也有，不過很少，之前大概是1小時幾萬次，現(xiàn)在是1小時幾十萬次。
仔細排查后，占用CPU的罪魁禍?zhǔn)拙驮谶@
【解決方案】
由于新老SDK消息監(jiān)聽API變更，之前是無論添加幾個監(jiān)聽者，都只會收到1次回調(diào)，老代碼中，每次刷新都會添加1個監(jiān)聽者，這就導(dǎo)致每次收到新消息都會被復(fù)制幾十上百次，直接導(dǎo)致卡頓，現(xiàn)在將監(jiān)聽者寫在init中，那么全局就只有1個監(jiān)聽者，解決了此問題

- (int)addMessageListener:(id<TIMMessageListener>)listener;

6、放置在首頁，會收到奇奇怪怪的各種別的群的點贊送禮等消息，正常不應(yīng)該收到
【問題排查】
懷疑是進入直播間A，從A非正常退出后，再重啟app，就能一直收到A群組的消息，退出A群組失敗，或者未調(diào)用退出A群組的API
【解決方案】
在用戶收到消息API中，若用戶不是在直播間內(nèi)，并且收到的是群組消息，且群組不是用戶大群的情況下，先調(diào)用退出群API，之前也有這塊的邏輯，不過有些不完善，現(xiàn)在我這種處理雖然解決了此問題，但是更新SDK之前并沒有此問題，所以這個解決的不完美，需要繼續(xù)深入排查。

- (void)onNewMessage:(NSArray*)msgs;

7、直播間內(nèi)，用戶送連發(fā)禮物(例如：蘋果*999)就需要一個數(shù)字滾動動畫，這時候當(dāng)多個用戶同時送，并且都是較多連發(fā)數(shù)的時候，會導(dǎo)致卡頓。
【問題排查】
送禮物數(shù)字滾動動畫有問題，會卡住cpu，導(dǎo)致cpu負荷從40%漲到90%+，之前送禮物數(shù)字滾動動畫是每0.01秒，執(zhí)行一次數(shù)字+1，然后賦值給UILabel，如果送禮999，那么就會循環(huán)999次，多人送禮物的時候會導(dǎo)致占用cpu過大，之前沒更新SDK之前沒有問題，更新SDK后，會導(dǎo)致cpu占用近100%，就會卡住，具體原因未知，可能新IMSDK占用cpu增加了正好會導(dǎo)致。
【解決方案】
同問題8一起

8、當(dāng)用戶送連發(fā)禮物時，連發(fā)禮物數(shù)字滾動的同時，滑動公屏消息，禮物連發(fā)動畫就會停止
【問題排查】
Runloop沖突
【解決方案】
首先之前是使用的

NSTimeInterval t = 1.6 / part;
[self performSelector:@selector(showNumAdd) withObject:nil afterDelay:t];

多次循環(huán)導(dǎo)致卡頓，并且出現(xiàn)問題8。
使用PPCounter解決此問題。
PPCounter使用的是CADisplayLink定時器，并且

[_timer addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSDefaultRunLoopMode];
    [_timer addToRunLoop:[NSRunLoop mainRunLoop] forMode:UITrackingRunLoopMode];

將timer添加到滾動runloop中防止沖突導(dǎo)致卡頓
同時也優(yōu)化了999次循環(huán)的問題。

9、公屏消息面板滾動卡頓
【問題排查】
因為公屏來新消息的時候，需要將消息面板自動滾動到最新的消息，所以同時自動滾和手動滑就沖突了，看起來不流暢
【解決方案】

- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView{
    _canScrollToBottom = NO;
}
- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate
{
    CGFloat offsetY = scrollView.contentOffset.y;
    CGFloat realContentHeight = scrollView.contentSize.height - 150;
    NSLog(@"~~~~~~~~~~~~%.2f", offsetY);
    if (offsetY < (realContentHeight - 40)) {
        _canScrollToBottom = NO;
    } else {
        _canScrollToBottom = YES;
    }
    
    if (!_canScrollToBottom) {
        dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(kLiveMessageContentOffsetTime * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
            self->_canScrollToBottom = YES;
        });
    }
}

10、iphoneX 系統(tǒng)14，運行項目崩潰，報錯[TIMFriend copyWithZone:]: unrecognized selector sent to instance
【問題排查】
之前獲取Firends的API是返回的 strings， 新SDK返回的是TIMFriends，類別沖突導(dǎo)致崩潰，但是不知道為啥iphone7p不崩潰，奇怪
【解決方案】
將原來的 friend 改為 firend.identifier 去獲取id 即可，可能有其他API也存在這種問題，需要注意，后面詳細測試時在具體看

11、私信列表，在剛進入，或者刷新后的第一次，有個會話收到新消息沒有紅點顯示，若之前就有紅點，則紅點數(shù)不增加
【問題排查】
因為新IMSDK獲取未讀消息數(shù)的api，在立刻收到消息時就去調(diào)用，拿到的數(shù)據(jù)不準(zhǔn)，所以在收到新消息通知時，增加一個異步延遲1s，然后再去獲取未讀消息數(shù)。
【解決方案】
同問題2

12、退出登錄會崩潰
【問題排查】
發(fā)現(xiàn)退出登錄時會崩潰，加了僵尸，加了全局斷點，就是一直崩在main，控制臺也無任何輸出。
最后發(fā)現(xiàn)崩潰的代碼是

@implementation IMAConversationManager
- (void)dealloc{
//    [[TIMManager sharedInstance] removeMessageListener:self]; //這么寫會崩潰，不知道為什么
}

我也不清楚為什么，是因為self已經(jīng)是nil了嗎？那騰訊寫的東西也不應(yīng)該崩潰才對。
【解決方案】
改到外面持有IMAConversationManager的類中，調(diào)用：

[[TIMManager sharedInstance] removeMessageListener:_conversationMgr];
    _conversationMgr = nil;

解決了閃退問題。

持續(xù)更新中...