iOS开发之Crash分析,以及收集

一  先谈谈iOS的Crash收集方式:

     1. APP 发生crash,用户手机手机上肯定会有crash纪录,当然删除了该app,或是删了再装 crash纪录还是没了。

     2. 如果用户设置-隐私  同意的话,你的crash日志会发送到App store,你可以去账号上去查看crash日志 。(PS:但是,这个要用户自己同意,大部分人选的是不同意,我也选的不同意。可能你的账号上根本没有任何crash纪录,这不代表你的app 没有crash过。)

     3.第三方日志统计平台,国外的比如CrashlyticsHockeyapp,国内的也有 友盟Bugly 等等。

     4.当然也可以自己收集,开源项目很多,如 KSCrashplcrashreporterCrashKit 等。(PS:小公司的话,用用第三方的省心点。但是对安全性高的,并且有人力有时间情况下,还是自己实现收集吧,阿里 京东 这些公司肯定不会用 3.xxx  ,都是有自己的收集服务。腾讯肯定用自家的Bugly )

     现在聊聊选用方式:

     1.大公司的话,老老实实 自己 实现收集。

     2.中小公司的话如果是金融类或是涉及个人资料比较多的,并且用户量特别巨大的,建议 也是老老实实自己收集。

     3.如果你说我是金融类的,目前/以后 用户不一定多,自己也没时间 人力搞,那你就用国外的第三方。(PS:个人见解是,你的那点数据对于国外的平台,人家不是很care,相对安全点。但是,用国内的第三方的话,不是说国内做的不好,而是更容易暴露 你的app 什么什么问题。)

     4.中小公司涉及用户安全不是很多的app,以及游戏,可以考虑使用第三方 ,  友盟 或是 Bugly 。

二   选择友盟好还是Bugly好?

     1.友盟很早就出了,数据统计,推送,crash统计,分享,IM 等 服务很多,也很全。小公司也用的多。(我之前有2个项目都用了友盟 )

     2.Bugly ,看着骚气的名字还以为是国外的第三方,其实是大企鹅出的,我记得刚出来时间不是很长,但是 腾讯出品,必属精品 !腾讯产品,值得信耐! 打2句骚气的广告,因为最近要去腾讯面试,先奶一口。(ps:有一个项目用了Bugly!腾讯的信鸽推送我感觉比  极光 这些好多了。当年有对几个平台测试分析,遗憾的是 没有纪录下来!)

     我个人推荐使用Bugly,腾讯自己的产品也都在用,Bugly定期也有分享文章,都是干货,大家可以去搜搜。

三  谈谈我之前处理一个crash 的经验,仅做参考

     去年某天,人事跟我讲他在 app store 下载的 我们自己的app crash了。我当时就想,老子写的app 竟然会crash?竟然会crash?

     1. 我然后问了,哪个界面什么操作导致的?可以复现吗? 得到的结果是,在就诊人列表,然后在点击 添加 就诊人按钮的时候 GG的。另外,不是必现的。

     2. 我首先跑去 appstore 看下日志统计,对 一个 纪录都没。(这就是要自己实现或是借助第三方的原因。)

     3. 让测试 用不同机型 跟测。(测试复现率,然而n轮没有再次crash,为什么让测试继续测,主要是统计下复现率,另外测试的时候多点击下其他界面,有可能是其他页面有内存泄漏,刚好在这个界面时候出了问题,估测下受潜在影响的用户)

     4. 我拿了那crash 的机子 ,导出了crash日志到 xcode ,点开日志 并没有直观的显示哪个地方crash。

     5. 我看了下版本,crash 的 是  上个 小版本,目前线上的 这一块 都有 重写过,(git还原到上个版本)检测下代码也没啥问题。

然后只能通过crash和 .app 分析:

1. 建议 桌面 建 个文件夹  appxx  ,然后 将那个闪退 对应的 包  xxx.app 放入  appxx文件夹

2. 打开终端cd命令,进入该文件夹

3.在命令行输入“dwarfdump --uuid XXX.app/XXX”

4.在终端中输入以下命令“atos -o XXX.app/XXX -arch arm64 0x00000001006544f8 ”

“0x00000001006544f8” 这个地址是 

查看日志搜索“Triggered by Thread”:得到“Triggered by Thread:  0”,我们知道是0号线程闪退,找到0号线程得到如下:
Thread 0 Crashed:
0   libsystem_kernel.dylib         0x00000001833114bc mach_msg_trap + 8
1   libsystem_kernel.dylib         0x0000000183311338 mach_msg + 72
2   CoreFoundation                 0x0000000183740ac0 __CFRunLoopServiceMachPort + 196
3   CoreFoundation                 0x000000018373e7c4 __CFRunLoopRun + 1032
4   CoreFoundation                 0x000000018366d680 CFRunLoopRunSpecific + 384
5   GraphicsServices               0x0000000184b7c088 GSEventRunModal + 180
6   UIKit                          0x00000001884e4d90 UIApplicationMain + 204
7   XXX                      0x00000001006544f8 0x10009c000 + 5997816
8   libdyld.dylib                  0x000000018320e8b8 start + 4
XXX:就是你的XXX.app的名称,找到他的第一个地址,这个地址就是要输入的地址,如果存在多个地址,那么直接在后面追加。

最后显示,是因为友盟统计  的时候 报了错,第一时间跟友盟技术客服沟通,然后他们有记录下,承诺下个版本改进。然后我有查询了一下,使用友盟确实有极小极小的奔溃率,我们app也不是第一个。当然在可接受范围内。以上的crash分析 只是当时那个阶段的解决方式,当然也有更合适的定位方案。

最后结论: 第三方也不要用太多,能自己实现的还是自己实现。

原文地址:https://www.cnblogs.com/qiyer/p/6178976.html