美文网首页iOS备忘录
TN2151:崩溃报告

TN2151:崩溃报告

作者: 纵横而乐 | 来源:发表于2015-08-10 10:50 被阅读980次

    understanding and analyzing ios application crashreports

    这个TN涉及了与崩溃相关的 内存耗尽信息,堆栈信息 以及 异常编号 等信息 

    内存耗尽

    内存不足时,虚存系统需要app的协助释放部分内存,内存不足的通知会发送给所有正在运行的app。如果内存压力依然存在,系统会终止后台进程以缓解内存压力。如果释放的内存足够,你的app仍可以运行且不会有crash report产生。否则,app将被终止且产生crash report。

    low memory report与其他crash report不同在于没有应用线程的stack trace,每个进程的内存占用是由内存页数标识的,每页4K。且每个被 ios终止的进程名后面都会有一串字符 "(jettisoned)"。如果你的app名旁边有这个字串,则可以确认你的应用是因为内存占用过多而被终止的。否则则不是因为内存压力而崩溃的,这时应该寻找.crash文件。可以checkout WWDC2010 session的 Advanced Memory Analysis with Instruments

    需要注意的是,泄漏和分配工具并不会跟踪显存。你需要使用VM tracker工具(instruments Allocations template中)运行app以查看显存使用量。

    分析crash report

    符号化

    crash report 最有趣的部分是应用执行中止时应用的栈回溯信息,这与在调试器中停止执行时的栈trace类似但不同的是其中并未带符号信息(即函数方法名),你所看到的会是十六进制的地址和可执行代码,你需要将这些地址映射成符号,即源代码地址和行数。这个过程需要 上传到app store的二进制app文件及此文件对应的.dsym文件,文件需要完全匹配,否则符号化会不完全。使用 product->Archive命令可以将app与dsym文件打包到你的home/library/developer/xcode/archives目录下。

    如果上传app二进制包到 appstore的时候添加了Archive则此应用的crash可以导入 xcode organizer的crash reports tab中。如果要分析开发过程中的crash可能就只能在Devices中view device logs里面查看crash了

    异常码

    crash log中以 Exception Codes: + 一个或多个十六进制value 为标志的行,这行是特定于处理器的代号,用于辨识crash的进一步信息

    0xbaaaaaad: 当前log为整个系统的栈快照,并不是crash report文件(home+volume键可以取stack快照)

    0xbad22222: VoIP app 由于重启太频繁而被ios中止

    0x8badf00d:watchdog超时(大概是1分钟未向约定的数据空间写数据导致),比如app启动或者退出,或者响应系统事件 花费的时间太长。通常的原因一般是在主线程上做同步的网络操作,无论如何,耗时的操作应该从主线程中移除,以免阻塞主线程。

    0xc00010ff: app由于过热引发的系统事件而被系统中止。

    0xdead10cc: app由于在后台运行时hold on to 系统资源(比如地址簿数据库)

    0xdeadfa11: app 被用户强制中止。用户长按 开机键直到出现“滑动关机”,然后长按home按钮。(需要注意的是,从多任务托盘中移除暂停的app并不会产生crash文件,因为一旦app暂停,ios即可随时将它中止,所以不会有crash文件产生)

    相关文章

      网友评论

        本文标题:TN2151:崩溃报告

        本文链接:https://www.haomeiwen.com/subject/vgldqttx.html