iOS的崩潰日誌配合dsym檔案可以找到崩潰時的backtrace,這是解決崩潰的最重要的資訊.


如果是在同一臺mac上打包, 匯入crash log時候會自動將backtrace符號化,可以看到方法名, 檔名和行號


但是,有時候發版的包不是在你的mac上打包的,xcode找不到對應的符號表, backtrace沒能符號化如下所示:


Last Exception Backtrace:
0 CoreFoundation 0x2cb535f2 __exceptionPreprocess + 122
1 libobjc.A.dylib 0x3a3c5c72 objc_exception_throw + 34
2 CoreFoundation 0x2ca67152 -[__NSArrayM objectAtIndex:] + 226
3 myapp 0x004fe736 0x9b000 + 4601654
4 myapp 0x00507ed4 0x9b000 + 4640468
5 myapp 0x004fd112 0x9b000 + 4595986
6 myapp 0x003275c6 0x9b000 + 2672070


這裡第二行可以看到是一個數組objectAtIndex丟擲異常,但是3-6行的是來自應用自己的程式碼myapp, 這些資訊才是最重要的.


其實,只要有原app檔案,是可以將這些資訊找到.


方法:


將對應版本的myapp.app檔案和crash檔案放在同一個資料夾下, 注意,一定要是該應用正確版本的app, 因為每次打包, 符號表的對映關係都有可能不同,如果不對應的話是沒法符號化的.


然後執行


atos -arch armv7 -o myapp.app/myapp -l 0x9b000 0x004fe736


這個方法 -arch後面是指硬體架構:
iphone 1,2,3 是armv6
iphone4,4s 是 armv7
iphone5,5c是armv7s
iphone 5s, 6, 6+, 6s, 6s+ 是arm64


根據崩潰發生的裝置來選擇上述架構, myapp.app就是你的app的檔名, 選項l後面的兩個16進位制數是關鍵:
第一個數字,取backtrace的要解析的行的第4列, 第二個數字取第3列, 就會得到對應的方法名,檔名,行號.
這樣,可以將上述3-6行中一行一行的解析出來,就能看到發生崩潰的地方,再進行分析就簡單了.