標籤：
轉自：http://www.cocoachina.com/industry/20140514/8418.html
轉自wufawei的部落格
當你的應用提交到App Store或者各個渠道之後，請問你多久會拿到crash檔案？你如何分析crash檔案的呢？
上傳crash檔案你的應用應當有模組能夠在應用程式crash的時候上傳crash資訊。 要麼通過使用者反饋拿到crash檔案，要麼藉助自己或第3方的crash上傳模組拿到crash檔案。 今天要分析的情境是你拿到使用者的.crash檔案之後，如何符合化crash檔案（Symbolicating crash logs）的3種方法。協助儘快找到crash原因。
crash檔案例子crash檔案的部分內容：
| Last Exception Backtrace:0 CoreFoundation 0x30acaf46 exceptionPreprocess + 1261 libobjc.A.dylib 0x3af0b6aa objc_exception_throw + 342 CoreFoundation 0x30a0152e -[__NSArrayM objectAtIndex:] + 2263 appName 0x000f462a 0x4000 + 9846184 appName 0x00352aee 0x4000 + 3468014…18 appName 0x00009404 0x4000 + 21508 |
大家一眼就能看到：
| 2 CoreFoundation 0x30a0152e -[__NSArrayM objectAtIndex:] + 226 |
這一行有問題。 但是，第3行和第4行的：
| 3 appName 0x000f462a 0x4000 + 9846184 appName 0x00352aee 0x4000 + 3468014 |
並沒有指出到底是app的那個模組導致的問題，如何排查呢？
有如下3種方法
方法1 使用XCode這種方法可能是最容易的方法了。 需要使用Xcode符號化 crash log，你需要下面所列的3個檔案：1. crash報告（.crash檔案）2. 符號檔案 (.dsymb檔案)3. 應用程式檔案 (appName.app檔案，把IPA檔案尾碼改為zip，然後解壓，Payload目錄下的appName.app檔案),
這裡的appName是你的應用程式的名稱。 把這3個檔案放到同一個目錄下，開啟Xcode的Window菜單下的organizer，然後點擊Devices tab，然後選中左邊的Device Logs。 然後把.crash檔案拖到Device Logs或者選擇下面的import匯入.crash檔案。 這樣你就可以看到crash的詳細log了。 如：
方法2 使用命令列工具symbolicatecrash有時候Xcode不能夠很好的符號化crash檔案。我們這裡介紹如何通過symbolicatecrash來手動符號化crash log。 在處理之前，請依然將“.app“, “.dSYM”和 ".crash"檔案放到同一個目錄下。現在開啟終端(Terminal)然後輸入如下的命令：
- export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
然後輸入命令：
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash appName.crash appName.app > appName.log
現在，符號化的crash log就儲存在appName.log中了。
方法3 使用命令列工具atos如果你有多個“.ipa”檔案，多個".dSYMB"檔案，你並不太確定到底“dSYMB”檔案對應哪個".ipa"檔案，那麼，這個方法就非常適合你。
特別當你的應用發布到多個渠道的時候，你需要對不同渠道的crash檔案，寫一個自動化的分析指令碼的時候，這個方法就極其有用。
這裡先介紹一個概念：
UUID
什麼是UUID每一個可執行程式都有一個build UUID來唯一標識。Crash日誌包含發生crash的這個應用（app）的 build UUID以及crash發生的時候，應用載入的所有庫檔案的[build UUID]。
那如何知道crash檔案的UUID呢？ 可以用：
- grep "appName armv" *crash
或者
- grep --after-context=2 "Binary Images:" *crash
可以得到類似如下的結果：
- appName.crash-0x4000 - 0x9e7fff appName armv7 <8bdeaf1a0b233ac199728c2a0ebb4165> /var/mobile/Applications/A0F8AB29-35D1-4E6E-84E2-954DE7D21CA1/appName.crash.app/appName
（請注意這裡的0x4000，是模組的載入地址，後面用atos的時候會用到）
如何找到app的UUID可以使用命令：
- xcrun dwarfdump -–uuid <AppName.app/ExecutableName>
比如：
- xcrun dwarfdump --uuid appName.app/appName
結果如下：
- UUID: 8BDEAF1A-0B23-3AC1-9972-8C2A0EBB4165 (armv7) appName.app/appName
- UUID: 5EA16BAC-BB52-3519-B218-342455A52E11 (armv7s) appName.app/appName
這個app有2個UUID，表明它是一個fat binnary。 它能利用最新硬體的特性，又能相容老版本的裝置。 對比上面crash檔案和app檔案的UUID，發現它們是匹配的：
- 8BDEAF1A-0B23-3AC1-9972-8C2A0EBB4165
用atos命令來符號化某個特定模組載入地址命令是：
- atos [-o AppName.app/AppName] [-l loadAddress] [-arch architecture]
親測，下面3種都可以：
- xcrun atos -o appName.app.dSYM/Contents/Resources/DWARF/appName -l 0x4000 -arch armv7
- xcrun atos -o appName.app.dSYM/Contents/Resources/DWARF/appName -arch armv7
- xcrun atos -o appName.app/appName -arch armv7
（註：這3行選任意一行執行都可以達到目的，其中0x4000是模組的載入地址，從上面的章節可以找到如何得到這個地址。） 文章開頭提到crash檔案中有如下兩行，
- * 3 appName 0x000f462a 0x4000 + 984618
- * 4 appName **0x00352aee** 0x4000 + 3468014
在執行了上面的：
- xcrun atos -o appName.app.dSYM/Contents/Resources/DWARF/appName -l 0x4000 -arch armv7
之後，輸入如下地址：
- 0x00352aee
（crash檔案中的第4行：4 appName **0x00352aee** 0x4000 + 3468014） 可以得到結果：
- -[UIScrollView(UITouch) touchesEnded:withEvent:] (in appName) (UIScrollView+UITouch.h:26)
這樣就找到了應用種到底是哪個模組導致的crash問題。
總結本文分析了拿到使用者的.crash檔案之後，如何符合化crash檔案的3種方法，分別有其適用情境，方法3適用於自動化crash檔案的分析。 參見：[1] :How to Match a Crash Report to a Build[2] :Understanding and Analyzing iOS Application Crash Reports[3] :Fixing Bugs: Using OS X crash logs and atos to symbolicate and find line numbers[4] :Symbolicating Crash Logs[5] :Symbolicating iPhone App Crash Reports
分析iOS Crash檔案：符號化iOS Crash檔案的3種方法
