常见崩溃
1、多线程同步问题造成的Crash
对于数据源的访问一定要注意多线程同时访问的情况，要做好对它的保护。这里可以使用GCD的串行队列来同步线程操作。
2、Observer的移除
注册observer很简单，但是移除的时候很容易出问题了。要么是忘记移除observer了，要么是移除的时机不对。如果某个被观察对象已经被释放了，observer还在，那结果只能是crash了，所以切记至少在dealloc里面移除一下observer。
3、NSMutableArray, NSMutableDictionary成员的判空保护
在addObject或insertObject到NSMutableArray或者NSMutableDictionary时最好加一下判空保护，尤其网络相关的逻辑，如果网络返回为空(jason解析出来为空)，而直接add到NSMutableArray里面或者insert到NSMutableDictionary, 那么就会Crash。
关于dSYM文件
dSYM文件：Xcode编译项目后，会得到一个同名的dSYM文件，dSYM是保存16进制函数地址映射信息的中转文件，调试的symbols都会包含在这个文件中，并且每次编译项目的时候都会生成新的dSYM文件，位于/sers/<用户名>/Library/Developer/Xcode/Archives目录下，对于每一个发布版本都很有必要保存对应的 Archives文件。
当软件release模式打包或上线后，不会像在Xcde中那样直观的看到用崩溃的错误，这个时候就需要分析crash report文件，iOS设备中会有日志文件保存每个应用出错的函数内存地址，通过Xcode的Organizer可以将设备中的Devicelog导出成crash文件，这个时候就可以通过出错的函数地址去查询dSYM文件中程序对应的函数名和文件名。大前提是需要有软件版本对应的dSYM文件，这也是为什么很有必要保存每个发布版本的Archives文件了。
每一个xx. app和xx.app. dsym文件都有对应的UUD，crash文件也有自己的UUD，只要这三个文件的UUD一致，就可以通过他们解析出正确的错误函数信息了。
- 查看××app文件的UUD，terminal中输入命令dwarfdump-- uuid xx. app/×x(x代表你的项目名）
- 查看 xx. app.dsYM文件的UUD，在 termina中输入命令：dwarfdump- uuid xx. app.dSYM
- crash文件内第一行Incident Identifier就是该crash文件的UUD
dSYM分析工具：可以分析友盟崩溃日志。
