導(dǎo)致Crash的原因

• 這個(gè)一般在開發(fā)階段就可以檢測(cè)出來(lái), 所以導(dǎo)致crash幾率較低
• 應(yīng)用違反了操作系統(tǒng)原則, 如當(dāng)App在切換AppDelegate的各種狀態(tài)時(shí)響應(yīng)超時(shí), 有可能被系統(tǒng)終止應(yīng)用(喚醒超時(shí))
• 應(yīng)用中一些bug: 如空數(shù)組, 調(diào)用未識(shí)別的方法, 阻塞主線程時(shí)間過長(zhǎng)等等

獲取Crash日志

• 當(dāng)iOS應(yīng)用程序崩潰的時(shí)候, 系統(tǒng)會(huì)自動(dòng)創(chuàng)建一份crash日志保存在設(shè)備上, crash日志記錄了App崩潰時(shí)的信息
• 在調(diào)試的時(shí)候, 可以通過Xcode -> Window -> Device來(lái)導(dǎo)出你的崩潰日志
• 對(duì)于已經(jīng)發(fā)布的App, 一般都是通過一些第三方推送來(lái)獲取Crash日志, 如友盟
  • 需要在后臺(tái)監(jiān)控上面查看, 然后使用錯(cuò)誤分析工具來(lái)查看錯(cuò)誤
• 也可以在iTunes Connect上面, 找到你已經(jīng)發(fā)布的程序, 獲取崩潰日志

Crash日志的簡(jiǎn)單介紹

     Incident Identifier: 7B5C3D72-9A8B-4D57-BF03-3A518FF215DF
     CrashReporter Key:   84b7b4f09b56ab3172449e05efa31985611bbd73
     Hardware Model:      iPhone7,1
     Process:             QQ [29482]
     Path:                /private/var/mobile/Containers/Bundle/Application/2E7374FD-B9A6-4915-B149-2707F3439152/QQ.app/QQ
     Identifier:          com.tencent.mqq
     Version:             6.2.3.409 (6.2.3)
     Code Type:           ARM-64 (Native)
     Parent Process:      launchd [1]
     
     Date/Time:           2016-06-15 17:27:43.830 +0800
     Launch Time:         2016-06-15 17:27:30.873 +0800
     OS Version:          iOS 8.3 (12F70)
     Report Version:      105
     
     Exception Type:  EXC_RESOURCE
     Exception Subtype: WAKEUPS
     Exception Message: (Limit 150/sec) Observed 3531/sec over 300 secs
     Triggered by Thread:  6
     
     Thread 0 name:  Dispatch queue: com.apple.main-thread
     Thread 0:
     0   libsystem_kernel.dylib          0x0000000196318e0c mach_msg_trap + 8
     1   libsystem_kernel.dylib          0x0000000196318c84 mach_msg + 68
     2   CoreFoundation                  0x0000000184327720 __CFRunLoopServiceMachPort + 196
     3   CoreFoundation                  0x0000000184325674 __CFRunLoopRun + 936
     4   CoreFoundation                  0x00000001842512d0 CFRunLoopRunSpecific + 392
     5   GraphicsServices                0x000000018da676f8 GSEventRunModal + 164
     6   UIKit                           0x0000000188e16fa8 UIApplicationMain + 1484
     7   QQ                              0x000000010090f600 0x1000dc000 + 8599040
     8   libdyld.dylib                   0x000000019621aa04 start + 0

• 這是剛剛找到的QQ的crash日志, 從上面看來(lái)基本上可以分成四部分
  1. 崩潰的程序, 以及一些主機(jī)信息
  2. 崩潰的事件, 當(dāng)前系統(tǒng)的版本
  3. 崩潰的異常類型, 信息以及出問題的線程
  4. 崩潰前, 各個(gè)線程的詳細(xì)信息
• 首先來(lái)解釋一下上述崩潰的問題
  • 我們可以看到在第三部分, 有各種Exception異常信息以及出情況的線程, 通常這就是導(dǎo)致崩潰的問題所在
  • 但是只有異常類型, 以及一些模糊的信息, 我們并不能準(zhǔn)確的斷定到底異常發(fā)生在哪, 所以一般就需要你去StackOverFlow中查看
  • 關(guān)于這個(gè)問題: 你可以看到Exception Message: (Limit 150/sec) Observed 3531/sec over 300 secs是由于這個(gè)錯(cuò)誤引起的, 由于這個(gè)是由QQ引起的崩潰, 我只能在StackOverFlow上面查看, 得到的結(jié)果是: 這個(gè)問題是由于在喚醒App線程中調(diào)用的方法次數(shù)過多導(dǎo)致的崩潰, 在iOS喚醒App的時(shí)候, 會(huì)有嚴(yán)格的控制方法調(diào)用的次數(shù), 如果超過這個(gè)次數(shù), 就會(huì)引發(fā)crash
• 一般解決crash的方法
  • 在線程中, 你可以看到線程正在調(diào)用的方法, 但是他們都統(tǒng)一被轉(zhuǎn)化為十六進(jìn)制和地址, 這被稱為符號(hào)化, 這樣我們就無(wú)法獲知到底出現(xiàn)了什么錯(cuò)誤
  • Xcode符號(hào)化崩潰日志時(shí)，需要訪問與App Store上對(duì)應(yīng)的應(yīng)用二進(jìn)制文件以及生成二進(jìn)制文件時(shí)產(chǎn)生的 .dSYM 文件
  • 所以，保留每個(gè)分發(fā)給用戶的編譯版本非常重要。提交應(yīng)用前進(jìn)行歸檔時(shí)，Xcode將保存應(yīng)用的二進(jìn)制文件。可以在Xcode Organizer的Archives標(biāo)簽欄下找到所有已歸檔的應(yīng)用文件。