注册
登录
| 关键词： 如图 文件 信息 文件夹 基地址 bughd 教程 FIR 公司 进制 |
之前使用Twitter公司的崩溃搜集工具crashlytics，它可以准确定位APP崩溃的具体原因到代码的某一行。这个工具也被很多的大公司采用。但是因为是Twitter公司的，你们懂得（貌似DNS经常被污染），经常会漏掉很多崩溃信息。对我们的开发非常不利。前几天发现了一款国内 FIR.im公司的产品bughd，因为服务器在国内，crash的反馈速度应该很快，于是我就简单的测试了一下，非常不错。美中不足的是，因为没有上传程序的dSYM文件，所有bughd不能准确定位到崩溃的具体位置。虽然FIR给出了教程（iOS错误堆栈查找崩溃原因的方法），但是可能不是非常浅显易懂，因此我要来个详细的扩展教学！一步步来！1.制作崩溃代码以及添加bughd SDK这里我为了测试，写了一个简单的数组越界，如图所示：下载bughd SDK，将下载包中的FIR.framework 文件夹拖到Xcode项目中。在应用的设置中, Build Phases -> Link Binary With Libraries里添加SystemConfiguration.framework在 AppDelegate.m 中:1#import <FIR/FIR.h> //导入头文件然后在application:didFinishLaunchingWithOptions:方法中加入一行:1[FIR handleCrashWithKey:@"YOUR_GENERAL_KEY"];这里的 YOUR_GENERAL_KEY 是建立每个项目时将自动生成项目对应的General Key。2.打包程序，并安装到手机上菜单栏->product->Archive。如图，在这一步的时候，show in Finder把刚刚生成的最新的xcarchive文件保存一份。然后打包成功，安装到手机上去（如果是发布，就上传到AppStore上去）3.查看崩溃信息，并查找原因当有用户使用此APP崩溃的时候会在bughd后台收到崩溃信息。如图所示：看这个头都大了吧，下面我教大家解码！把刚才保存的xcarchive文件打开，显示包内容，将里面的“Products->Applications->文件”和”dSYMs->文件“保存到一个新的文件夹中，这里我的文件夹是CrashReport。我们来看崩溃信息，具体应该看哪条信息，fir给出了教程已经很清楚了。我们就要序号为3的这种“未标记错误位置，无基地址的情况”将0x000fdf7f转换为10进制是10402551040255-20351 = 1019904再转为16进制为 0xf9000，这个就是基地址了。我们打开终端，进入CrashReport文件夹，输入如下命令就可以得到崩溃信息1atos -arch armv7 -o mengmengdai.app/mengmengdai -l 0xf9000 0x000fdf7f如图所示：为了证实准确性，我使用了Twitter的crashlytics工具进行了一次崩溃搜集：注意看序号3，和我们分析出来的崩溃信息一模一样，在这个地方数组越界了！注意事项：不要两个崩溃搜集同时使用，不然只有一个生效的！总结：以上是为初学者准备的详细教程，如果有什么不明白，可以再查看FIR.im官方的教程进行进一步理解。 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
