iOS crash分析實踐

正文

一、運行時錯誤

1、UICollectionView的調用順序

從堆棧可以看出是indexPath無效,通常是indexPath的section或者row超過了數據的大小;

根據堆棧信息和日志信息,可以找到用戶操作路徑,是通過scheme進入分類;
但是直接用真機復現,相同的操作并不會導致crash;
通過分析crash出現的機型和系統特征,發現都是iOS 13以下系統,而剛剛嘗試的是iOS 13的真機;
于是用iOS 12模擬器嘗試同樣的路徑,可以成功復現。
分析原因后,定位到是先調用scrollToItemAtIndexPath,再調用reloadData導致的異常。
解決方案也很簡單,調整為正確的順序即可。

尋找復現路徑的時候,要盡量從兩個方向去復現:
1、用戶設備條件,包括iOS系統版本、iphone機型、網絡環境等要保持一致;
2、App運行上下文,包括App版本、操作路徑、運行環境等;

2、HTML轉碼NSAttributedString耗時過長

業務需要把html格式的字符串轉成NSAttributedString,原來HTML轉碼成NSAttributedString使用的是系統自帶的方法:

- (nullable instancetype)initWithData:(NSData *)data options:(NSDictionary<NSAttributedStringDocumentReadingOptionKey, id> *)options documentAttributes:(NSDictionary<NSAttributedStringDocumentAttributeKey, id> * __nullable * __nullable)dict error:(NSError **)error;

舉一個實際的例子:

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.

    NSString *pathStr = [[NSBundle mainBundle] pathForResource:@"test" ofType:@"data"];
    NSString *htmlStr = [NSString stringWithContentsOfURL:[NSURL fileURLWithPath:pathStr] encoding:NSUTF8StringEncoding error:nil];

    NSLog(@"load string:%@", htmlStr);
    NSData *htmlData = [NSData dataWithBytes:htmlStr.UTF8String length:[htmlStr lengthOfBytesUsingEncoding:NSUTF8StringEncoding]];
    NSDictionary *dic = @{NSDocumentTypeDocumentAttribute:NSHTMLTextDocumentType,
                          NSCharacterEncodingDocumentAttribute:[NSNumber numberWithInt:NSUTF8StringEncoding]};
    NSDate *date = [NSDate date];
    NSAttributedString *attrStr = [[NSAttributedString alloc] initWithData:htmlData options:dic documentAttributes:nil error:nil];

    NSLog(@"transform time:%f", [[NSDate date] timeIntervalSinceDate:date]);
}

這個邏輯測試階段一切正常, 直到遇到一段HTML文本,其中帶有img標簽。
這段HTML文本在轉碼的時候會同步對圖片資源進行加載,導致線程阻塞,如果阻塞時間過長,還會引發crash。
堆棧如下:

此時,再回顧系統api的解釋,才有了更深刻的理解:

It will try to synchronize with the main thread, fail, and time out. Calling it from the main thread works (but can still time out if the HTML contains references to external resources, which should be avoided at all costs).

解決方案1、轉碼前,手動過濾掉<img>的標簽;
解決方案2、改用DTCoreText的html轉NSAttributedString;

使用一個不熟悉的系統API接口,最好花時間閱讀下接口說明;

二、多線程

1、dispatch_once引起死鎖

dispatch_once常被用于iOS單例實現方法,也會被用來處理某些只需要執行一次的場景,比如下文的獲取某些tag的方法:

+ (NSInteger)coolCommentTag { 
    static NSInteger ret = 5; // 實驗寫死默認值,客戶端不關心,透傳給后臺 
    static dispatch_once_t onceToken; 
    dispatch_once(&onceToken, ^{ 
        NSDictionary *abDict = [GET_SERVICE(SSTestManager) getExperimentValueForKey:@"social_comment_tag" withExposure:YES]; 
        if (SSIsValidatedDict(abDict)) { 
            ret = [abDict bda_integerValueForKey:@"comment_tag"]; 
        } 
    });      
    return ret; 
} 

這段代碼會造成一個crash:

堆棧關鍵信息:dispatch_gate_wait_slow;
注意到上圖,crash的是子線程,這時候要習慣性看看主線程在處理什么邏輯

從這兩個堆棧信息,我們基本可以確定是因為多線程死鎖導致的卡死。
場景分析:
1、主線程:did注冊 =》TTNet初始化 =》發起網絡請求 =》 獲取公共參數 =》 dispatch_once ;
2、子線程:RPC(網絡層)初始化 =》初始化 =》 獲取公共參數 =》 dispatch_once ;
然后發生死鎖

修復方式:去掉dispatch_once,改用線程安全的方式;

經驗總結:
網絡層相關接口有可能是子線程發起;
dispatch_once內的代碼要盡可能簡單;
子線程發生crash時,要習慣性看看主線程;

三、內存相關

1、dealloc訪問weak指針

weak指針經常被應用到在代理、block避免循環引用,避免有一個特性就是對象dealloc的時候,指向對象的weak指針會被置為nil。

但是使用不當的時候,weak指針也很容易造成crash,如下圖:

場景舉例:
1、書架某個按鈕,使用getter的方式獲取;getter方法中用block去響應按鈕點擊,block因為持有了外部self,所以會用weak-strong-dance;如果在dealloc方法訪問到該按鈕,則會發生crash;
2、詳情頁的某個view,使用getter的方式獲取,在dealloc方法時訪問了該getter;

getter實現

修復方式

經驗總結:
1、getter實現應該簡單化,盡量少的去設置很多屬性和創建block等,僅僅作為懶加載去創建對象;
2、dealloc方法不要訪問getter和setter的方法;

思考題,為什么對象dealloc創建對象的weak指針會crash?

2、子線程釋放對象

block是常見的回調方式,當我們調用某個異步方法,想在回調時繼續保持運行上下文,就會傳入一個回調block,等到就緒時再執行block。
比如說常見的rpc請求:

[SSBookApiService getBookToneInfo:^(SSBookToneInfoRequest *request) {
        request.bookId = bookId;
    } completion:^(BDRpcError *error, SSBookToneInfoResponse *response) {
        XXX.XXX
    }
}];

block保持上下文的方式,就是持有block中所有訪問到的外部對象。
這種持有特性可能會導致一些意想不到的情況,比如說在子線程銷毀一個對象

如圖,子線程的堆棧都是在dealloc方法,一層層遞歸。

通過代碼分析,可以知道是BDRpcAsyncOperation持有了某個block;該block持有了其他對象(因為block中訪問了該對象)。
結果BDRpcAsyncOperation在子線程銷毀時,dealloc方法層層遞進,最終觸發了某個對象在子線程銷毀,而該對象會在dealloc方法處理一些UI相關的邏輯。

修復方法:
1、block訪問到的外部對象,非局部變量盡可能使用weak-strong的方式來聲明;用weak指針來聲明外部的變量,如果該對象在block回調前被釋放,則會變為nil;
2、如果需要block持有該對象,則可以在dealloc的時候使用dispatch_async的方式,放到主線程去執行;(不能訪問self相關)

總結

1、尋找復現路徑的時候,要盡可能還原現場,才能更好復現;
2、使用一個不熟悉的系統API接口,最好花時間閱讀下接口說明;
3、子線程發生crash時,要習慣性看看主線程;

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,882評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,208評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,746評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,666評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,477評論 6 407
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,960評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,047評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,200評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,726評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,617評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,807評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,327評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,049評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,425評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,674評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,432評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,769評論 2 372

推薦閱讀更多精彩內容

  • 背景 分享一些過去兩個月遇到的crash。 正文 一、運行時錯誤 1、UICollectionView的調用順序 ...
    落影loyinglin閱讀 4,055評論 16 17
  • UIKit 1.UIView 和 CALayer 是什么關系? UIView 繼承 UIResponder,而 U...
    Sephiroth_Ma閱讀 2,230評論 0 25
  • 1.ios高性能編程 (1).內層 最小的內層平均值和峰值(2).耗電量 高效的算法和數據結構(3).初始化時...
    歐辰_OSR閱讀 29,473評論 8 265
  • 1、設計模式是什么? 你知道哪些設計模式,并簡要敘述? 設計模式是一種編碼經驗,就是用比較成熟的邏輯去處理某一種類...
    青春_追逐閱讀 772評論 0 7
  • *面試心聲:其實這些題本人都沒怎么背,但是在上海 兩周半 面了大約10家 收到差不多3個offer,總結起來就是把...
    Dove_iOS閱讀 27,186評論 30 471