看着bugly干了1个多月的crash问题处理,可以说是心力憔悴,整天对着一堆莫名其妙的崩溃堆栈和一大把日志发愁,背锅的滋味可是真不好受,得空写一篇总结与各位背锅侠共勉。
一般来说游戏的Crash引起原因分为这么几类:1.内存不足、2.逻辑代码导致、3.Unity引擎自身问题以及4.第三方库的自身问题。内存不必说了,逻辑代码因为是C#脚本,又隔了一层引擎出现崩溃的可能性也是极低,大部分需要处理的crash其实都是3和4。这样说来的话其实负责解决crash问题的同志们也就可以洗洗睡了,引擎和第三方库的问题又不是咱的问题,咱也改不了,出了问题这锅想接也没法接啊。其实不然,对于3、4问题的处理,一是可能因为我们用了错误的调用方式,二是可能有一些workaround去绕过崩溃的地方,而这两点都基于我们能够准确定位crash产生的原因或者至少准确定位crash产生位置的基础之上。这篇博客也就是总结一下bugly使用的一些经验,通过bugly去来定位或者分析这些crash。
*
首先第一步要做的就是上传libunity.so的符号表!,这一步是最简单也是最重要的,虽然bugly官网上是这样写的
2) Unity项目的Android工程中默认加载的几个Native库(libmono.so,libunity.so等)没有的debug版本,所以开发者也无法获得对应的符号信息进行配置
但是其实Unity从5.3开始就提供的libunity的符号表https://support.unity3d.com/hc/en-us/articles/115000292166-Symbolicate-Android-crash
位置在【Unity安装目录】\Editor\Data\Playbac