zoukankan      html  css  js  c++  java
  • 命令行工具解析Crash文件,dSYM文件进行符号化

    备份
     
    文/爱掏蜂窝的熊(简书作者)
    原文链接:http://www.jianshu.com/p/0b6f5148dab8
    著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。

    在日常开发中,app难免会发生崩溃。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。

    获取崩溃信息方式

    在iOS中获取崩溃信息的方式有很多,比较常见的是使用友盟、云测、百度等第三方分析工具,或者自己收集崩溃信息并上传公司服务器。
    下面列举一些我们常用的崩溃分析方式:

    • 使用友盟、云测、百度等第三方崩溃统计工具。
    • 自己实现应用内崩溃收集,并上传服务器。
    • Xcode-Devices中直接查看某个设备的崩溃信息。
    • 使用苹果提供的Crash崩溃收集服务。(少用)

    收集崩溃信息

    苹果给我们提供了异常处理的类,NSException类。这个类可以创建一个异常对象,也可以通过这个类获取一个异常对象。

    这个类中我们最常用的还是一个获取崩溃信息的C函数,我们可以通过这个函数在程序发生异常的时候收集这个异常。

    // 将系统提供的获取崩溃信息函数写在这个方法中,以保证在程序开始运行就具有获取崩溃信息的功能
      - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
         // 将下面C函数的函数地址当做参数
         NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);
         return YES;
      }
      // 设置一个C函数,用来接收崩溃信息
      void UncaughtExceptionHandler(NSException *exception){
          // 可以通过exception对象获取一些崩溃信息,我们就是通过这些崩溃信息来进行解析的,例如下面的symbols数组就是我们的崩溃堆栈。
          NSArray *symbols = [exception callStackSymbols];
          NSString *reason = [exception reason];
          NSString *name = [exception name];
      }

    我们也可以通过下面方法获取崩溃统计的函数指针:

     NSUncaughtExceptionHandler *handler = NSGetUncaughtExceptionHandler();

    dSYM 符号集

    • 符号集是我们对ipa文件进行打包之后,和.app文件同级的后缀名为.dSYM的文件,这个文件必须使用Xcode进行打包才有。
    • 每一个.dSYM文件都有一个UUID,和.app文件中的UUID对应,代表着是一个应用。而.dSYM文件中每一条崩溃信息也有一个单独的UUID,用来和程序的UUID进行校对。
    • 我们如果不使用.dSYM文件获取到的崩溃信息都是不准确的。
    • 符号集中存储着文件名、方法名、行号的信息,是和可执行文件的16进制函数地址对应的,通过分析崩溃的.Crash文件可以准确知道具体的崩溃信息。

    我们每次Archive一个包之后,都会随之生成一个dSYM文件。每次发布一个版本,我们都需要备份这个文件,以方便以后的调试。进行崩溃信息符号化的时候,必须使用当前应用打包的电脑所生成的dSYM文件,其他电脑生成的文件可能会导致分析不准确的问题。


    Archive.png

    当程序崩溃的时候,我们可以获得到崩溃的错误堆栈,但是这个错误堆栈都是0x开头的16进制地址,需要我们使用Xcode自带的symbolicatecrash工具来将.Crash和.dSYM文件进行符号化,就可以得到详细崩溃的信息。

    崩溃分析

    • 命令行解析Crash文件

    通过Mac自带的命令行工具解析Crash文件需要具备三个文件

    • symbolicatecrash,Xcode自带的崩溃分析工具,使用这个工具可以更精确的定位崩溃所在的位置,将0x开头的地址替换为响应的代码和具体行数。
    • 我们打包时产生的dSYM文件。
    • 崩溃时产生的Crash文件,例如:*.crash。

    我在解析崩溃信息的时候,首先在桌面上建立一个Crash文件夹,然后将.Crash、.dSYM、symbolicatecrash放在这个文件夹中,这样进入这个文件夹下,直接一行命令就解决了。

    symbolicatecrash我们可以在下面路径下可以找到,我用的是Xcode7,其他版本Xcode路径不一样,请自行Google。

    /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

    选中archive的版本右击,选择Show in Finder就可以选中archived 文件然后显示包内容,就可以找到dSYM文件了。


    dsym文件位置.png

    将.Crash、.dSYM、symbolicatecrash三个文件都放在我们在桌面建立的Crash文件夹中。


    crash.png

    进行解析的工作

    开启命令行工具,进入崩溃文件夹crash中

    cd /Users/自己MacPro上的名字/Desktop/崩溃文件夹crash

    使用命令解析Crash文件,*号指的是具体的文件名

    ./symbolicatecrash ./*.crash ./*.app.dSYM > symbol.crash

    如果上面命令不成功,使用命令检查一下环境变量

    xcode-select -print-path

    返回结果:

    /Applications/Xcode.app/Contents/Developer/

    如果不是上面的结果,需要使用下面命令设置一下导出的环境变量,然后重复上面解析的操作。(这一步很重要)

    export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer

    解析完成后会生成一个新的.Crash文件,这个文件中就是崩溃详细信息。图中红色标注的部分就是我们代码崩溃的部分。


    result.png


    注意,以下情况不会有崩溃信息产生:

    • 内存访问错误(不是野指针错误)
    • 低内存,当程序内存使用过多会造成系统低内存的问题,系统会将程序内存回收
    • 因为某种原因触发看门狗机制

    通过Xcode查看设备崩溃信息

    除了上面的系统分析工具来进行分析,如果是我们自己直接使用手机连接崩溃或者崩溃之后连接手机,选择window-> devices -> 选择自己的手机 -> view device logs 就可以查看我们的崩溃信息了。


    deviceLog.png

    只要手机上的应用是这台电脑安装打包的,这样的崩溃信息系统已经为我们符号化好了,我们只需要进去之后等一会就行(不要相信这里面的进度刷新,并不准确),如果还是没有符号化完毕 ,我们选择文件,然后右击选择Re-Sysbomlicate就可以。

    如果是使用其他电脑进行的打包,我们可以在这里面将Crash文件导出,自己通过命令行的方式进行解析。

  • 相关阅读:
    jquery 序列化form表单
    nginx for windows 安装
    nodejs idea 创建项目 (一)
    spring 配置 shiro rememberMe
    idea 2018 解决 双击shift 弹出 search everywhere 搜索框的方法
    redis 在windows 集群
    spring IOC控制反转和DI依赖注入
    redis 的安装
    shiro 通过jdbc连接数据库
    handlebars的用法
  • 原文地址:https://www.cnblogs.com/walkerwang/p/5287580.html
Copyright © 2011-2022 走看看