ios發(fā)現(xiàn)ANR或者crash排查的方法和需要哪些相關(guān)的信息，對于發(fā)現(xiàn)偶現(xiàn)的ANR和Crash應(yīng)該如何做到避免影響到線上用戶

ANR即（application not responding），即應(yīng)用無響應(yīng)。Crash 即程序崩潰。這兩種情況的發(fā)生會給用戶不友好的體驗。在應(yīng)用發(fā)布之前應(yīng)盡量避免。所以在開發(fā)的過程中如何對這兩種情況做到查漏補缺，主要有以下這些方案。

ANR：程序為何會出現(xiàn)“無響應(yīng)”的狀態(tài)。在iOS應(yīng)用中，所有的UI操作及更新都是在主線程完成，并且主線程的runloop是逐個處理用戶事件的（當然其他的runloop也一樣），所以主線程必須等待上一次事件處理完成后才能繼續(xù)響應(yīng)下一次事件。絕大部分用戶感知到的卡頓就是由于主線程阻塞了，在處理某次事件消耗了過長的時間，導(dǎo)致主線程處于等待狀態(tài)，無法及時響應(yīng)用戶的下一次輸入事件。由于iOS 上的 UIKit 只能在主線程進行處理，導(dǎo)致開發(fā)者在開發(fā)過程中不經(jīng)意間在主線程做了一些消耗時間的工作，導(dǎo)致了應(yīng)用卡頓。

避免卡頓的黃金法則就是不要讓主線程干重活，例如網(wǎng)絡(luò)請求，讀寫大文件，復(fù)雜的運算 等一些耗費大量系統(tǒng)資源及時間的任務(wù)。充分利用好 iOS 的多線程，如 NSThread、NSO peration Queue，GCD 等干臟活，累活，讓主線程能及時迅速的響應(yīng)用戶事件。

Crash是用戶使用應(yīng)用的過程中最糟糕的體驗，也是程序員最深惡痛絕的BUG。然而，每位程序員都免不了接觸crash事件。應(yīng)用Crash的產(chǎn)生主要有以下原因：

1.調(diào)用懸浮指針

2.數(shù)組越界訪問

3.調(diào)用了未實現(xiàn)的方法

4.調(diào)用的庫函數(shù)版本高于本機

5.返回空cell

6.類釋放時未remove通知，之后收到通知

7.類釋放時delegate未置空，之后被回調(diào)

8.使用nil做初始化操作，例如：

NSString*str =nil;



NSDictionary*dic =@{@"name":@"emma",@"age":str};

再如：

[NSString strWithFormat:nil];

9.NSRange訪問越界，例如：

NSString *str = @"abcedfh";

NSRange range = NSMakeRange(5, 9);

[str substringWithRange:range];

10.對象對應(yīng)關(guān)系異常。例如a實例removeObserver一個非a類關(guān)聯(lián)的監(jiān)聽對象。

11.delegate先于tableview被置空，后收到關(guān)于table或者scroll的調(diào)用.

12.系統(tǒng)內(nèi)存不足。

對于Crash的解決也都不同，一般必現(xiàn)的Crash可以通過對代碼仔細的閱讀輔以斷點調(diào)試幾乎都可以找出來。對于隱藏較深的Crash問題可以通過以下手段。

A ： 企業(yè)內(nèi)部測試階段：找到發(fā)包時的.ipa文件以及打包時archive生成的.dSYM文件以及應(yīng)用使用過程中產(chǎn)生的.crash文件。通過對這三個文件的解析。可以查看應(yīng)用程序具體的崩潰原因，以及崩潰什么地方。

B：應(yīng)用已經(jīng)安裝到用戶手機中，此時的crash可以通過一些第三方的工具進行獲取，常用的有Bugly、Testin、友盟等。但是需要在研發(fā)的過程中將這些第三方的SDK集成到自己的代碼中。

如果線上程序出現(xiàn)Crash的問題，首先要做的是定位BUG產(chǎn)生的原因。

1、如果是服務(wù)端返回的異常數(shù)據(jù)沒做兼容，就由服務(wù)端確保格式正確，客戶端看情況是否要做兼容；

2、如果是升級版本后的由于本地數(shù)據(jù)庫或本地存儲的數(shù)據(jù)格式未兼容等問題，一般需要撤下版本重新提交；

3、如果是業(yè)務(wù)代碼中只是簡單的數(shù)組越界之類，就很適合使用熱修復(fù)技術(shù)，比如JSPatch，但是前提是已經(jīng)發(fā)布的版本集成過熱修復(fù)模塊，否則也要重新發(fā)布版本。