有代碼的地方，就可能會有崩潰。定位崩潰問題的方法：最直接的，通過重現(xiàn)的步驟去調適；但是，有時候測試無法確定崩潰的步驟，或者崩潰是線上用戶發(fā)生的，這些情況下，我們仍然可以通過崩潰日志，知道崩潰的原因和崩潰的代碼行，從而修復問題。

—— 什么是崩潰？

Application crashes: An applicationtypically crashes when it performs an operation which is not allowed by the operatingsystem.

Server crashes, Operating systemcrashes, …

——定位崩潰原因的方法有哪些？

線索1：重現(xiàn)步驟

線索2：崩潰日志（知道崩潰的原因、崩潰的代碼行等信息）

那么，本文就來說說崩潰日志。

●●●?

獲取日志的幾種方法

在iOS系統(tǒng)中，當應用崩潰的時候，系統(tǒng)會生成一個崩潰日志，保存在設備上。

1.直接在手機上查看

在手機端設置里查看，如圖是iOS10的界面：

2.手機連PC用iTunes導出

iTunes同步資料庫，然后去PC對應目錄下，找文件

Mac OS X: ??~/Library/Logs/CrashReporter/MobileDevice/

Windows XP: ? C://Documents andSettings/Application Data/Apple Computer/Logs/Crash/Reporter/MobileDevice

Windows Vista or 7: ? ?C://Users/AppData/Roaming/AppleComputer/Logs/Crash/Reporter/MobileDevice

3.手機連XCode導出

Simulator-Hardware-Device-ManageDevices

4.XCode中，對提交商店的應用，查看Crashes

xcode->Window->Organizer->Crashes

5.用iTunes Connect（提交商店的應用）

如果應用提交到App Store了，還可以從iTunes Connect（https://itunesconnect.apple.com/）上獲取到用戶的崩潰日志.。通過應用提交者的apple id登錄，管理提交的應用，應用細節(jié)中有一個崩潰報告

5.app植入第三方sdk，配合第三方平臺查看

很多第三方平臺，（比如蒲公英、fabric、網易云捕...）提供sdk和管理后臺。

只需要使用它們的sdk，并添加幾行代碼，app運行時，sdk會將應用Crash數據自動上傳到后臺，后臺會進行相應的統(tǒng)計和分析。并給出產品各個版本的崩潰數，崩潰率，影響用戶數，崩潰的機型、系統(tǒng)等。

6.使用蘋果的api，自己實現(xiàn)抓取崩潰信息，提交到自己寫的后臺

和5是一樣的，有這些現(xiàn)成的情況下，不是很必要自己重新再寫一個，但是可以簡單了解一下其中的關鍵原理。

1.iOS SDK中提供了一個現(xiàn)成的函數NSSetUncaughtExceptionHandler用來做異常處理。

voidHandleException(NSException*exception) ? //捕捉到異常時執(zhí)行的方法

{

? ? ? ? //異常的堆棧信息

? ? ? ? NSArray*stackArray = [exceptioncallStackSymbols];

? ? ? ? //出現(xiàn)異常的原因

? ? ? ? NSString*reason = [exception reason];

? ? ? ? //異常名稱

? ? ? ? NSString*name = [exception name];

? ? ? ? NSString*exceptionInfo =[NSStringstringWithFormat:@"Exception reason：%@\nException name：%@\nExceptionstack：%@",name, reason, stackArray];

? ? ? ? NSLog(@"%@",exceptionInfo);

? ? ? ? [UncaughtExceptionHandlersaveCrash:exceptionInfo]; //自己實現(xiàn)一個記錄下這些信息的方法，作者是實現(xiàn)了一個寫文本文件的方法

}

voidInstallUncaughtExceptionHandler(void)?? //注冊一些抓取函數，在APPDelegate中didFinishLaunchingWithOptions調用

{

? ? ? ? NSSetUncaughtExceptionHandler(&HandleException);

}

2.但NSSetUncaughtExceptionHandler功能非常有限，而引起崩潰的原因如：內存訪問錯誤，重復釋放等錯誤并不能被抓到，而這種錯誤它拋出的是Signal，因此做一個Signal處理可以抓到這一類的崩潰。

voidSignalExceptionHandler(intsignal) //抓取到Signal異常時，執(zhí)行的方法

{

? ? ? ? ?NSMutableString*mstr =[[NSMutableString alloc] init];

? ? ? ? ?[mstrappendString:@"Stack:\n"];

? ? ? ? ?void* callstack[128];

? ? ? ? ?inti, frames =backtrace(callstack,128);

? ? ? ? ?char**strs =backtrace_symbols(callstack, frames);

? ? ? ? ?for(i=0; i<frames;++i）{

? ? ? ? ?? ? ? ? [mstr appendFormat:@"%s\n", strs[i]];

? ? ? ? ? }

? ? ? ? ? [SignalHandlersaveCrash:mstr]; //同上，自己實現(xiàn)一個記錄下這些信息的方法，作者是實現(xiàn)了一個寫文本文件的方法

}

void InstallSignalHandler(void) //注冊抓取函數和抓取的Signal類型，在APPDelegate中didFinishLaunchingWithOptions調用

{

? ? ? ? ? signal(SIGHUP,SignalExceptionHandler);

? ? ? ? ? signal(SIGINT,SignalExceptionHandler);

? ? ? ? ? signal(SIGQUIT,SignalExceptionHandler);

? ? ? ? ? signal(SIGABRT,SignalExceptionHandler);

? ? ? ? ? signal(SIGILL,SignalExceptionHandler);

? ? ? ? ? signal(SIGSEGV,SignalExceptionHandler);

? ? ? ? ? signal(SIGFPE,SignalExceptionHandler);

? ? ? ? ? signal(SIGBUS,SignalExceptionHandler);

? ? ? ? ? signal(SIGPIPE,SignalExceptionHandler);

}

3.寫完上面兩個類，在APPDelegate中didFinishLaunchingWithOptions調用

-(BOOL)application:(UIApplication*)applicationdidFinishLaunchingWithOptions:(NSDictionary*)launchOptions {

? ? ? ? ?InstallSignalHandler();

? ? ? ? ?InstallUncaughtExceptionHandler();

? ? ? ? ?returnYES;

}

4.可以寫一個demo，按鈕函數包含一些崩潰的代碼，然后就會發(fā)現(xiàn)抓取的崩潰的函數，被執(zhí)行了，崩潰信息成功輸出到了指定的文本文件中。

-(IBAction)buttonClick:(UIButton*)sender { ? ?//1.信號量

? ? ? ? ?intlist[2]={1,2};

? ? ? ? ?int*p= list;

? ? ? ? ?free(p);??

? ? ? ? ?p[1]=5;

}

-(IBAction)buttonOCException:(UIButton*)sender{ ? ? ? ?//2.ios崩潰

? ? ? ? ? NSArray*array=@[@"tom",@"xxx",@"ooo"];

? ? ? ? ? [arrayobjectAtIndex:5];

}

5.得到了關鍵的堆棧信息，和崩潰原因

到這里，已經知道了，怎么獲得到這些信息。下面繼續(xù)講一下，怎么根據這些信息，定位到是哪里崩潰的，以及其中可能遇到的一些問題。

●●●?

如何讀懂、解析日志

1.崩潰日志提供的信息

從手機直接撈出來的日志，很有可能長這樣，一推十六進制的，看不出有效信息。那么問題來了，怎么樣轉換為看得懂的信息呢？

2.認識符號文件

符號文件是保存 16 進制函數地址映射信息的中轉文件，符號集中存儲著文件名、方法名、行號的信息.

符號文件和崩潰日志，具有一一對應的關系。

如何確定符合文件A和崩潰日志B是一一對應的？

在崩潰日志中會記錄一個UUID；用一些工具（比如dwarfdump），可以查詢符號文件的UUID；如果是一致的，那就說明這兩個文件的一對對應的符號文件和崩潰日志，可以用這個符號文件解析這個崩潰日志。

然后，用dwarfdump、atos等工具，可以將崩潰日志，通過對應的符號文件，將十六進制數通過查符號表，轉化為工程中的方法名，代碼行號。

比如：

崩潰日志中有一段：

然后，用dwarfdump命令

命令：dwarfdump --uuidYour.app.dSYM

對比兩個uuid一致，就對上了。

最后，用symbolicatecrash工具，解析崩潰日志

命令：

cd /Users/yourMac/Desktop/崩潰文件夾

symbolicatecrash ./*.crash ./*.app.dSYM> symbol.crash

就得到了崩潰日志。

3.解析的原理

（1）-原始的崩潰文件：

原始的崩潰文件其中一行，拿出來講解

3 UncaughtExceptionDemo0x00dabe0 0x00d300e + 31698

序號?進程名 ? ? ? ? ? ?? ? ?崩潰時的堆棧地址 ? ?運行時起始地址 + 偏移量

應用崩潰發(fā)生時的堆棧地址為0x00dabe0，該進程的運行時起始地址是0x00d300e，崩潰處距離進程起始地址的偏移量為十進制的31698(對應十六進制為0x0007bd2)。

三者對應關系：0x00dabe0 =0x00d300e+ 0x0007bd2

(崩潰時的堆棧地址= 運行時起始地址 + 偏移量)

接著，去符號表中查詢

（2）-獲取符號表起始地址

命令：$otool -lYour.app.dSYM/Contents/Resources/DWARF/Your

結果

其中vmaddr= 0x00004000 就是符號表中的起始地址。

符號表崩潰地址 = 符號表起始地址 + 偏移量

= 0x4000 +?0x7bd2

=?0xbbd2

得到符號表中的崩潰地址

（3）-提取.debug_info

命令：$ dwarfdump -e--debug-info YourPath/YourApp.dSYM/Contents/Resources/DWARF > info-e.txt

會生成一個txt，里面包含很多個如下的內容，文件內容舉例：

可以知道ViewController::buttonOCException方法的地址范圍：0x0000bb76-0x0000bc00。

（4）提取.debug_line

命令：$ dwarfdump -e--debug-line YourPath/YourApp.dSYM/Contents/Resources/DWARF > line-e.txt

會生成一個txt，里面包含很多個如下的內容，文件內容舉例：

這里代表的意思是，每一行代碼，對應的地址、偏移量。

（5）-結論，得到關鍵信息：

解析后的崩潰日志為

3UncaughtExceptionDemo-[ViewControllerbuttonOCException:] (ViewController.m:36)

崩潰所在源碼文件：/Users/huangchong/iOSCrashUncaught-master/UncaughtExceptionDemo/ViewController.m

發(fā)生崩潰的方法：-[ViewController :buttonOCException]

發(fā)生崩潰的方法在源文件中的行號：32

崩潰發(fā)生的代碼行，在源文件中得行號：36

——推薦閱讀——

全面復盤！深度剖析直播答題產品架構的難點與坑>>

如何快速設計短信驗證碼>>

如何做好Android 端音視頻測試>>

總結

以上是生活随笔為你收集整理的【iOS篇】从容面对App崩溃的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。