先上几张最近bugly搜集到的崩溃信息的图：
起初遇到这种情况都会觉得不可思议，后来发现这就是野指针造成的。
我觉得平时开发xcode崩溃信息查看的并不多，所以直接说符号表相关的。
xcode崩溃信息查看：xcode->Window->Organizer->Crashes
崩溃分析之符号表：
符号表是编译生成的.app的同目录下生成的.dSYM文件，.dSYM是一个目录，在子目录中包含了一个16进制的保存函数地址映射信息的中转文件，所有Debug的symbols都在这个文件中(包括文件名、函数名、行号等)，所以也称之为调试符号信息文件。
通过符号表就能找到对应的能够直观看到的方法名之类
这里重点说野指针：
1.据下面这篇文章统计的 野指针概率大概1/5，而且多数是一些奇奇怪怪的崩溃
https://blog.csdn.net/tencent_bugly/article/details/46277055
https://blog.csdn.net/tangaowen/article/details/46830019
https://msd.misuland.com/pd/300175265395380224
https://blog.csdn.net/tangaowen/article/details/46830049
https://www.jianshu.com/p/9fd4dc046046?utm_source=oschina-app
野指针是指指向一个已删除的对象或未申请访问受限内存区域的指针。本文说的Obj-C野指针，说的是Obj-C对象释放之后指针未置空，导致的野指针（Obj-C里面一般不会出现为初始化对象的常识性错误）。
既然是访问已经释放的对象为什么不是必现Crash呢？
因为dealloc执行后只是告诉系统，这片内存我不用了，而系统并没有就让这片内存不能访问。
现实大概是下面几种可能的情况：
1. 对象释放后内存没被改动过，原来的内存保存完好，可能不Crash或者出现逻辑错误（随机Crash）。
2. 对象释放后内存没被改动过，但是它自己析构的时候已经删掉某些必要的东西，可能不Crash、Crash在访问依赖的对象比如类成员上、出现逻辑错误（随机Crash）。
3. 对象释放后内存被改动过，写上了不可访问的数据，直接就出错了很可能Crash在objc_msgSend上面（必现Crash，常见）。
4. 对象释放后内存被改动过，写上了可以访问的数据，可能不Crash、出现逻辑错误、间接访问到不可访问的数据（随机Crash）。
5. 对象释放后内存被改动过，写上了可以访问的数据，但是再次访问的时候执行的代码把别的数据写坏了，遇到这种Crash只能哭了（随机Crash，难度大，概率低）！！
6. 对象释放后再次release（几乎是必现Crash，但也有例外，很常见）。
针对野指针的解决方案：
让野指针被访问时立马崩溃，也就是一定程度的增加崩溃率
1.xcode方式：这种方式对于测试人员是不合适的，因为依赖xcode
malloc scribble选项
Xcode帮我们 在 对象释放后，随机填入不可访问的数据，导致野指针立即崩溃
2.手动实现：
hook c语言 free函数的方式，现成的第三方库 fishhook
在hook的函数中 填充0x55（Xcode 帮我们填充的这个，用方式1崩溃时能发现）
void safe_free(void* p){
size_tmemSiziee=malloc_size(p);
memset(p,0x55, memSiziee);
orig_free(p);
return;
}
