在iOS开发中,bug从来都叫人尴尬又头秃,bug中又以线上崩溃最为致命。本地尚且能相视一笑而后猥琐排查,如果线上应用崩溃,就需要考验职业素养了。
在下的经验是做好实名被喷的准备,但面上一定要稳如老狗,要知道应用的崩溃信息是什么,从而获取应用的崩溃信息,找到问题点,尽可能不露痕迹的把这个锅甩出去。
常见收集用户使用时出现的崩溃信息方式有三种(新版iTunes Connect已经不能查看崩溃日志了)
利用Xcode导出相关的崩溃信息
直接导出错误日志适用于能复现闪退的场景,将手机连接到Mac,选择Xcode->Windows->Device and Simulator,点击View Device Logs,会看到很多Log,其中Type为Crash的就是崩溃的Log,如下图:
使用第三方SDK
如鹅厂的Bugly、友盟、KSCrash 等
Bugly首先需要注册账号,创建应用,创建成功之后会获取Appid 和 Appkey
接下来在测试项目中初始化SDK并人为的制造一个崩溃(哈哈哈哈哈哈哈写bug我可太有经验了)
需要注意的是,debug模式下无法收集异常,需要改为Release
刷新平台,很快就能看到收集的异常,这个就很优秀了,点个赞哇~
友盟集成前同样需要在平台注册账号,创建应用,获取 Appkey
接下来在测试项目中初始化SDK,由于收集app使用过程中产生的Crash信息,统计SDK默认是开启Crash收集机制的,所以我们就直接初始化统计SDK
同样是测试一个闪退,能看到收集到的错误列表。友盟有个问题是错误统计并不及时,这个就比较头疼。同学们需要注意检查是否有集成其他第三方错误统计SDK,或自己获取错误信息的方法,如有此情况,则U-App无法统计到错误信息。
到这里基本能满足一般的日志收集需求,但是有时候美丽而迷人的产品大大可能会觉得为什么我们要把自己的信息放到别人的服务上,这样真的好吗?你们就不能优化一下吗??!!!
我可以,我当然可以,成年的社畜怎么能说自己不行!
我们来康康KSCrash吧!KSCrash集成同样可以选择自动集成或者手动集成,一般就直接引入了
KSCrash主要提供了多种安装收集方式:
KSCrashInstallationStandard(崩溃日志发到服务器)
KSCrashInstallationHockey(隐式收集)
KSCrashInstallationEmail(将崩溃日志发到邮箱)
KSCrashInstallationConsole(输出崩溃日志)
更多信息有兴趣的小宝贝可以到github查看
https://github.com/kstenerud/KSCrash
通过KSCrash类来设置各项属性
事情到这里已经很好了对不对,但是如果你的产品大大也和我的一样希望获取Crash日志然后转成Apple format 作为参数之一再自己实现上传Crash文件,那么可以来看看KSCrashReportFilterAppleFmt这个类
到这里,就得到了Apple format 的Crash文件,接下来你可以对它做任何处理,想怎么传就怎么传!
通过iOS自带的函数
函数NSSetUncaughtExceptionHandler
程序启动的时候添加 NSSetUncaughtExceptionHandler,在程序发生异常的时候可以捕捉到异常信息,再进行适当的处理反馈,需要注意的是自定义NSSetUncaughtExceptionHandler可能会会导致第三方监听失效哦~
以上是常用的几种收集日志的方式。
最理想的情况当然是手机连接直接导出日志,但实际开发过程中,尤其是应用发布之后,这种好事大多数时候只是一个理想值。
使用大厂的成品SDK也是一个不错的收集方式,集成方便且资料齐全,日志数据也都清晰明了,但是缺点是将数据放到三方平台,可能会有安全性问题。
相比之下集成开源SDK,将Crash日志传到自家的服务则可以避免这个问题,但是缺陷也很明显,这种方式不会像平台化的产品给到统计趋势分析分类。
所以具体实战过程中,要根据需求和侧重点进行取舍。
欢迎大家一起探讨!
好啦,就到这里啦,等产品妹子再揍我的时候,我再来和大家侃侃日志解析,爱你们呦~啵~~~~~~
关于作者:李二,普元移动端开发工程师,目前参与Mobile 8.0项目的开发。互联网技术猥琐发育人员,主攻移动端开发。
关于EAWorld:微服务,DevOps,数据治理,移动架构原创技术分享。长按二维码关注!
在看点这里