第一步，解析堆栈信息
在bugly上收集到的信息是这样的
0x000000010542e46c 0x0000000104db4000 + 6792300
OS应用发生崩溃时，系统会生成一份崩溃日志，这份日志中包含了崩溃时的堆栈信息，但这些堆栈信息并非直接指向源代码，而是以16进制的地址表示，这就需要我们进行反向符号化操作来定位具体的代码行数。
以下是具体的步骤：
- 打开终端，cd到Xcode的"Developer"目录下，如：
```
cd /Applications/Xcode.app/Contents/Developer
```
- 执行以下命令进行反向符号化：
```
./usr/bin/atos -o dSYM文件的路径/Contents/Resources/DWARF/应用的名字 -l 内存基地址 要转换的地址
```
其中：
-
dSYM文件的路径: dSYM文件是在编译时生成，用于存储应用的调试符号信息，通常和.ipa文件在同一目录下。
-
应用的名字: 你的应用名字，该值需要和dSYM文件的名字一样。
-
内存基地址: 崩溃堆栈信息中的内存基地址。
-
要转换的地址: 崩溃堆栈信息中你要转换的那个地址。
这样就可以找到对应的源代码行数了。
需要注意的是，这种方法只适用于你有dSYM文件的情况下，如果没有，则需要使用其他方式，如在开发阶段打开Xcode的异常断点等方法。
例如：
cuixiang@Cuis-Mac-mini ~ % cd /Applications/Xcode.app/Contents/Developer
cuixiang@Cuis-Mac-mini Developer % ./usr/bin/atos -o "/Users/cuixiang/Documents/twig/twig-mobile.app.dSYM/Contents/Resources/DWARF/twig-mobile" -l 0x0000000102e38000 0x0000000103356514
得到具体的堆栈如下
cocos2d::LuaBridge::pushLuaFunctionById(int) (in twig-mobile) + 116
第二步，分析崩溃时内存占用，发现崩溃时内存剩余5%一下
第三步，查看内存和调用堆栈，通过分析波峰堆栈，查找内存增长的点，这里发现是spine相关的API，在相关调用地方加日志发现缓存失效，每次都重新创建新的spine，而旧的有没释放。进一步查找发现失效的原因是切换场景时置空了缓存池table，同样的在AndroidStudio上查看也是同样的内存涨幅，androidstudio查看内存情况看这里。
可以发现，通过调整每次进出游戏后加载的资源都释放了