符号化的两种方式：
1.利用Xcode符号化
2.利用symbolicatecrash脚本符号化
其实这两种分析方式都使用了同一个工具符号化:***atos***。
atos是苹果提供的符号化工具，在Mac OS系统下默认安装。
使用***atos***符号化需要dsym文件。dsym文件是在编译工程的时候生成的，可以在Xcode Organizer的Archives标签栏下找到所有已归档的应用文件。它保存了编译过程的详细信息，其中包括符号信息。
注意: 你必需同时保留应用二进制文件和.dSYM文件才能将崩溃日志完整符号化。每次提交到iTunes Connect的构建都必需归档。.dSYM文件和二进制文件是特定绑定于每一次构建和后续构建的，即使来自相同的源代码文件，每一次构建也与其他构建不同，不能相互替换。如果你使用Build 和 Archive 命令,这些文件会自动放在适当位置。 如果不是使用Build 和 Archive命令，放在Spotlight能够搜索到的位置（比如Home目录）即可。
atos用法：
atos -o dysm文件路径 -l 模块load地址 -arch cpu指令集种类 调用方法的地址
atos -arch armv7 -o "StarMaker.app.dSYM" -l 0x66000 0x012c03e1
dysm文件路径：可以在Xcode Organizer的Archives标签栏下找到所有已归档的应用文件。它保存了编译过程的详细信息，其中包括符号信息。
模块load地址：模块加载的基地址，可以在日志的***动态库信息***中找到对应模块的基地址。这里为0x66000
cpu指令集种类：可以为armv6 armv7 armv7s arm64。具体用哪个，可以参考对应模块的***动态库信息***中确定。如
0x66000 - 0x19cdfff +StarMaker armv7 <43ebe409980f31fd9be165a64b002af5> /var/mobile/Applications/E3B51E77-D44D-4B3E-8767-B7DC2008D138/StarMaker.app/StarMaker
1、Exception Type
1）EXC_BAD_ACCESS
此类型的Excpetion是我们最常碰到的Crash，通常用于访问了不该访问的内存导致。一般EXC_BAD_ACCESS后面的"()"还会带有补充信息。
SIGSEGV: 通常由于重复释放对象导致，这种类型在切换了ARC以后应该已经很少见到了。
SIGABRT: 收到Abort信号退出，通常Foundation库中的容器为了保护状态正常会做一些检测，例如插入nil到数组中等会遇到此类错误。
SEGV:（Segmentation Violation），代表无效内存地址，比如空指针，未初始化指针，栈溢出等；
SIGBUS：总线错误，与 SIGSEGV 不同的是，SIGSEGV 访问的是无效地址，而 SIGBUS 访问的是有效地址，但总线访问异常(如地址对齐问题)
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限
