iOS常见崩溃简介

已于 2024-04-06 11:24:22 修改
阅读量1.2k 收藏 15
点赞数 9
分类专栏： iOS 文章标签： ios
于 2024-03-17 13:18:33 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/IOSSHAN/article/details/136779829
版权

1. 崩溃

多指在移动设备（如iOS、Android设备）中或不可移动设备（如:Windows、Linux等设备），
在打开或使用应用程序时出现的突然退出中断的情况（类似于Windows的应用程序崩溃）。

多表现为：应用程序画面一闪而过，随即退回到桌面。

崩溃会影响用户体验，造成用户流失，因此，我们要重视崩溃
在这里插入图片描述

根据不同场景，崩溃收集方式不同

Xcode编译期间：

在这里插入图片描述

测试机获取：

Xcode->Window->Devices and Simulators
在这里插入图片描述
或者
设置->隐私->分析与改进

线上崩溃采集：

封装好的三方，直接接入的：友盟、bugly、听云
开源的SDK：KSCrash、plcrashreporter

2. 崩溃产生的原因

划分方式一：

  • cpu无法执行的代码
  • 被系统强杀
  • 语言触发异常

2.1 cpu无法执行的代码

  • 无效指令或操作
  • 访问无效地址及不具有权限的内存地址
  • 除以0等
  • 僵尸对象
    …

2.2 被系统强杀

  • 应用内存消耗过高，即OOM问题
  • 主线程长时间无法响应ANR
  • 资源异常
  • 死锁
  • 非法的应用签名
  • 后台执行超时
    …

2.3 语言触发异常

  • OC语言抛出异常
  • C++抛出异常
    …

划分方式二：

除了上面的划分方式，崩溃还可以按：软件异常、硬件异常划分

软件异常：
软件异常主要来自 kill()，pthread_kill()。iOS 中的 NSException 未捕获,abort 都属于这种情况。

硬件异常：
硬件的信号始于处理器 trap，是和平台相关的。野指针崩溃大部分是硬件异常。

软件异常的流程是：

软件异常 -> Unix信号

硬件异常的流程是：

硬件异常 -> Mach异常 -> Unix信号
在这里插入图片描述

在这里插入图片描述

Mach 异常：

  • EXC_BAD_ACCESS: 不能访问的内存
  • EXC_BAD_INSTRUCTION： 非法或未定义的指令或操作数
  • EXC_ARITHMETIC： 算术异常(例如除以0)。iOS 默认是不启用的，所以我们一般不会遇到
  • EXC_EMULATION: 执行打算用于支持仿真的指令
  • EXC_SOFTWARE：软件生成的异常，我们在 Crash 日志中一般不会看到这个类型，苹果的日志里会是 EXC_CRASH
  • EXC_BREAKPOINT：跟踪或断点
  • EXC_SYSCALL: UNIX 系统调用
  • EXC_MACH_SYSCALL: Mach 系统调用

UNIX 信号：

  • SIGSEGV，段错误。访问未分配内存、写入没有写权限的内存等。
  • SIGBUS，总线错误。比如内存地址对齐、错误的内存类型访问等。
  • SIGILL，执行了非法指令，一般是可执行文件出现了错误。
  • SIGFPE ，致命的算术运算。比如数值溢出、NaN数值等。
  • SIGABRT，调用 abort() 产生，通过 pthread_kill() 发送。
  • SIGPIPE，管道破裂。通常在进程间通信产生。比如采用FIFO(管道)通信的两个进程，读管道* 没打开或者意外终止就往管道写，写进程会收到SIGPIPE信号。根据苹果相关文档，可以忽略这个信号。
  • SIGSYS，系统调用异常。
  • SIGKILL，此信号表示系统中止进程。崩溃报告会包含代表中止原因的编码。exit(), kill(9) 等函数调用。iOS 系统杀进程，如 watchDog 杀进程。
  • SIGTRAP，断点指令或者其他trap指令产生。

当我们拦截信号处理之后是可以让程序不崩溃而继续运行的，但是不建议这样做，因为程序已经处于异常不可知状态。
看上图里面最终都会转换为 “UNIX信号”， 是不是代表我们只用监听 “UNIX 信号” 就够了呢？为什么还要拦截 Mach 异常呢？

不是所有的 "Mach异常” 类型都映射到了 “UNIX信号”
“UNIX信号” 在崩溃线程回调，如果遇到 Stackoverflow 问题，已经没有条件(栈空间)再执行回调代码了。

捕获到异常信号后，在处理方法 handleSignalException 里通过 backtrace_symbols 方法就能获取到当前的堆栈信息。
堆栈信息可以先保存在本地，下次启动时再上传到崩溃监控服务器就可以了。

Mach是一个XNU的微内核核心

在这里插入图片描述

3. 崩溃日志包含信息

基本信息：崩溃发生的日期、iOS 版本等
进程信息：崩溃进程的相关信息，比如崩溃报告唯一标识符、唯一键值、设备标识
异常信息：异常类型、异常编码、异常的线程；
线程回溯：崩溃时的方法调用栈

崩溃日志调用栈内容：
在这里插入图片描述
这样直接看崩溃信息的调用栈，是看不懂的

我们需要一个.DSYM文件，dSYM 是保存 函数地址映射信息的中转文件，其中包含文件名、方法名、行号等信息，是和可执行文件的16进制函数地址一一对应的，通过分析崩溃的崩溃文件可以准确知道具体的崩溃信息。
在这里插入图片描述
一个ipa包，对应一个.DSYM文件
每次编译生成的 dSYM都会有所差别，通常 dSYM 中会有一个唯一标识，称作 UUID ，用以区分不同的 dSYM 文件。

UUID(Universally Unique Identifier)：一个app包对应一个UUID
UDID(Unique Device Identifier)：一个手机设备对应一个UDID

在这里插入图片描述
通过.DSYM文件的解析，就可以找到对应的文件名和函数名

具体的做法？

方法一：

具体的做法：

  1. 首先要通过崩溃信息里面，找到UUID，然后通过UUID找到对应正确的.dsym的
  2. 找到崩溃日志的关键信息，获取：偏移量、运行时堆栈地址、运行时APP起始地址

在这里插入图片描述

相对于起始地址的偏移量为 29796，运行时堆栈地址为 0x102a47464，运行时APP起始地址为 0x102a40000。

  1. 通过.dsym拿到起始地址(dSYM 文件中保存中符号表 TEXT 段的起始地址)，再加上崩溃日志的偏移量，获取运行时堆栈地址在.dsym的真正地址
  2. 查找.dsym上的运行地址，解析即可

因为 iOS 加载 Mach-O 文件时为了安全使用了 ASLR(Address Space Layout Randomization) 机制，导致二进制 Mach-O 文件每次加载到内存的首地址都会不一样，但是偏移量，加载地址，起始地址的计算规则是一样的；
从上面我们可以得到 0x102a47464 (运行时地址) = 0x102a40000 (起始地址) + 29796(偏移量)这个公式。
因此通过 dSYM 的起始地址和偏移量就可以计算出 0x102a47464 对应在 dSYM 中的地址为 0x100007464 = 0x0000000100000000 + 29296。

在这里插入图片描述

OS 崩溃日志在线符号化实践

方法二：使用命令atos

跟前面那个方法的理论是一致的，只是命令不一样

atos -o 项目名.app.dSYM/Contents/Resources/DWARF/项目名 -l 基地址(运行初始地址) 偏移后的地址

笔者使用的命令参考如下

atos -o Test.app.dSYM/Contents/Resources/DWARF/Test -l 0x1026b4000 0x1026B9904

iOS dSYM详解和分析crash，ips文件

方法三：使用symbolicatecrash脚本

symbolicate：象征

symbolicatecrash是一个Perl脚本，随Xcode提供，专门用于符号化崩溃日志。你需要找到这个脚本的位置（通常在Xcode的App包内），然后在命令行中使用它，如下：

使用命令find /Applications/Xcode.app -name symbolicatecrash -type f获取到symbolicatecrash

/path/to/symbolicatecrash /path/to/MyApp.crash /path/to/MyApp.dSYM > Symbolicated.crash

在桌面上新建一个文件夹，把.app文件、.app.dSYM文件、.crash文件、symbolicatecrash工具，一起放到新建的文件夹下：
在这里插入图片描述

然后执行命令：

export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
./symbolicatecrash JCrashDemo.crash JCrashDemo.app.dSYM > new.crash

即可获取一个新的解析好的crash文件

使用symbolicatecrash解析崩溃日志

方法四：使用其他更便捷的脚本

即，将好几步要执行的步骤，简单化

4. 开发中常见崩溃

  • unrecognized selector crash
  • KVO crash
  • NSNotification crash
  • NSTimer crash
  • Container crash（数组越界，插nil等）
  • NSString crash （字符串操作的crash）
  • UI not on Main Thread Crash (非主线程刷UI(机制待改善))
  • …

unrecognized selector crash

当一个对象找不到对应的方法实现的时候，会报此类错误

在找不到方法时，查找方法将会进入方法forward流程,系统给了三次补救的机会，
所以我们要解决这个问题，在这三次均可以解决这个问题
在这里插入图片描述

KVO crash

KVO监听对象属性值的改变

KVO 日常使用造成崩溃的原因通常有以下几个：

  • KVO 添加次数和移除次数不匹配：
  • 移除了未注册的观察者，导致崩溃。
  • 重复移除多次，移除次数多于添加次数，导致崩溃。
  • 重复添加多次，虽然不会崩溃，但是发生改变时，也同时会被观察多次。
  • 被观察者提前被释放，被观察者在 dealloc 时仍然注册着 KVO，导致崩溃。
  • …

NSNotification crash

当一个对象添加了notification之后，如果dealloc的时候，仍然持有notification，就会出现NSNotification类型的crash。

在iOS9以及iOS9以后，可以不做移除通知操作

NSTimer crash

一般是在定时器被target强引用没有被释放，产生内存泄露，或者在定时器触发的时候导致崩溃
解决方案：
1.NSTimer使用Block，对其target不强引用
2.是否找到一个合适的时机，在确定NSTimer已经失效的情况下，让NSTimer自动invalidate
3.使用中间变量

类族(NSArray,NSMutableArray,NSDictonary,NSMutableDictionary)

  • 插入空对象
  • 数组越界
  • 不可变类型插入数据
  • …

建议：

  • 加三目运算符，防止数据为空
  • 数组取值的时候，判断数组个数
  • 遇到可变类型，使用strong修饰

非主线程刷UI

UI刷新，必须在主线程操作
在子线程中，需要刷新UI的时候，要切换到主线程

野指针

在这里插入图片描述

定义：当所指向的对象被释放或者收回，但是对该指针没有作任何的修改，以至于该指针仍旧指向已经回收的内存地址，此情况下该指针便称野指针

若操作系统将这部分已经释放的内存重新分配给另外一个进程，而原来的程序重新引用现在的迷途指针，则将产生无法预料的后果。因为此时迷途指针所指向的内存现在包含的已经完全是不同的数据。

在这里插入图片描述

解决方法：

Xcode开启僵尸对象监听
在这里插入图片描述

使用MLeaksFinder或其他三方库，排查内存泄露问题
在这里插入图片描述

使用JJException，减少App闪退
当然，最好做到：开发过程不使用，正式包开启
在这里插入图片描述

参考资料：
iOS 野指针处理
iOS野指针定位总结

Chat-GPT有关野指针的解释

问：iOS野指针错误一般由什么引起的？怎么排查与避免？

答：

iOS 开发中的野指针错误通常是指向一个已经被释放的对象的指针仍然被访问时发生的错误。这种错误可能导致应用崩溃或不稳定的行为。野指针错误的主要原因包括但不限于：

  1. 对象被提前释放：当你尝试访问一个已经被释放的对象时，就会出现野指针错误。这通常是因为对象的引用计数被错误管理，如被提前释放或没有正确地持有对象。
  2. 内存管理不当：在手动管理内存（如使用MRC, 手动引用计数）的项目中，如果没有正确地平衡retain和release调用，可能会导致对象提前释放，从而引发野指针错误。
  3. 指针未初始化或重置：使用未初始化的指针或者在释放对象后未将指针设为nil，也可能导致野指针访问。

如何排查野指针错误：

  1. 使用Xcode的调试工具：利用Xcode的调试工具，如LLDB调试器，可以帮助你定位野指针的来源。Zombies工具尤其有用，它可以帮助追踪已释放对象的访问尝试。
  2. 代码审查：定期进行代码审查可以帮助发现潜在的内存管理错误，特别是对于使用MRC的项目。
  3. 静态分析工具：Xcode自带的静态分析工具可以帮助检测潜在的内存管理问题，包括可能导致野指针错误的情况。

如何避免野指针错误：

  1. 使用自动引用计数(ARC)：自动引用计数可以大大减少内存管理错误。确保项目启用ARC，让编译器帮助管理对象的生命周期。
  2. 指针置nil：在释放对象后，将指向该对象的指针置为nil，这样即使尝试访问该指针，也不会导致崩溃。
  3. 避免使用未初始化的指针：在声明指针变量时，初始化为nil，以避免使用未初始化的指针。
  4. 遵循内存管理规则：即使在ARC环境下，也需要理解并遵循基本的内存管理规则，如不要持有非自己创建的对象，除非这个对象已经明确地被retain了。
  5. 使用弱引用：对于不需要拥有对象的引用，使用弱引用可以避免循环引用和提前释放的问题。

通过采取这些措施，你可以显著减少应用中野指针错误的发生，提高应用的稳定性和可靠性。

不得不说，回答的还蛮好的

AsiaSun.
关注
  • 9
    点赞
  • 踩
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
iOS开发教程之常见的性能优化技巧
01-06
前言 性能问题的主要原因是什么，原因有相同的，也有不同的，但归根到底，不外乎内存使用、代码效率、合适的策略逻辑、代码质量、安装包体积这一类问题。 但从用户体验的角度去思考，当我们置身处地得把自己当做用户去玩一款应用时候，那么都会在意什么呢？假如正在玩一款手游，首先一定不希望玩着玩着突然闪退，然后就是不希望卡顿，其次就是耗电和耗流量不希望太严重，最后就是安装包希望能小一点。简单归类如下： 快：使用时避免出现卡顿，响应速度快，减少用户等待的时间，满足用户期望。 稳：不要在用户使用过程中崩溃和无响应。 省：节省流量和耗电，减少用户使用成本，避免使用时导致手机发烫。 小：安装包小可以降低用户的安装
iOS常见的崩溃让你更轻松找到常见问题
04-25
iOS常见的崩溃让你更轻松找到常见问题
解决iOS中常见的几种Crash1
08-03
1.数组越界，nil值初始化导致的崩溃 2.对字典插nil值，或者读取NSNULL导致的崩溃 3.字符串的截取越界导致的崩溃 4.doesNotRecogniz
iOS Crash防护
07-09
iOS Crash防护内容涉及 NSArray/NSMutableArray、NSDictionary/NSMutableDictionary、NSString/NSMutableString、Unrecognized Selector、KVO、KVC 、野指针定位、内存泄漏/循环引用；主要是对常见易错的地方进行容错处理，避免崩溃，并保存出错时的函数调用栈，以方便快速定位代码，主要是利用的runtime和fishhook知识。GitHub：https://github.com/wsl2ls/iOS_TipsiOS的一些示例，持续更新中：1、AVFoundation 高仿微信相机拍摄和编辑 2、AVFoundation 人脸检测、实时滤镜、音视频编解码、GPUImage框架的使用等音视频相关内容 3、OpenGLES 4、LeetCode算法练习 5、iOS Crash防护 6、WKWebView相关的内容 等........
iOS开发 常见的崩溃闪退原因(12点)1
08-03
1. 字典的key或value为nil,字典的key只要为nil任何写法定会崩， 2. 数组越界 3. 内存溢出或泄露，分为下个 4. 遍历数组时，对数组进操作
app常见的崩溃类型
暖暖的博客
07-20 2417
app常见的崩溃类型及代码原因 1、java.lang.OutOfMemoryError：内存溢出 原因： ①内存中加载的数据量过于庞大，如一次从数据库取出过多数据； ②代码中存在死循环或循环产生过多重复的对象实体； 2、java.lang.NoSuchMethodError：方法引用错误 原因： ①方法调用错误 3、java.lang.RuntimeException: Unable to instantiate activity：无法实例化活动 原因： ①不能实例化 4、java.lang.NullPo
iOS常见崩溃以及总结
郭晓东的专栏
11-06 3452
【转载】作者：乳猪啸谷 链接：https://juejin.im/post/6844903688608153614 用户在使用App的过程中，经常遇到闪退的情况，体验不太好，本文尝试探索引发闪退的原因，以及在遇到crash的情况下，尽可能的保持程序运行，并及时上报错误。 一、crash类型 1.OC层面的crash 1.1 普通类型 NSInvalidArgumentException：非法参数异常，传入非法参数导致异常，nil参数比较常见。 NSRangeException：下标越界导致的异常
iOS- Exception异常处理
alexhua1444的博客
03-31 196
1.Exception 前言　　　　　　　　　　　　　　　 在iOS里对异常的处理及捕获，并没有其它语言里那么常见，相信很多iOS程序员都知道，更多的时候是对内存的的检测与分析，检测相关内存方面的问题。 而在app闪退并不是因为内存的时候，这时候我们完全可以将常见的一些异常捕获。 捕获后发送至服务器，并且友好提示用户错误，或则直接回滚到用户操作前，阻止应用程序的崩溃。 ...
iOS NSException异常处理
u013712343的博客
02-21 726
为什么使用NSException 在平常的开发过程中，由于代码不严谨或者没有对参数做校验处理会造成程序crash，所以需要去监控项目中的crash并及时解决。NSException是针对OC类异常捕获的一套机制。 如何使用NSException NSException的结构如下： @interface NSException : NSObject <NSCopying, NSSecureCoding> { @private NSString *name
iOS crash分类,Mach异常、Unix 信号和NSException 异常
gcs的博客
08-08 2059
前言 Crash的主要原因是你的应用收到了未处理的信号。 未处理信号可能来源于三个地方：kernel、其他进程、以及App本身。 因此，crash异常也分为三种： Mach异常：是指最底层的内核级异常。用户态的开发者可以直接通过Mach API设置thread，task，host的异常端口，来捕获Mach异常。 Unix信号：又称BSD 信号，如果开发者没有捕获Mach异常，则会被host层的方法ux_exception()将异常转换为对应的UNIX信号，并通过方法threadsignal()将信
iOS 异常捕捉及处理发送。ExceptionHandler.
07-27
iOS异常捕捉提示，发送邮件及写入异常日志。 提供 断言， 错误的具体位置（类名及行数）、所有异常报告内容、及异常报告文件路径接口。 并统一展示 异常日志 。
iOS中的崩溃类型
听榆大叔的专栏
03-13 5770
iOS中的崩溃类型        在这里了解一下XCode用来表示各种崩溃类型的术语，补充一些这方面的各知识。崩溃通常是指操作系统向正在运行的程序发送的信号，所以我们在查看崩溃日志时，常常看到如下错误摘要：Application received signal SIGSEGV。一般来说，常见的崩溃类型有以下几种：   1、        EXC_BAD_ACCESS 在访问一个已经释放的对
iOS 不同的崩溃类型
圣人男的博客
03-17 1234
用汇编语言编写的软件跟用脚本或标记语言编写的Web应用的差别在于，前者在出现问题时会崩溃，由于Web应用运行在浏览器环境中，所以Web应用很少会对内存的使用造成破坏或是导致浏览器崩溃。如果你以前使用的是高级开发语言，那么可能不太了解Xcode用来表示各种崩溃类型的术语。崩溃通畅是指操作系统向正在运行的程序发送的信号。 1.EXC_BAD_ACCESS      在访问一个已经释放的对象或向它发
iOS-APP崩溃分析
MOON_YZM的博客
10-27 1983
程序崩溃是宣判app死亡的直接因素，仔细看工程崩溃日志，会有一些相应的信号输出给我们，根据崩溃类型我们可以快速的思考到与其类型相对应的崩溃场景，那么都有哪些崩溃类型呢？又有哪些崩溃信号呢？
iOS的App的崩溃收集和类型解释 ObjC/C/Swift语言都可以拦截
VictorZhang
07-08 1255
在Unix系统中标准的6种信号： SIGABRT: 表示程序异常终止，英语单词即Signal Abort SIGFPE: 表示浮点数异常错误，英语单词即Signal Floating Point Exception SIGILL: 表示无效指令/操作，英语单词即Signal Illegal SIGINT: 表示交互式注意请求发送到了程序引起了中断，英语单词Signal Interrupt SIGSEGV: 表示无效的内存访问，英语单词是Segmentation Violation SIGTERM: 表示终
iOS崩溃crash大解析
热门推荐
努力，可能成功！放弃，注定失败！
04-15 1万+
前言 iOS崩溃是让iOS开发人员比较头痛的事情，app崩溃了，说明代码写的有问题，这时如何快速定位到崩溃的地方很重要。调试阶段是比较容易找到出问题的地方的，但是已经上线的app并分析崩溃报告就比较麻烦了。 之前我总是找到一个改一个，并靠别人测试重现来找出问题的地方，这样往往比较耗费时间。而且比较难找到原因的时候每次都是到网上找各种资源搜索，解决了之后也没有认真分析原因及收集，时间长了之后就会
iOS崩溃 捕获异常处理
warm的博客
05-18 9581
网上基本使用的都是同一个版本的异常捕获，我能了解到的关于signal异常捕获的方法也是通过这个版本。我在自己理解的基础上对于这个版本进行了一些修改，也添加了一些注释。下面贴出主要的代码。
ios memcpy 崩溃
最新发布
03-27
在iOS开发中，memcpy函数是用于内存拷贝的。它的原型如下： ```c void *memcpy(void *dest, const void *src, size_t n); ``` 该函数用于将源内存区域的内容复制到目标内存区域。其中，`dest`是目标内存区域的指针，`src`是源内存区域的指针，`n`是要复制的字节数。 当使用memcpy函数时，可能会出现崩溃的情况。以下是一些可能导致memcpy崩溃的常见原因： 1. 内存越界：如果源内存区域或目标内存区域的大小超过了实际分配的内存大小，就会导致内存越界，从而引发崩溃。 2. 空指针：如果源内存区域或目标内存区域的指针为空指针（NULL），则会导致崩溃。 3. 内存重叠：如果源内存区域与目标内存区域存在重叠，即它们指向同一块内存区域，就会导致未定义行为，可能引发崩溃。 为了避免memcpy函数崩溃，你可以注意以下几点： 1. 确保源内存区域和目标内存区域的大小正确，并且不会越界。 2. 确保源内存区域和目标内存区域的指针不为空。 3. 避免源内存区域与目标内存区域重叠。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值