第一步,解析堆栈信息
在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查看内存情况看这里。
可以发现,通过调整每次进出游戏后加载的资源都释放了