Crasheye F&Q
Android SDK
Q: 如何通过发生宕机的手机,在页面上查找到对应的宕机信息?
A: 有两种方法可以定位到宕机问题:
方法一:通过uid 可以定位到此机器的所有宕机信息;
1、手机接入电脑,通过logcat可以查到uid的值,通过此值可以在电脑上查找,如下图的uid为:69d86f0988d898df246e36071bb02baa
2、通过设备ID可以直接在页面上进行搜索:
编号#950的宕机信息就是我们需要搜索的宕机。
方法二:通过用户标识定位宕机信息;
1、用户标识是在初始化Crasheye的时候设置进来:
(可以查看常用API: 设置用户标识)
2、假如你设置的用户标识为UserByCQF,那么在页面里就可以这么搜索:
页面就会把所有有关UserByCQF这位用户的所有宕机都会列出来。
Android NDK
Q: 后台只看到Java相关的错误堆栈信息,没发现有NDK相关的堆栈异常?
A:问题排除方法:
1、这种情况应该是初始化错误,Crasheye NDK相关的初始化应该是调用:详情参考Android
NDK接入指南
Crasheye.initWithNativeHandle(this, "Your_Appkey");
2、不同的项目引擎排除方法也不一样,Logcat中有相应的日志输出,例如:引擎使用Cocos2d,查看logcat初始化日志:
查看是否有以上的NDK初始化信息,如果没有,代表NDK没有初始化成功,请参照第一步重新初始化;
3、请不要将Crasheye加入代码混淆;
4、如果是项目的so也加入了混淆,则Crasheye无法捕获NDK的宕机;
Q: 部分机型在Android5.0 之后的版本捕获不到NDK异常?
A: libCrasheyeNDK.so 版本过旧,更新官网最新版本的so就可以成功捕获;(SDK下载)
iOS SDK
Q: 接入Crasheye后app启动崩溃,Log里有输出<Error>: +[NSString ksgIsNilOrEmpty:]: unrecognized selector?
A: Linker Flags中没有添加_ObjC选项;(详情参考:iOS SDK接入指南)
Q: 生成的crash 文件存储在什么位置?
A: 保存在Library/Caches/Crasheye下
Q: 产生崩溃后,为什么没有生成对应的crash文件?
A: 1.检查log,查看Crasheye是否有正常初始; 2.检查是否连接debugger,连接debugger时,不生成crash文件;
Q: 产生崩溃后,网站上为什么没有对应记录?
A: 重新启动App才会上传上一次崩溃的crash文件。
Unity Plugin
Q: Unity捕获不到脚本异常信息?
A: 问题排除方法: 1、应用程序在最外层添加了try catch,导致异常被try catch捕获,没有被Crasheye捕获到; 2、搜索项目其他地方有无重复使用 Application.RegisterLogCallback,如果有请使用Crasheye.SetRegisterLogFunction 代替,详情查看 帮助文档 ; 3、确定Crasheye.cs 在项目启动入口有初始化;
Q: Unity使用MONO接入的好处是什么?
A: 使用unity接入后可以查看到部分NDK崩溃的C#的堆栈信息,如下图
Q: Unity如何查看NDK堆栈信息?
A: 把unity版本下的libmain.so、libunity.so、libmono.so符号文件上传到Crasheye服务,Crasheye会自动进行重新分析,稍等片刻即可查看到相关的NDK堆栈信息;
符号表
Q: 什么是符号表,配置符号表的作用是什么?
A: 符号表是内存地址与函数名、文件名、行号的映射表。为了能快速并准确地定位用户APP发生Crash的代码位置,Crasheye使用符号表对APP发生Crash的程序堆栈进行解析和还原
Q: 配置符号表是不是必须的?什么情况下必须配置符号表?
A: 不是必须的,不会影响异常上报,但建议您进行配置。 Android( Java及NDK )符号表配置指南 iOS符号表配置指南
Q: 符号文件上传提示成功,但崩溃堆栈信息仍未分析出详细结果
A: 确认所上传的符号文件版本是否正确(方法是:刷新崩溃详情页,在页面头部显示的提示信息中的uuid是否在“设置 – 符号文件 – 符号文件上传 - 已上传列表”中存在)
Q: 符号文件上传是否有文件大小限制?
A: 使用工具上传时,单文件最大1G,其他方式上传无限制,请放心使用
Q: iOS 上传文件提示 run lipo -info false?
A: 问题排除方法:
1、是否使用了正确的符号文件上传工具,iOS应用的符号文件上传工具文件名为***iOS***.jar,Android应用的符号文件上传工具文件名为***Android***.jar;
2、符号文件路径不支持空格,若有,请将空格删除;
Crasheye平台使用
Q: Crasheye是否收费?
A: 永久免费,请放心使用
Q: Crasheye是否会有数据泄漏问题?收集了哪些信息?
A: 所收集的数据都是与崩溃相关,目的是为了给开发者提供真实的崩溃场景,并未收集任何个人隐私信息,且数据分析完成后,只针对该项目成员开放 常规收集的信息主要包括: 崩溃环境:Crash信息及线程堆栈,ROM/RAM、网络环境/系统语言等 App信息:包名、版本、所属进程名 设备信息:设备名称、系统版本、屏幕分辨率 开发者均可以通过打印上报数据日志来查看所有上报内容
Q: 未上线的应用可以使用吗?
A: 可以
Q: Crasheye和第三方SDK同时编译会不会有冲突?
A: 可能会有冲突,接入时遇到问题可联系Crasheye或第三方SDK的官方人员,或在相应帮助中查找解决方案
Q: Crasheye和同类SDK同时使用会不会有冲突?
A: 不会,建议将Crasheye在同类SDK初始化之后再初始化
Q: 接入Crasheye后会不会影响程序的运行速度?
A: 几乎没有影响,Crasheye只会在应用启动的时候,检查上次是否有崩溃数据需要上传,若有,则数据经过压缩后再上传,不影响应用的功能
Q: 消耗的流量大不大?
A: Crasheye提供接口设置只在wifi环境下才上报,当不在wifi下产生的宕机文件会保存到本地,等wifi环境下再上传,据Crasheye的统计,平均每个崩溃的数据传输量在10K左右
Q: (iOS)接入Crasheye会影响app store发布吗?
A: 不会
Q: Crasheye支持哪些自定义的功能?
A: 提供了多个功能控制接口和信息记录API: Android Api使用说明 iOS Api使用说明
Q: 我现在使用我自己的账号登录,由于工作变动可以把登录账号更改了吗?
A: 如果你是“应用所有者”,无法将帐号和应用进行解绑,建议在创建应用时使用公司产品邮箱,而非个人名字邮箱 如果你非“应用所有者”,联系“应用所有者”进行解除关联即可
Q: 接入Crasheye之后,对原应用的内存占用和CPU消耗会有多大影响?
A: 接入Crasheye之后,内存占用增加了0.86MB,CPU峰值均为1%,并无影响。
测试方法:使用
TestPlus客户端
性能测试工具,对同一程序在接入Crasheye前后均至少测试三次,每次测试时间不少于30秒,取平均值。
测试数据见下表:
无Crasheye | 有Crasheye | 增幅 | |
---|---|---|---|
内存 | 32.81MB | 33.67MB | 0.86MB |
CPU峰值 | 1% | 1% | 0% |
测试手机:红米note3
Q: 项目已经接入了Crasheye,但页面显示未接入?
A: 问题排除方法: Step1:访问网络权限是否已经添加;
<uses-permission android:name="android.permission.INTERNET"/>Step2:在logcat搜索是否有以下字符(上报活跃);
NetSender: Sending data to url: http://rp.crasheye.cn/sessionStep3:查看是否有以下结果;
NetSender: Transmitting result {"ret":0,"msg":"","data":{"appkeyvalid":true}}若以上3步检查不通过,请查看帮忙文档重新接入或者联系官方工作人员
Q: 为什么我的应用崩溃率会超过100%?
A: 有以下两种可能:
1、应用一启动就产生了崩溃,并成功被Crasheye捕获到,但是,报活未完成,由于崩溃堆栈有上报失败缓存功能,而报活无此逻辑,导致在之后的某次上报中,同时上报了多条崩溃,但只有一次报活,在这种情况下,可能会出现崩溃次数大于报活的情况,就终会导致崩溃率会超过100%;
2、应用在服务(service)里初始化了Crasheye,服务在产生崩溃之后,Crasheye会将该崩溃上报,但由于服务启动时是不会进行session(报活),而主程序此时并未崩溃,如果大量出现这种(服务崩溃的)情况就会导致 崩溃数 > 报活数;如果确定需要在服务里收集崩溃,崩溃数大于报活数的现象是属于正常的;
ps:Crasheye为什么不对服务进行报活?服务的崩溃,是不会对主程序功能产生影响的,并且主程序可以随时把服务启动起来,但服务的启动不能算是一次用户的活跃,所以Crasheye才确定不在服务里提供报活。