最初始的需求是：怎么定位线上的奔溃。
那就是捕获NSException，收集发送到后台统一处理。或者接入第三方奔溃统计的库，让他们把这些都做了。
这里面都有一个绕不过的问题是，得到的信息里有些是未符号化、显示为内存地址的信息：
怎么把地址转为对应的方法/函数就是符号化的任务。为啥叫符号化？在编译链接系统中，函数、变量这些都被认为是符号，有一个叫符号表的东西：
所以解析过程需要的材料就是符号表，用它就可以用地址反向定位它的符号，得到需要的方法名。
- 对于我们的APP，符号表就在dSYMs文件里，dSYMs应该就是debug symbols的缩写。
- 对于系统库，如UIKit，在它们的framework里。/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/System/Library/Frameworks/UIKit.framework
奔溃信息的获取
- 手机直接导入：window --> device --> view device logs. 这里面是格式化的crash文件，而且用Xcode查看时会自动符号化。
- 在App Store上查看，这个需要用户在设置里同意了上传奔溃信息。
- 前面两种几乎没什么暖用，对于线上的奔溃信息，得自己获取：
//没有捕获的异常会调用这里设置的函数
NSSetUncaughtExceptionHandler(analyzeAndSaveException);
void analyzeAndSaveException(NSException *exception){
NSArray<NSString *> *symbols = [exception callStackSymbols];
NSString *reason = [exception reason];
NSDictionary *userInfo = [exception userInfo];
NSString *name = [exception name];
//按某种格式存到本地，然后上传到服务器
}
测试了下，在这个函数执行结束前，程序是不会狗带的，网络请求这种需要等待回调的肯定是不行了，但写到本地文件里还是可以的。
重点就是这个callStackSymbols，是引起奔溃的函数的调用栈，比如：
这里就是部分符号化的，4-17这些都是显示的内存地址。如果是打包后安装的APP，调用栈跟上面直接连接xcode运行的又不同，关键性的第三点是这样的：
"3 CrashAnalyze 0x00000001000dbda8 CrashAnalyze + 32168"
符号化命令
atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate>
- -arch 指定对应的cpu架构
- -o 指定符号表路径，对APP本身的方法是
dSYM文件路径/Contents/Resources/DWARF/app名称,对系统方法是/Users/shiwei/Library/Developer/Xcode/iOS\ DeviceSupport/10.3.3\ \(14G60\)/Symbols/System/Library/Frameworks/库名.framework/库名，注意路径有个版本区别。 - -l 指定load address,就是这个库加载的地址
- 最后的是需要被符号化的地址
从命令里可以看出，奔溃日志需要这些信息：
- 机型，有了这个就知道cpu架构了
- 系统版本，有系统版本可以知道对应的系统库的版本，但最好是每个库的UUID，ID总是不会错的。
- 每个库的加载地址。
以前也有一些符号化和dSYMs文件的文章和工具，我试了下，好像没用了。区别是没有考虑load address的问题，具体的我没仔细考证。
怎么知道是哪个库的方法？
- 调用栈里的每条前面都有库的名字，自己APP的代码就是APP的名称
- 我观察到一点：加载地址是有区间的，比如加载地址从小到大是：libA --- libB --- libC,而需要符号化的地址落在libB和libC之间，那么就是libB的函数了。
怎么获取加载地址？
#import <mach-o/dyld.h>
.....
uint32_t numImages = _dyld_image_count();
for (uint32_t i = 0; i < numImages; i++) {
const struct mach_header *header = _dyld_get_image_header(i);
const char *name = _dyld_get_image_name(i);
const char *p = strrchr(name, '/');
if (p) {
NSLog(@"module=%s, address=%p", p + 1, header);
}
}
怎么获取UUID?
iOS 如何获取 Mach-O 的 UUID
测试：
//对APP本身
atos -arch arm64 -o ~/Desktop/CrashAnalyze.app.dSYM/Contents/Resources/DWARF/CrashAnalyze -l 0x100068000 0x10006fd8c
-[ViewController triggerException] (in CrashAnalyze) (ViewController.m:61)
//对UIKit
atos -arch arm64 -o /Users/shiwei/Library/Developer/Xcode/iOS\ DeviceSupport/10.3.3\ \(14G60\)/Symbols/System/Library/Frameworks/UIKit.framework/UIKit -l 0x196f2d000 0x0000000196f71bd4
-[UIControl sendAction:to:forEvent:] (in UIKit) + 80
系统库的符号化更多看这里
最后
这些东西如果要自己手动处理确实很麻烦，因为必要的数据和材料都可以上传给服务器，所以做一套系统，自动上报crash信息，后台根据提供的符号表或dSYMs文件，再加上各个系统库的各个版本的符号表，就可以让程序自动去处理这些。
这样一个自动化的系统才更有价值吧！
然后看了下Bugly做了这样的处理，Bugly iOS 符号表配置
Understanding and Analyzing Application Crash Reports
iOS Crash分析必备：符号化系统库方法
符号表
