最近bugly上每天都有幾個在非主線程更新UI的crash，從跟蹤數據看VC crash前基本集中出現在如下幾個VC中，但具體哪個方法bugly不知道沒法給出，首先通過對這幾個VC和關聯代碼仔細排查了邏輯發現沒啥明顯問題，后面在打包機上看到該版本Xcode有crash上報，而且信息更加具體明顯，問題隱藏的比較深，代碼路徑比較長，復現的情況比較難，解決費了點時間，在此記錄一下，這之后也提醒我需要對bugly 的crash上報做下更具體的優化才行，上報的信息都不及xcode上報的詳細具體。
問題原因
1、MainViewController是一個rootViewController，viewDidLoad中注冊監聽token是否失效，如果token失效登出清空用戶數據彈出present登錄界面，同時發出一個用戶需要退出的通知。
@implementation MainViewController
- (void)viewDidLoad {
[super viewDidLoad];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(userToeknInvalidateHandle) name:user_token_invalidate_notification object:nil];
}
- (void)userToeknInvalidateHandle{
//退出登錄并彈出登錄界面
[UserDataHandler setUserLoginModel:[[LoginModel alloc] init]];
[[NSNotificationCenter defaultCenter] postNotificationName:user_loginOrLogout_notification object:@{@"code":@"0"}];
[AppDelegate loadLoginVc];
}
2、在消息列表MessageViewController的viewDidLoad中注冊監聽用戶登錄登出的通知，接收到通知會更新相應的UI界面。
@implementation MessageViewController
- (void)viewDidLoad {
[super viewDidLoad];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(userLoginStatusChangeHandler:) name:user_loginOrlogout_notification_key object:nil];
}
- (void)userLoginStatusChangeHandler:(NSNotification *)notif {
if (notif.object && notif.object[@"code"] && [notif.object[@"code"] integerValue] > 0) {
//登錄 更新UI
[self loadRightItemWithImage:@"msg_clear" action:@selector(rightClick)];
} else {
//退出登錄 更新UI
[self loadRightItemWithImage:nil action:nil];
[self hideBadgeOnItemIndex:2];
}
}
3、獲取消息列表用戶基礎信息的EMConversationsViewController 在下拉刷新的時候因為需要處理數據量有點大， dispatch_async了一個子線程 異步處理，再dispatch_async(dispatch_get_main_queue(), ^{回到主線程刷新UI}，邏輯沒問題，問題在于 [weakself requestAvatarByCurPage];沒放在主線程執行，這時就造成一個子線程去請求網絡了，一般來說也沒啥問題，因為網絡請求的回調失敗OR成功結果肯定都做了放在主線程統一處理的。
@implementation EMConversationsViewController
- (void)viewDidLoad {
[super viewDidLoad];
self.tableViewDidTriggerHeaderRefresh = ^{
[weakSelf _loadAllConversationsFromDBWithIsShowHud:NO];
}
}
- (void)_loadAllConversationsFromDBWithIsShowHud:(BOOL)aIsShowHUD {
__weak typeof(self) weakself = self;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// 數據處理段
[weakself requestAvatarByCurPage]; // 錯誤源地：在此處寫了刷新聊天列表數據
//回歸主線程刷新UI
dispatch_async(dispatch_get_main_queue(), ^{
[weakself.tableView reloadData];
});
});
}
4、但中途如果有通知就另外說了。因為通知是不管你在哪個線程注冊的，只關心你在哪個線程post發出的，主線程發出的就在主線程處理，子線程發出的就在子線程處理。
//此時是一個子線程發起網絡請求
- (void)requestAvatarByCurPage {
[IMUtility.shareInstance getMessageListInfoWithUids:uids completeBlock:^(BOOL isSucc) {
if (isSucc) {
[self.tableView reloadData];
}
}];
}
}
5、網絡請求的路徑基本是：業務類請求->網絡基礎類邏輯判斷判斷（是否有token、該請求是否需要token）->AFnetWorking建立請求request和response；當用戶token失效，該請求必須帶token則回調回去的error還是在當前調用線程（沒到AFnetworking那一步），發出的通知也是子線程，這時候的上層失敗回調和通知接收者對UI的更新都是在子線程的，所以會造成crash。
- (void)getMessageListInfoWithUids:(NSString *)uids completeBlock:(UserMessageInfoBlock)completeBlock {
[WSAPPAPIHelper.shared.wsAPI getMessageListInfoWithUids:uids complete:^(id data) {
completeBlock(YES);
} error:^(NSError *error) {
completeBlock(NO);
}];
}
- (void)getMessageListInfoWithUids:(NSString *)uids complete:(CompleteBlock)complete error:(ErrorBlock)errorBlock {
NSMutableDictionary *parameters = [[NSMutableDictionary alloc] init];
[parameters setObject:uids?:@"" forKey:@"user_list"];
__weak WSBaseHttpAPI *SELF = self;
if ([self addCurrentUserToken:parameters isMustToken:YES error:errorBlock]) {
[SELF getRequest:UserList_URL parameters:parameters complete:complete error:errorBlock];
}
}
- (BOOL)addCurrentUserToken:(NSDictionary *)parameter isMustToken:(BOOL)isMustToken error:(ErrorBlock)error {
if (UserDataHandler.getUserInfo.token > 0) {
return YES;
} else {
if (isMustToken) {
[self didError:kErrorTokenCode strError:@"請先登錄" error:error];
[[NSNotificationCenter defaultCenter] postNotificationName:user_invalidate_token_notification_key object:nil];
}
}
return isMustToken == NO;
}
解決辦法
刷新請求放到主線程中，token失效放在主線程回調error，通知放在主線程post
