iOS 崩溃日志 Backtrace的符号化

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行中一行一行的解析出来,就能看到发生崩溃的地方,再进行分析就简单了.