美文网首页
iOS 2017友盟错误统计及分析

iOS 2017友盟错误统计及分析

作者: MQ_Twist | 来源:发表于2017-09-05 13:57 被阅读636次

    我还以为你不会搜我呢~

    看完这文章后的你

    前言

    在app开发中,我坚信,总会有小伙伴会用到友盟统计的,我也是(废话)。但是在友盟的错误日志分析这块,小白用的话可能会有点小麻烦。最近有个小伙伴问我这点,于是我就整理一下,小白们参考,大神们绕行。

    Crash日志统计

    • 集成友盟SDK
      这点我就不再过多的赘述了,详细看 友盟集成文档
    • 收集Crash日志


      友盟上的文案

      这点友盟上说的很清楚,错误统计这个接口默认是开启的,只要你成功集成,它就会自动统计日志。如果你省事,啥都不做,那你就错了,至少你得有这点代码意思一下:

    #ifdef DEBUG
        [MobClick setCrashReportEnabled:NO];    //关闭错误统计
    #else
        [MobClick setCrashReportEnabled:YES];   //打开错误统计
    #endif
    

    最后,查看的地方,如下图

    查看Crash日志

    当你看到错误日志的时候,别急着高兴,因为还有坑等着你呢。

    Crash日志分析

    当你查看日志,点击某一个查看详情的时候,你会看到:

    错误详情

    乍一看,哦~原来是数组越界了啊,小case!仔细一想,卧槽,怎么改!在哪改!

    不着急,且看:

    日志分析方法(一)

    umcrashtool 解析友盟错误日志,怎么用?
    按照官方文档--2.2.3 错误分析工具的使用的方法,三步走。

    注意:友盟上的.csv要用Numbers打开,不然可能会有乱码。

    虽然只有三步,但是有的小伙伴可能走的并不是很悠然,不急,反手给你一个教学视频,有超清哦~

    到这,如果你已经成功了,那么恭喜你,下面的你可以选择性的不看了,如果没有成功,咱继续

    注:如果错误分析没有成功,请先确保对应的 xxx.dSYM 文件在 ~/Library/Developer/Xcode/ 或该路径的子目录下。(对于每一个产品发布时archive操作会将dsym文件存放到~/Library/Developer/Xcode/Archives路径下,因此建议保留该路径下的文件,以便后续用工具分析错误。)

    上面的是官方文档上的提示,我再补充一下。在你找到该路径情况下,你会看到

    找到对应的版本

    然后你要右键


    显示包内容

    在这个包里面你会看到有关自己app 的dsym文件,然后将对应的 xxx.dSYM 文件在 ~/Library/Developer/Xcode/ 或该路径的子目录下。

    注意:解析的时候要保证版本号一致。

    日志分析方法(二)

    用dsym解析工具

    查看 xx.app 文件的 UUID,terminal 中输入命令 :

    dwarfdump --uuid xx.app/xx (xx代表你的项目名)
    

    查看 xx.app.dSYM 文件的 UUID ,在 terminal 中输入命令:

     dwarfdump --uuid xx.app.dSYM 
    

    crash 文件内第一行 Incident Identifier 就是该 crash 文件的 UUID。
    工具呢,是一个大神写的,下载地址
    在使用的时候是这个样子的

    dsym工具 错误地址

    这种方法,解析有时会有一些出入,不过也能解决大部分问题。

    日志分析方法(三)

    个人觉得是最省事的方法。
    在友盟上查看错误详情的时候,点击app后面对应的堆栈地址

    点击堆栈地址

    打开terminal,把黑框内分号以前的完整复制,然后回车,再把分号以后的完整复制,然后回车,你就可以看到错误详情了。

    • 优点:很快很方便。
    • 缺点:不能像umcrashtool一样可以批量解析。

    日志分析方法(四)

    1、找到.dSYM文件,把xxx.app和.dSYM文件放到同一个目录,推荐把该目录放在桌面。
    xxx.app在分析方法(一)图“显示包内容”操作之后,在下图中

    xxx.app位置

    2、cd到这个目录。
    3、执行下面的代码

    xcrun atos -arch arm64 -o 'xxx.app/xxx' 0x0004af6f
    

    arm64是CPU架构,有的时候是armv7,这个在友盟crash最下面有,xxx是app的bundle名,0x0004af6f是错误的内存地址。

    日志分析方法(五)更新于2017-10-10

    最近的几个版本的包里面的.dsym的UUID和crash的UUID老是不一致,导致解析的有问题。为啥不一致?我给友盟的工作人员发了邮件,人家说,我在打包之后,没有立刻保存dsym文件,修改了代码后dsym文件的UUID会变化。用来用去还是觉得命令行最舒服。下面的是命令行的具体的用法:

    • 把错误版本的dsym文件(这个文件一定要是打包后就立刻保存下来的)放到某个文件夹,cd到这个文件夹。
    • dwarfdump --lookup 0xb86f7 -arch arm64 xxx.app.dSYM
      同样,0xb86f7是堆栈地址,arm64是CPU架构,xxx是Boundle名。

    后记

    有啥问题,可以留言,互相交流,共同进步。

    相关文章

      网友评论

          本文标题:iOS 2017友盟错误统计及分析

          本文链接:https://www.haomeiwen.com/subject/gusujxtx.html