cocos经验分享1:Android排查游戏崩溃的8种办法

这是一个老生常谈的问题,只要做游戏,发布app,你就躲不过崩溃的问题。

这篇文章不会具体展开,会给出多个思路和解决办法,来定位游戏的崩溃问题,总结下我个人的经验,希望能帮到你

1. 看logcat

一般android出问题,查看logcat是最直接有效的办法,能够很快了解到异常的日志信息,帮助定位问题。

app如果发生崩溃,一般你会在logcat中看到 signal字样的log,有的还会打印具体的崩溃堆栈信息

2. 崩溃日志

举例:

 signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xfffa007d340800a4
     x0  0000000000000000  x1  59e5d2e95e384ee8  x2  59e5d2e95e384ee8  x3  0000000000000003
     x4  0000000000000000  x5  0000007d5061d600  x6  0000007cc1e24a0c  x7  0000000000000000
     x8  59e5d2e95e384ee8  x9  0000007d3a0d9528  x10 0000007cd3fa6900  x11 0000000000000000
     x12 0000000000000000  x13 0000000000000001  x14 000000000000000a  x15 0000000000000000
     x16 0000007e1576ffd8  x17 0000007e1575ffd0  x18 0000000010000000  x19 0000007d3a0d9538
     x20 0000000000000002  x21 fffa007d340800a8  x22 0000007d3ddf23e0  x23 0000007d3ddf2380
     x24 fff9000000000000  x25 00000000fff90000  x26 ffffffffffffffff  x27 0000007d3a0d9520
     x28 0000000000000010  x29 0000007cc1e24eb0
     lr  0000007cb377d304  sp  0000007cc1e24df0  pc  0000007cb377cd10  pst 0000000040001000
 backtrace:
       #00 pc 000000000054dd10  /data/app/~~KAcpalo2xp59wpqtWJpaLA==/com.ymy.hy.lmsg-0vY-CTvjj94qF342K93h8Q==/lib/arm64/libgame.so (lj_BC_RET+28) (BuildId: a9a1ad161e9ccfccb9c126452e629c3007d69bb1)
       #01 pc 00000000005ad588  /data/app/~~KAcpalo2xp59wpqtWJpaLA==/com.ymy.hy.lmsg-0vY-CTvjj94qF342K93h8Q==/lib/arm64/libgame.so (lj_cf_package_require+292) (BuildId: a9a1ad161e9ccfccb9c126452e629c3007d69bb1)

在backtrace中你会看到libgame.so (lj_cf_package_require+292),logcat会自动还原崩溃地址对应的c++代码以及行号。

如果backtrace只有地址,这时候就要用到addr2line通过崩溃地址换区源码地址,注意so文件里面必须得有调试符号信息,android studio打包apk默认会把so里面的调试信息剔除掉。

有时日志里面会没有backtrace,可能是因为你的so里面没有调试符号信息导致,这种情况,使用addr2line,如果你也没有保存对应的调试符号表,就很难办了,你可以选择重新构建出带调试符号表的so文件(具体怎么做,有需要可以咨询我),但是需要保证so和游戏是匹配的,否则出来的源码信息对不上就麻烦了。

3. tombstone墓碑日志

有时你会遇到logcat捕获到的日志如下

Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xfffa007d340800a4 in tid 32510 (GLThread 149635), pid 18454 

没有更详细的崩溃信息了,这个日志其实也看不出来什么,这时可以看下墓碑日志文件,顾名思义就是app发生崩溃时,系统会收集一些信息保存在磁盘上。

对于已经root的手机,这里主要指的是模拟器,可以使用adb pull将墓碑文件拉取到本地排查。

大部分手机现在root已经很难了,没关系,可以使用adb bugrepot d:/crash.zip将崩溃信息拉取到本地排查。

分析墓碑日志文件其实和看logcat一样,必要时需要配合addr2line/objdump/nm等工具配合分析,这里不再展开。

4. ida逆向反汇编

如何你都看到了这里,说明你遇到的崩溃的确很棘手,特别是so没有调试符号表,而自己暂时又无法构建出携带调试符号表的so,这是只能尝试通过ida尝试着逆向,ida还是很强大的,能根据反汇编代码反推出c代码,反推出的c伪代码,还是有很多源码的特征,还是很容易识别的。

当然objdump也能生成so的逆向反汇编,但是我觉得没有ida操作起来方便,ide的可视化操作很直观。

我这里有个人的一些笔记,仅供参考

更多文章可以浏览个人的掘金,纯纯的干货。

5. 在代码层捕获signal信号量

看到这里如果你还没有思路解决项目的崩溃,你可能得考虑从代码层面入手了,集成一些崩溃捕获的lib库,因为拿到崩溃的堆栈对于解决崩溃至关重要。

当app产生崩溃时系统会向当前进程中发送一个信号量,表示进程异常。
我们可以拦截这个信号量,收集相关的信息,上传到服务器,方便我们后续排查,对应的函数是:

void (*signal(int sig, void (*func)(int)))(int)

在回调中,我们可以获取c++的堆栈信息,同时我们也可以收集当前脚本引擎(lua/js)的调用堆栈情况,一般脚本引擎都是有对应接口的,这种方案对于解决那种偶发性的bug,非常有帮助。

我了解到的爱奇艺xCrash的崩溃收集,就是围绕这个signal函数实现的,另外还有google breakpad可供选择。

6. android native调试

android studio提供了调试ndk的能力,也就是调试c++,不过环境配置起来还是有点麻烦,个人笔记,仅供参考:

7. 重新思考崩溃的真正原因,不要被报错迷惑

到这里没有解决崩溃问题?说明大概率游戏的崩溃可能不是c++层导致的,毕竟一般我们也不会对engine大改,有能力魔改engine的项目除外。

你需要尽可能的编写一个干净的demo,尽量排除掉干扰项,对于看清问题至关重要,虽然这么做很麻烦,我知道剥离demo是一件很痛苦的事情。

8. 不是办法的办法

以上给出的都是方向性的解决方案,一般来说,addr2line+signal信号量,这套组合拳足以让大部分的崩溃无处遁形,并且这个组合拳我在排查崩溃的时候屡试不爽,如果你也在排查崩溃的过程中遇到了问题需要交流,欢迎加微信交流,这也算是解决崩溃的一种办法。

x50%

另外本人现在处于待业状态(被优化了),正在看合适的工作机会。

11赞

还有一个办法,用windows版本的游戏调试,碰到segment fault / MAPERR这种,可以打一个windows debug,用vs调试。一般来说代码的错误都可以调出来。我用这个方法解决了不少次这种内存溢出或者野指针问题。

1赞

我认为 也就是分两种情况 是你的脚步应用层错误 还是引擎内部错误,这个还是很容易判断的 logcat就能看出来,如果不是你的脚步错误 你啊 放弃吧还是 让官方来解决吧

好文收藏一下~~~~