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

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

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

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

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

     4.当然也可以自己收集，开源项目很多，如 KSCrash，plcrashreporter，CrashKit 等。（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分析 只是当时那个阶段的解决方式，当然也有更合适的定位方案。

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