本文不会详述，但会给出定位游戏崩溃问题的多种思路和解决方案。我总结一下我的个人经历，希望对你有帮助。

1. 看logcat

一般来说，当Android出现问题时，检查logcat是最直接有效的方法。您可以快速了解异常日志信息，帮助定位问题。

如果应用崩溃了，一般会在logcat中看到带有signal字样的日志，有的还会打印具体的崩溃堆栈信息。

2. 崩溃日志

示例：

信号11 (SIGSEGV)，代码1 (SEGV_MAPERR)，故障地址0xfffa007d340800a4x0 0000000000000000 00000000000000x5 0000007d5061d600x6 0000007cc1e24a0c 00 x11 0 000000000000000x12 0000000000000000 x13 000000000000001 x14 000000000000000a x15 0000000000000000x16 0000007e1576ffd8 x17 7e1575ffd0 x18 0000000010000000 x19 0000007d3a0d9538x20 000000000000002 x21 fffa007d340800a8 x22 0000007d3ddf23e0 x23 0000007d3ddf2380 x24 fff9000000000000 x25 00000000fff90000 x26 ffffffffffffffff x 27 0000007d3a0d9520x28 0000000000000010 x29 0000007cc1e24eb0lr 0000007cb377d304 sp 0000007cc1e24df0 pc 0000007cb377cd10 pst 000000004 0 001000backtrace:#00 pc 000000000054dd10 /data/app/~~KAccalo2xp59wpqtWJpaLA==/com.ymy.hy.lmsg-0vY-CTvjj94qF342K93h8Q==/lib/arm64/libgame.so (lj_BC_RET +28) (BuildId: a9a1ad161e9ccfccb9c126452e629c3007d69bb1)#01 pc 00000000005ad588 /data/app/~~KAcpalo2xp59wpqtWJpaLA==/com.y my.hy.lmsg-0vY-CTvjj94qF342K9 3h8Q==/lib/arm64/libgame.so (lj_cf_package_require+292) ( BuildId: a9a1ad161e9ccfccb9c126452e629c3007d69bb1) 在回溯中，您将看到libgame.so (lj_cf_package_require+292)。 Logcat会自动恢复崩溃地址对应的C++代码和行号。

如果backtrace只有一个地址，那么需要使用addr2line通过crash地址来改变源代码地址。注意so文件必须有调试符号信息。 Android Studio打包apk默认会去掉so中的调试信息。

有时日志中没有回溯。可能是因为你的so中没有调试符号信息。在这种情况下，请使用addr2line。如果不保存相应的调试符号表，那就很难了。您可以选择重建它。带调试符号表的so文件（具体怎么做，需要的话请咨询我），但是需要保证so文件与游戏匹配，否则源代码信息不匹配就麻烦了。

3. tombstone墓碑日志

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

Fatal signal 11 (SIGSEGV)，code 1 (SEGV_MAPERR)，fault addr0xfffa007d340800a4 in tid 32510 (GLThread 149635)，pid 18454。没有更详细的崩溃信息。事实上，从这个日志中看不出任何东西。这时候就可以查看墓碑日志了。文件，顾名思义，就是当app崩溃时，系统会收集一些信息，保存到磁盘上。

对于已经root的手机来说，主要是指模拟器。您可以使用adb pull 将逻辑删除文件拉取到本地以进行故障排除。

现在大部分手机root都比较困难。没关系。您可以使用“adb bugrepot d:/crash.zip”将崩溃信息拉取到本地进行故障排除。

分析tombstone日志文件实际上和查看logcat是一样的。如有必要，需要配合`addr2line/objdump/nm`等工具进行分析，这里不再讨论。

4. ida逆向反汇编

既然你们都看到了这个，那就说明你们遇到的crash确实是很困难的，尤其是so没有调试符号表，而你们暂时无法构建一个带有调试符号表的so。你只能通过ida尝试。关于逆向工程，ida还是很强大的。它可以根据反汇编代码推导出C代码。推导出来的C伪代码仍然具有源代码的许多特征，并且易于识别。

当然`objdump`也可以生成so的反向反汇编，但是我觉得操作起来不如ida方便。 ide的可视化操作非常直观。

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

ida入门教程： https://juejin.cn/post/7306894457814433855 实战1：使用ida分析崩溃： https://juejin.cn/post/7298361908444151862 实战2：使用ida分析崩溃： 333 59juejin.cn/post/73070 61788145844243）了解更多文章，可以浏览个人挖金币，纯干货。

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

如果你看到这里之后还没有解决项目崩溃的想法，你可能要考虑从代码层面入手，集成一些崩溃捕获lib库，因为获取崩溃堆栈对于解决崩溃至关重要。

当app崩溃时，系统会向当前进程发送信号量，表明该进程出现异常。

我们可以拦截这个信号量，收集相关信息，上传到服务器，方便我们后续排查问题。对应的函数是：

void (*signal(int sig, void (*func)(int)))(int) 在回调中我们可以获取c++的堆栈信息，还可以收集当前脚本引擎的调用堆栈（lua/js），一般脚本引擎都有相应的接口。这个解决方案对于解决零星的bug非常有帮助。

我了解到的[iQiyi xCrash](https://github.com/iqiyi/xCrash)的崩溃集合就是围绕这个信号函数实现的。还有“google breakpad”可供选择。

6. android native调试

Android Studio提供了调试NDK的能力，即调试C++，但是配置环境还是有点麻烦。个人笔记仅供参考：

Android JNI联调环境配置： https://juejin.cn/post/7250283546367983676Android NDK调试启动分析LLDB-SERVER: https://juejin.cn/post/7280007090755878967

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

这里崩溃问题还没有解决吗？这说明游戏崩溃的大概率可能不是C++层造成的。毕竟一般我们不会对引擎进行大的改动，除非是有能力神奇修改引擎的项目。

你需要尽可能地编写一个干净的演示，并尽可能地消除干扰。这对于看清问题至关重要。虽然这样做很麻烦，但我知道剥离demo是一件很痛苦的事情。

8. 不是办法的办法

以上都是定向解决方案。一般来说，addr2line+signal，这个组合足以让大多数崩溃无处可藏，而这个组合也是我在排查崩溃时使用的。屡试不爽，如果您在排查崩溃的过程中也遇到问题需要沟通，欢迎您加入微信进行交流。这也算是解决崩溃的一种方法。