在分析一份crash日志之前，如果开发人员对于常见的错误类型有所了解，那定是极好的。crash日志的产生来源于两种问题：违反iOS策略被干掉，以及自身的代码bug。
1.违反iOS策略
-
内存报警闪退
当iOS检测到内存过低时，它的VM系统会发出低内存警告通知，尝试回收一些内存；如果情况没有得到足够的改善，iOS会终止后台应用以回收更多内存；最后，如果内存还是不足，那么正在运行的应用可能会被终止掉。在Debug模式下，可以主动将客户端执行的动作逻辑写入一个log文件中，这样程序童鞋可以将内存预警的逻辑写入该log文件，当发生如下截图中的内存报警时，就是提醒当前客户端性能内存吃紧，可以通过Instruments工具中的Allocations 和 Leaks模块库来发现内存分配问题和内存泄漏问题。
我们使用Xcode 5和iOS 7的设备模拟一次低内存闪退，然后通过Organizer查看产生的crash日志，可以发现Process和Type都为Unknown：
具体内容
第一部分是崩溃信息，包括识别标识、软硬件信息和时间信息等。
第二部分是内存页分配信息，以及当前占用内存最多的进程，上图中为crashTypeDemo。
第三部分是具体的进程列表，描述着每个进程使用内存的情况以及当前状态。在较早的版本中可以在某些进程后面看到“jettisoned”字样，表明这些进程使用过多内存被终止了，而现在我们看到的是“vm-pageshortage”字样。
-
Watchdog响应超时
当应用程序对一些特定的事件（比如启动、挂起、恢复、结束）响应不及时，苹果的Watchdog机制会把应用程序干掉，并生成一份相应的crash日志。这些事件与下列UIApplicationDelegate方法相对应，当遇到Watchdog日志时，可以检查上图中的几个方法是否有比较重的阻塞UI的动作。
-
用户强制退出
一看到“用户强制退出”，首先可能想到的双击Home键，然后关闭应用程序。不过这种场景一般是不会产生crash日志的，因为双击Home键后，所有的应用程序都处于后台状态，而iOS随时都有可能关闭后台进程，当应用阻塞界面并停止响应时这种场景才会产生crash日志。这里指的“用户强制退出”场景，是稍微比较复杂点的操作：先按住电源键，直到出现“滑动关机”的界面时，再按住Home键，这时候当前应用程序会被终止掉，并且产生一份相应事件的crash日志。
Paste_Image.png
2.应用逻辑的Bug
大多数闪退崩溃日志的产生都是因为应用中的Bug，这种Bug的错误种类有很多，比如
SEGV：（Segmentation Violation，段违例），无效内存地址，比如空指针，未初始化指针，栈溢出等；
SIGABRT：收到Abort信号，可能自身调用abort()或者收到外部发送过来的信号；
SIGBUS：总线错误。与SIGSEGV不同的是，SIGSEGV访问的是无效地址（比如虚存映射不到物理内存），而SIGBUS访问的是有效地址，但总线访问异常（比如地址对齐问题）；
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限； SIGFPE：Floating Point Error，数学计算相关问题（可能不限于浮点计算），比如除零操作；
SIGPIPE：管道另一端没有进程接手数据；
常见的崩溃原因基本都是代码逻辑问题或资源问题，比如数组越界，访问野指针或者资源不存在，或资源大小写错误等。需要稍微注意点的是多线程问题，当一时找不到解决思路时，不妨往多线程方面考虑下。
3. 常见错误标识** Exception codes**
- 0x8badf00d错误码：Watchdog超时，意为“ate bad food”。
- 0xdeadfa11错误码：用户强制退出，意为“dead fall”。
- 0xbaaaaaad错误码：用户按住Home键和音量键，获取当前内存状态，不代表崩溃。
- 0xbad22222错误码：VoIP应用（因为太频繁？）被iOS干掉。
- 0xc00010ff错误码：因为太烫了被干掉，意为“cool off”。
- 0xdead10cc错误码：因为在后台时仍然占据系统资源（比如通讯录）被干掉，意为“dead lock”。
网友评论