看着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\PlaybackEngines\AndroidPlayer\Variations\mono\Release\Symbols,进行完这一步操作后基本上所有Unity引擎的crash问题都可以直接通过崩溃堆栈看出产生原因了,再结合具体的游戏场景进一步做分析最终找到避免该crash发生的方法。
再多说一嘴,一般来说Unity的crash基本上有这么几类,一个是shader编译的平台适配问题,二是跟资源加载相关的问题,三是跟动画、粒子这种多线程处理模块相关的问题。shader问题的话基本上调整调整shader就能搞定,剩下那些问题直接在google上搜索一下相关的堆栈信息或者日志提示信息基本在stackoverflow或者unity官方论坛上有相关的主题讨论,一般会有人提出一些workaround。另外就是浏览一下后面版本unity patch rele