iOS崩溃堆栈信息的符号化怎么用-创新互联

小编给大家分享一下iOS崩溃堆栈信息的符号化怎么用，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！

创新互联建站是一家集网站建设,宝兴企业网站建设,宝兴品牌网站建设,网站定制,宝兴网站建设报价,网络营销,网络优化,宝兴网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

对iOS崩溃符号化的使用和技巧：

一．场景

    当我们收集iOS的崩溃信息时，获取到的崩溃堆栈一般是如下的形式，全是十六进制的内存地址形式：

     

    这样的格式我们很难看出实际含义，无法定位问题代码，只有将它们转化为可读的形式才有意义：

     

    如上所示，我们一眼就能看明白，这次崩溃发生在ViewController.m文件的68行，对应的方法是rangeException。那么这样的符号化又是如何实现的呢？

    我们知道，开发者在使用Xcode开发调试App时，一旦遇到崩溃问题，开发者可以直接使用Xcode的调试器定位分析崩溃堆栈。但如果App发布上线，用户的手机发生了崩溃，我们就只能通过分析系统记录的崩溃日志来定位问题，在这份崩溃日志文件中，会指出App出错的函数内存地址，关键的问题，崩溃日志中只有地址，类似 0x2312e92f这种，这看起来岂不是相当头疼，那怎么办呢？

    幸好有dSYM文件的存在，它是帮助苦逼的码农有效定位bug问题的重要途径。崩溃堆栈里的函数地址可以借助dSYM文件来找到具体的文件名、函数名和行号信息的。实际上，在使用Xcode的Organizer查看崩溃日志时，就是根据本地存储的.dSYM文件进行了符号化的操作。

二．Xcode符号化工具

    Xcode本身也提供了几个工具来帮助开发者执行函数地址符号化的操作

    1、symbolicatecrash

    symbolicatecrash是一个将堆栈地址符号化的脚本，输入参数是苹果官方格式的崩溃日志及本地的.dSYM文件，
     执行方式如下：
    Symbolicatecrash + 崩溃日志 + APP对应的.dSYM文件 + > + 输出到的文件，
    但使用symbolicatecrash工具有很大的限制
    (1)只能分析官方格式的崩溃日志，需要从具体的设备中导出，获取和操作都不是很方便
    (2)符号化的结果也是没有具体的行号信息的，也经常会出现符号化失败的情况。
    实际上, Xcode的Organizer内置了symbolicatecrash工具，所以开发者才可以直接看到符号化的崩溃堆栈日志。

     2、atos

    更普遍的情况是，开发者能获取到错误堆栈信息，而使用atos工具就是把地址对应的具体符号信息找到。它是一个可以把地址转换为函数名（包括行号）的工具，
     执行方式如下：
    atos -o executable -arch architecture -l loadAddress address
    说明：
    loadAddress 表示函数的动态加载地址，对应崩溃地址堆栈中 + 号前面的地址，即0x00048000
address 表示运行时地址、对应崩溃地址堆栈中第一个地址，即0x0004fbed ，实际上，崩溃地址堆栈中+号前后的地址相加即是运行时地址，即0x00048000+ 31720= 0x0004fbed
    执行命令查询地址的符号，可以看到如下结果：
    -[ViewController rangeException:] (in xx)(ViewController.m:68)

三．堆栈符号化原理

    那么，如果我们自己来符号化堆栈，又该怎么实现呢？这里需要处理两种符号，包括用户符号和系统符号。

    1、用户堆栈的符号化

     符号化的依据来自dSYM文件， dSYM文件也是Mach-o格式，我们按照Mach-o格式一步一步解析即可。

    

    从图上我们可以大概的看出Mach-O可以分为3个部分
    (1)Header
    (2)Segment
    (3)section
    如图所示，header后面是segment，然后再跟着section，而一个segment是可以包含多个section的。
    我们把dSYM文件放入可视化工具:

    

    该dSYM文件包含armv7和arm64两种架构的符号表，我们只看armv7(arm64同理)，它偏移64，直接定位到64(0x00000040),这里就是上面的Mach Header信息

    
 
    跟我们符号表有关的两个地方，一是”LC_SYMTAB”, 二是“LC_SEGMENT(__DWARF)” -> “Section Header(__debug_line)”。

    LC_SYMTAB信息

     

     定位地址: 偏移4096 + 64(0x1040),得到函数符号信息模块”Symbols”,把函数符号解析出来，比如第一个函数: “-[DKDLicenseAgreeementModel isAuthorize]”对应的内存地址:模块地址+43856

     
 
    “__debug_line”模块

   这个模块里包含有代码文件行号信息，根据dwarf格式去一个一个解析
   首先定位到SEGMENT：LC_SEGMENT(__DWARF)，再定位到Section:__debug_line

    

    它的偏移值:4248608, 4248608+ 64 = 0x40D460，定位到“Section(__DWARF,__debug_line)”
    这里面就是具体的行号信息，根据dwarf格式去解析

    

    解析出来的结果如下:

    

    第一列是起始内存地址，第二列是结束内存地址，第三列是对应的函数名、文件名、行号信息，这样我们捕获到任意的崩溃信息后，都可以很轻松的还原了。
 
    上面解析出来的Object-C符号倒没什么问题，但如果是C++或者Swift的符号就还需要特殊处理

    Swift符号:

    Swift函数会进行命名重整(name mangling),所以从dSYM中解析出来的原始符号是不太直观的

      

    我们使用”swift-demangle”来还原:swift-demangle –simplified originName，结果如下:

      
 
     C++符号:

    C++函数也会进行命名重整(name mangling),所以从dSYM中解析出来的原始符号如下:

      

    我们使用”c++filt ”来还原: c++filt originName，结果如下:

      
 
     2、系统堆栈的符号化

     未解析形式:
     

    解析后:
     

    Apple没有提供系统库符号表的下载功能，我们可以通过真机来获取
    当把开发机连到MAC时，会首先把该机型的符号拷贝到电脑上。

     

    “Processing symbol files”做的事情就是把系统符号拷贝到电脑，拷贝地址:
    ~/Library/Developer/Xcode/iOS DeviceSupport

     

    但这样有个缺陷，那就是你真机的iOS版本不会足够多，包含所有版本，所以系统符号会有缺失，另一个办法就是下载各种iOS固件，从固件中去解析。

看完了这篇文章，相信你对“iOS崩溃堆栈信息的符号化怎么用”有了一定的了解，如果想了解更多相关知识，欢迎关注创新互联行业资讯频道，感谢各位的阅读！

另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。

当前名称：iOS崩溃堆栈信息的符号化怎么用-创新互联
分享地址：http://dzwzjz.com/article/cegpoe.html