这是一个老生常谈的问题，只要做游戏，发布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的可视化操作很直观。
我这里有个人的一些笔记，仅供参考
- ida入门教程: https://juejin.cn/post/7306894457814433855
- 实战1：使用ida分析崩溃: https://juejin.cn/post/7298361908444151862
- 实战2：使用ida分析崩溃: https://juejin.cn/post/7307061788145844243)
更多文章可以浏览个人的掘金，纯纯的干货。
5. 在代码层捕获signal信号量
看到这里如果你还没有思路解决项目的崩溃，你可能得考虑从代码层面入手了，集成一些崩溃捕获的lib库，因为拿到崩溃的堆栈对于解决崩溃至关重要。
当app产生崩溃时系统会向当前进程中发送一个信号量，表示进程异常。
我们可以拦截这个信号量，收集相关的信息，上传到服务器，方便我们后续排查，对应的函数是：
void (*signal(int sig, void (*func)(int)))(int)在回调中，我们可以获取c++的堆栈信息，同时我们也可以收集当前脚本引擎(lua/js)的调用堆栈情况，一般脚本引擎都是有对应接口的，这种方案对于解决那种偶发性的bug，非常有帮助。
我了解到的[爱奇艺xCrash](
https://github.com/iqiyi/xCrash)的崩溃收集，就是围绕这个signal函数实现的，另外还有`google breakpad`可供选择。
6. android native调试
android studio提供了调试ndk的能力，也就是调试c++，不过环境配置起来还是有点麻烦，个人笔记，仅供参考：
- Android JNI联调环境配置: https://juejin.cn/post/7250283546367983676
- Android NDK调试启动分析LLDB-SERVER: https://juejin.cn/post/7280007090755878967
7. 重新思考崩溃的真正原因，不要被报错迷惑
到这里没有解决崩溃问题？说明大概率游戏的崩溃可能不是c++层导致的，毕竟一般我们也不会对engine大改，有能力魔改engine的项目除外。
你需要尽可能的编写一个干净的demo，尽量排除掉干扰项，对于看清问题至关重要，虽然这么做很麻烦，我知道剥离demo是一件很痛苦的事情。
8. 不是办法的办法
以上给出的都是方向性的解决方案，一般来说，addr2line+signal信号量，这套组合拳足以让大部分的崩溃无处遁形，并且这个组合拳我在排查崩溃的时候屡试不爽，如果你也在排查崩溃的过程中遇到了问题需要交流，欢迎加微信交流，这也算是解决崩溃的一种办法。
另外本人现在处于待业状态（被优化了），正在看合适的工作机会，有坑的朋友欢迎私信。