1.初识Crash
Crash即我们通常所说的闪退或者程序崩溃。一般会出现在3种地方：
1.我们正在编写程序的时候，运行崩溃。
2.测试阶段，测试出现的崩溃闪退。
3.项目上线后用户出现的崩溃闪退。
2.如何定位
针对三种方式的定位方法:
2.1.debug
添加All Exceptions
即可定位到对应的代码。
2.2.测试阶段
这个时候我们就需要测试提供给我们手机崩溃后的crash文件，可以通过itools，itunesConnect，Xcode等工具获得，然后结合.app，.dsym文件，对crash日志的符号化，具体参考:分析iOS Crash文件：符号化iOS Crash文件的3种方法
2.3.线上App
线上App的解析原理跟测试阶段的类似，只是想办法把crash日志上传到服务器即可，有的甚至还做了符号化，定位到了代码的具体位置，目前很多第三方的平台的SDK都支持，只需要简单的集成到代码中即可。常用的有:友盟，OneAPM，听云，Crashlytics，Flurry等。
3.如何产生
crash日志的产生来源于两种问题：违反iOS策略被干掉，以及自身的代码bug。
3.1.违反iOS策略
3.1.1.内存报警闪退
当iOS检测到内存过低时，它的VM系统会发出低内存警告通知，尝试回收一些内存；如果情况没有得到足够的改善，iOS会终止后台应用以回收更多内存；最后，如果内存还是不足，那么正在运行的应用可能会被终止掉。
3.1.2.Watchdog响应超时
当应用程序对一些特定的事件（比如启动、挂起、恢复、结束）响应不及时，苹果的Watchdog机制会把应用程序干掉，并生成一份相应的crash日志。
3.1.3.用户非正常的强制退出
这里指的“用户强制退出”场景，是稍微比较复杂点的操作：先按住电源键，直到出现“滑动关机”的界面时，再按住Home键，这时候当前应用程序会被终止掉，并且产生一份相应事件的crash日志（分厂少见）。
3.2.应用逻辑的Bug
比较常见的崩溃基本都源于代码bug，比如数组越界、插空、空引用、引用的数据类型不对、发送未实现的方法、多线程安全性、访问野指针，新老系统兼容等。
3.2.1.数组越界
取得对应索引位置的对象，但是索引位置已经超过数组的长度。
3.2.2.插空
插入数组的元素为空
3.2.3.空引用
对象置空了，却有作为某方法的参数时
3.2.4.引用数据类型不对
a类型的数值赋值给b类型了，如果是不支持自动强转的类型则会crash
3.2.5.发送未实现的方法
多见于代理方法调用，而代理的类并未实现改方法。此时调用该类的对象的代理方法，则会crash
3.2.6.多线程安全
当多个线程对同一个数据进行读写而造成的crash。
3.2.7.访问野指针
对象指向的内存释放后没有置nil，因为其指向的为垃圾内存，野指针，已经不属于该对象了，再次调用该对象，则会crash（多见于MRC）。
3.2.8.新老系统兼容
调用新的api特性时候，就的版本不支持相应的方法。
4.如何解决
4.1.违反iOS策略
4.1.1.内存警告
需要及时的释放掉不使用的内存空间，避免循环引用等问题。
4.1.2.Watchdog响应超时
应该尽量避免耗时操作出现在主线程中即可。
4.2.应用逻辑的Bug
4.2.1.数组越界
进行索引越界判断
4.2.2.插空&空引用
非空判断
4.2.3.引用的数据类型不对
进行数据类型的判断
4.2.4.发送未实现的方法
需要提前判断对象是否响应对应方法
4.2.5.多线程安全
对被竞争的资源进行加锁。
4.2.6.访问野指针
ARC下编译器已经进行了处理，MRC下release后记得置空。
4.2.7.新老系统兼容
调用新的api特性时候，记得提前做版本判断。
5.与服务端交互需要注意事项
针对上面所述，有些时候与服务端交互时，接口的合理制定也可以避免不必要的麻烦，比如
5.1.返回数据的数据类型
根据接口文档确定类型并进行转化
5.2.数据为空时候的数据处理
建议字符串返回空串，整数和浮点数可以返回0。数组返回空数组，字典返回空字典。最好不要有字段的缺失。
6.参考文献
a.iOS crash日志分析
b.分析iOS Crash文件：符号化iOS Crash文件的3种方法
c.iOS Crash - 分析篇
d.ios crash的原因与抓取crash日志的方法<来自网络分享>
e.iOS崩溃crash大解析
