其实,对于做移动 APP 开发的同学来说,质量和体验都是同等重要的。一个 APP 应用如果经常「闪退」,是产品质量很差的一个体现,那么用户体验就更不用再提了。
上面是笔者截取的国外一家公司对用户行为分析漫画的一个片段,从图中可以看到,有 80%的用户会因为网络错误和崩溃抛弃这个 APP,有 86% 的用户,如果体验太差,绝对不会第二次使用该 APP。所以开发一个优秀的 APP,性能即生死,一定尽量杜绝「闪退」。
诚然,iOS 上的 APP 闪退有各种各样的原因,像三方库不兼容、响应超时、内存不足都有可能造成 Crash。但更多情况下可能是 APP 程序自身的运行逻辑存在问题。比如调用用了 Objective-C 对象根本不支持的方法(发送消息),非法内存访问,数组越界,参数不符合要求等。
这些问题在调试阶段,我们很容易通过给 Xcode 打断点来进行调试, 但对于已发布的 APP,如果想重现并利用上述办法来解决,恐怕会比较费时费事。
最有帮助最直接的办法就是根据出现问题时的闪退日志,分析和判断 Crash 的原因,快速准确的定位和解决。
在 iOS 上运行的 APP 出现 Crash 的时候,通常会生成一个 Crash log,记载问题发生时的具体状况。开发者可以在 iTunes Connect 中特定 APP下找到收集上来的 Crash log。也可以连接电脑,去本地目录找 Mac :~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>
这个时候你会发现一大堆的.crash 文件和.ips 文件。
不过笔者还是推荐第三种,通过 Xcode 获取到崩溃日志,方法是 Xcode->Window->Devices
,想必很多开发者和笔者一样,也都是用的是这个方法。
通过上面三种方法收集到了 Crash log,但用文本编辑器打开文件是一堆十六进制的内存地址,你会郁闷的发现压根看不懂。这又是另一个话题了。
Crash log 里面包含了 Crash 发生的 APP、运行软硬件环境、发生时间、错误类型、方法调用异常栈、各线程状态、寄存器和内存信息。
而其中对我们开发人员来说意义最为重大的,可能就是异常线程的调用栈. 可惜有些时候,这关键的信息竟然全是 16 进制的数据,所以我们很难看懂。比如:
1CrashDebugInfoTest 0x1000c2b90 0x1000bc000 + 27536
那么要从十六进制的地址码,得到我们代码中对应的方法调用,就需要结合调试信息对 Crash log 进行符号化。笔者查看了很多文档,能符号化 Crash log 无非就 3 种方法: 1. 使用开发工具库中自带的 symbolicatecrash 2. 使用 atos 3. 使用 dwarfdump
前两种方法方法,都简单的试了一下,但并没有觉得有多好用,atos 要想把十六进制的地址翻译为符号,需要每次给 APP 打包时生成的 dSYM 文件,个人觉得很是麻烦。而 symbolicatecrash 也是如此,每次都需要在终端输入一些命令,也是劳心费神!
在这个当下这个这个注重效率的时代,笔者不认为手动的去做这些事情是好的。如果能借助一些工具去解决事情,那就再好不过了。仔细找了找,国内外还真有一些三方工具能解决这个问题。
国外的比如 New Relic,还有国内 OneAPM 的 Mobile Insight 。
他们不仅解析了 Crash log,而且能将你所有的 Crash 进行分类,做成可视化的,不仅能直观的看到造成你 APP 崩溃的代码行,而且帮你统计出这个崩溃是在哪个iOS 系统和机型下发生的,这个崩溃影响了多少你的终端用户,堆栈信息也一目了然。
起初,笔者也不确定他是否能将所有崩溃类型都能抓到,于是在 Github 上下载了CrashProbe-master,一个崩溃类型相对比较全的开源 Demo 亲自测了一下,像常见的像无效内存地址,空指针未初始化指针,栈溢出造成的 SEGV:(Segmentation Violation)
类型和线程异常造成的 EXC_BAD_INSTRUCTION
类型的崩溃等十几种崩溃都抓取到了 ,感觉还是很惊讶。立马和身边一块做项目的安卓同事念叨了一下,他导入安卓的SDK 之后,简单的模拟了几个 Crash,神奇的是,竟然还有崩溃轨迹,就是在发生崩溃之前你都进行了什么操作,都可以看的到。当时,笔者心里就有点不平衡了,为啥 iOS 就没有,去问了他们的技术支持,说是下一期就能加上,很是期待啊! 备注:本文已经得到原作者的同意,授权 OneAPM 技术博客进行转载
OneAPM Mobile Insight 以真实用户体验为度量标准进行 Crash 分析,监控网络请求及网络错误,提升用户留存。访问 OneAPM 官方网站 感受更多应用性能优化体验,想阅读更多技术文章,请访问 OneAPM 官方技术博客 。