工程上线后,总会有几个崩溃,有的是操作问题,有的是程序bug,下面就是如何通过崩溃日志找到程序bug的过程

  1. 先弄到设备上APP的crash日志
    参照(这篇日志),我的日志是从报错平台上得到的,这步跳过
  2. 打开报错日志(这里只保留了有用信息,不过你拿得到报错机器的话…直接看8.)
  3. 分析
    gcld开头的应该就是引起崩溃的地方,不过完全看不懂
    a) 创建一个crash文件夹
    b) 把报错日志重命名成app.crash 放进crash文件夹
    c) 问开发要xcarchive,从xcarchive里找到app.app和app.app.dSYM 放进crash文件夹
    d) 复制/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash 放进crash文件夹
    e) 打开Terminal

    f) 我们看到了"got symbolicator for /Users/superyyl/Desktop/crash/app.app/app, base address 4000"这种日志
  4. 打开gcld-kuaiyong-symbol.crash文件
    发现Thread 0的地方已经变样子了

  5. 找到C代码​
    打开LuaCocos2d.cpp,找到21969行,看到C代码

  6. 根据日志判断崩溃原因
    错误类型是SIGSEGV,从signal.h文件中得知
    ​​

  7. 分析用户的行为日志
    such as:最近收发的数据包,最近调用的接口,进入的场景名
    来跟踪lua代码可能出错的地方

  8. 既然拿得到设备…
    a) 找开发要到当时版本的xcarchive,导入到xcode中
    b) 连接设备
    c) 从xcode里的Organizer-Devices里找到Device Logs
    d) 找到崩溃的日志,左键单击
    e) 开始的2秒,崩溃日志还是内存地址,但是2秒解析过后,就能找到具体行了

  9. 最后
    这个方法能找到大部分的报错原因,但有时候拿到crash并非完全有效,比如你可能拿到大量例子中的"___lldb_unnamed_function6269"就无从下手

附录1:

Apple Hardware Model

附录2: 

signal.h defines