频道栏目
首页 > 程序开发 > 移动开发 > IOS > 正文
iOS应用的crash日志的分析基础
2014-02-10 15:29:52         来源:JasonLee的专栏  
收藏   我要投稿
Outline
如何获得crash日志
如何解析crash日志
如何分析crash日志
1. iOS策略相关
2. 常见错误标识
3. 代码bug


一、如何获得crash日志

当一个iOS应用程序崩溃时,系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息,通常包含着每个执行线程的栈调用信息(低内存闪退日志例外),对于开发人员定位问题很有帮助。

如果设备就在身边,可以连接设备,打开Xcode - Window - Organizer,在左侧面板中选择Device Logs(可以选择具体设备的Device Logs或者Library下所有设备的Device Logs),然后根据时间排序查看设备上的crash日志。这是开发、测试阶段最经常采用的方式。

如果应用程序已经提交到App Store发布,用户已经安装使用了,那么开发者可以通过iTunes Connect(Manage Your Applications - View Details - Crash Reports)获取用户的crash日志。不过这并不是100%有效的,而且大多数开发者并不依赖于此,因为这需要用户设备同意上传相关信息,详情可参见iOS: Providing Apple with diagnostics and usage information摘要。

考虑到并不是所有iPhone用户都允许自动发送诊断报告(crash日志),而且对于部分提交到Apple得crash日志,开发者还需要手动去拉取,然后找到对应的符号文件进行解析——这是一件很繁琐的事情。所以实际项目开发中,通常接入现有的crash收集工具(参考1参考2),或者自己编写一个进行自动化收集、解析和统计汇总。


二、如何解析crash日志

当获得一份crash日志时,我们需要将初始展示的十六进制地址等原始信息映射为源代码级别的方法名称和代码行数,使其对开发人员可读。这个过程称为符号化解析。要成功地符号化解析一份crash日志,我们需要有对应的应用程序二进制文件以及符号(.dSYM)文件。

如果处于开发调试阶段,通常Xcode都能匹配到crash日志对应的二进制文件和符号文件,所以能够帮我们自动解析。

如果处于测试阶段,测试人员已经安装了不同的版本(比如alpha、beta版本),那么需要保存好对应版本的二进制文件和符号文件,以便在应用程序崩溃时对crash日志进行解析。对于这种场景下产生的crash日志,只需要将.crash文件、.app文件和.dSYM文件三者放在同一个目录下,然后将.crash文件拖放到Xcode - Window - Organizer中左侧面板Library下的Device Logs中,即可进行解析。

如果要提交发布,那么我们通常会先执行Clean,再Build,最后通过Product - Archive来打包。这样,Xcode会将二进制文件和符号文件归档在一起,可以通过Organizer中的Archives进行浏览。

这里是一份关于如何解析crash日志的讨论:https://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports


三、如何分析crash日志

在分析一份crash日志之前,如果开发人员对于常见的错误类型有所了解,那定是极好的。
crash日志的产生来源于两种问题:违反iOS策略被干掉,以及自身的代码bug。

1. iOS策略

1.1 低内存闪退
前面提到大多数crash日志都包含着执行线程的栈调用信息,但是低内存闪退日志除外,这里就先看看低内存闪退日志是什么样的。
我们使用Xcode 5和iOS 7的设备模拟一次低内存闪退,然后通过Organizer查看产生的crash日志,可以发现Process和Type都为Unknown:

\

而具体的日志内容如下:

vc/U57XEsOaxvtbQv8nS1NTaxLPQqb34s8y688Pmv7S1vaGwamV0dGlzb25lZKGx19bR+aOsse3D99Xi0Km9+LPMyrnTw7n9tuDE2rTmsbvW1da5wcujrLb4z9bU2s7Sw8e/tLW9tcTKx6Gwdm0tcGFnZXNob3J0YWdlobHX1tH5oaM8YnI+Cjxicj4KtbFpT1O87LLitb3E2rTmuf21zcqxo6zL/KOotcRWTc+1zbOjqbvht6Kz9rXNxNq05r6vuObNqNaqo6yzosrUu9jK1dK70KnE2rTmo7vI57n7x+m/9sO709C1w7W91+O5u7XEuMTJxqOsaU9Tu+HW1da5uvPMqNOm08PS1LvYytW4/LbgxNq05qO71+6686OsyOe5+8TatOa7ucrHsrvX46OsxMfDtNX91NrUy9DQtcTTptPDv8nE3LvhsbvW1da5tfShozxicj4Ky/nS1KOsztLDx7XE06bTw9OmuMO6z8DttdjP7NOmz7XNs8XXs/bAtLXEtc3E2rTmvq+45s2o1qqjrLbU0rvQqbu6tObK/b7dus2/ydbY0MK0tL2otcS21M/zvfjQ0MrNt8WjrM2syrHSqrHcw+Kz9s/WxNq05tC5wra1yM7KzOKhozxicj4KPGJyPgq1zcTatObJwc3LysfTyWlPU7LfwtS+9rao1tXWudOm08OzzNDy1MvQ0LXEo6zNrNH5u/nT2mlPU7LfwtS1xLu509BXYXRjaGRvZ7OsyrG6zdPDu6fHv9bGzcuz9qGjPGJyPgo8YnI+CjxzdHJvbmc+MS4yIFdhdGNoZG9ns6zKsTwvc3Ryb25nPjxicj4KQXBwbGW1xGlPUyBEZXZlbG9wZXIgTGlicmFyec341b7Jz6OsPHU+UUExNjkzPC91Ps7EtbXW0MPoyvbBy1dhdGNoZG9nu/rWxqOssPzAqMn60Kezob6wus2x7c/WoaPI57n7ztLDx7XE06bTw7PM0PK21NK70KnM2LaotcRVScrCvP6jqLHIyOfG9LavoaK50sbwoaK71ri0oaK94cr4o6nP7NOmsru8sMqxo6xXYXRjaGRvZ7vhsNHO0sPHtcTTptPDs8zQ8rjJtfSjrLKiyfqzydK7t93P7NOmtcRjcmFzaLGouOahozxicj4KPGJyPgrV4rfdY3Jhc2ixqLjmtcTT0Mik1q60ptTa09rS7LOjtPrC66O6obAweDhiYWRmMDBkobGjrLy0obBhdGUgYmFkIGZvb2ShsaGjPGJyPgrI57n7y7XM2LaotcRVScrCvP6xyL3Ps+nP86OsxMfDtNPDtPrC68C01rG908Poyva1xLuwo6y21NOmtcS+zcrHo6i0tL2o0ru49rmks8zKsVhjb2Rl19S2r8n6s8m1xKOpVUlBcHBsaWNhdGlvbkRlbGVnYXRltcS8uLj2t723qKO6PGJyPgo8YnI+CjxpbWcgc3JjPQ=="/uploadfile/Collfiles/20140210/20140210133630184.jpg" alt="\">

所以当遇到Watchdog日志时,可以检查下上图几个方法是否有比较重的阻塞UI的动作。

QA1693举的例子是在主线程进行同步网络请求。如果我们是在公司的Wifi环境下使用则一切顺利,但当应用程序发布出去面向很大范围的用户,在各种网络环境下运行,则不可避免地会出现一片Watchdog超时报告。
另一种可能出现问题的场景就是数据量比较大的情况下进行的数据库版本迁移(同样是在主线程上),这也是促使我写这篇总结的一个直接因素。

1.3 用户强制退出

一看到“用户强制退出”,首先可能想到的双击Home键,然后关闭应用程序。不过这种场景是不会产生crash日志的,因为双击Home键后,所有的应用程序都处于后台状态,而iOS随时都有可能关闭后台进程,所以这种场景没有crash日志。

另一种场景是用户同时按住电源键和Home键,让iPhone重启。这种场景会产生日志(仅验证过一次),但并不针对特定应用程序。

这里指的“用户强制退出”场景,是稍微比较复杂点的操作:先按住电源键,直到出现“滑动关机”的界面时,再按住Home键,这时候当前应用程序会被终止掉,并且产生一份相应事件的crash日志。

\

通常,用户应该是遇到应用程序卡死,并且影响到了iOS响应,才会进行这样的操作——不过感觉这操作好高级,所以这样的crash日志应该比较少见。

2. 常见错误标识

2.1 Exception codes
上面“用户强制退出”的crash日志中的Exception Codes是“0xdeadfa11”,再上面“Watchdog超时”的crash日志中的Exception Codes是“0x8badf00d”,这些都是特有的Exception codes。
根据官方文档描述,至少有以下几种特定异常代码:

0x8badf00d错误码:Watchdog超时,意为“ate bad food”。

0xdeadfa11错误码:用户强制退出,意为“dead fall”。

0xbaaaaaad错误码:用户按住Home键和音量键,获取当前内存状态,不代表崩溃。

Android),如果有兴趣到阿里巴巴(杭州)工作,可以联系我,或者直接把简历发到 siqin.ljp(at)taobao.com。

点击复制链接 与好友分享!回本站首页
相关TAG标签 基础 日志
上一篇:xcode之iOS simulator
下一篇:ios7版 30天精通iPhone手机编程 第18天 音乐播放器
相关文章
图文推荐
文章
推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站