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大解析
网友评论