看着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 release发布说明里面的fixed项，看看有没有相关crash的修复。总之一旦定位到了具体崩溃的模块或者方法，后面的处理基本上也就算是有眉目了，无论最后解决还是不解决基本上都能有一个靠谱的答复。
Unity引擎的崩溃处理基本上就说完了，下面说说最头痛的第三方库的崩溃问题，通常第三方库可是没有符号表的，而且基本肯定是原生代码写的，所以你看到的堆栈信息基本上来说应该是这样的：
这是什么鬼！这种情况下崩溃堆栈里是没什么可用信息了。那日志是什么情况呢？情况绝对好不到哪里去，bugly上截得日志是在太短了，经常是连崩溃的点都没有截取到，也不知道他们是什么算法。不过没有关系，一个设备崩溃的日志不好使还有其他的，点击查看更多，总会是有些设备的日志里能看到点有用信息。比如下面这两段日志，就是来源于同一个crash下面，那信息量可以算的上是天差级别了。
这个Log是来搞我的么！！！还是下面这个靠点谱
需要注意的是看Log定位崩溃原因时不要仅仅被红字所吸引，bugly应该是会把Error标成红色，也就是第四项为E的log，但是Error不等同于崩溃，还要具体看Error后面的信息，如果信息里包含什么SIG啊Abort啊crash这类的的才能说这一条Error是crash的点。但是如果你看到的Log类型是F，也就是Fatal，那肯定就属于系统崩溃日志了，当然也没准是垃圾，就比如上面展示的第一条Log。
一般来说光看崩溃信息是没有什么用的，因为那都是标准的系统崩溃说明，比如SIGSEGV、SIGABRT这些，如果你只拿着这种信息去网上搜肯定是搜不出来有用东西的，这个时候除了定位系统崩溃点之外，通常还需要做第二件事，那就是找！相！同！
有啥相同呢一般来说有运行时间（是否都是刚启动或者长时间运行）、设备机型（是否是某一特定机型的兼容性问题）、系统版本（是否是特定系统的兼容性问题），以及最重要的崩溃点之前的日志信息。前面几点如果找到了一些相同特效顶多是为你描述这个crash或者了解crash影响的范围有所帮助，但是真正如果要解决一个crash的话还是要从日志信息中入手，一般说来如果你发现了相同的日志信息总是出现在crash发生节点之前，那么接下来就应该着手去分析或者测试打出日志的点与crash的关系了。这块说得实在有点干，还是讲一个具体的例子吧。
这是我们线上报出的一个crash，占比挺高的一直都没定位解决，首先看堆栈信息：
就一条libmono.so，什么鬼，难道还是C#代码导致的崩溃？开什么玩笑，而且怎么会一句话就搞崩了呢。看一下线程信息‘#unknown(1523)’不是UnityMain，所以肯定是排除了逻辑代码【直接】导致崩溃的情况。那么接下来先看看设备信息：
咦？怎么系统版本全是一样的，看来是系统版本兼容性问题喽？哼，难道要甩锅给系统版本不管了？想得太美，版本一样不是个有用信息，还得接着看。设备怎么全是小米5？我靠小米这破手机坑老子！还有个virtual machine 2应该是个模拟器，先来看看小米5的问题吧，随便选择一个看下设备详细信息：
这xxx的ROM，这x86的CPU架构，原来刚才错怪小米了，这设备不是小米5啊，其实是个PC上的模拟器啊！ok，现在确认所有崩溃都发生在模拟器上了，老大，要不咱把模拟器屏蔽了呗？屏你个头啊，咱跟人家可是有合作的！这个问题必须解决！好吧，那只能看Log了，先随便点开一个看一下：
VM Aborting!肯定就是崩溃在这儿了，看一下崩溃信息，native thread exited without detaching，再往上都是些不知所云的log。先来查一下这个错误是什么意思，呵，CSDN上就有相关内容，随便给个面善的兄弟打个广告吧，http://blog.csdn.net/wangchenggggdn/article/details/7819708，大概情况就是有这么一个线程结束后没有调用detach，导致了这个崩溃。
嗯嗯，这好说，那找到那个线程的代码把detach加上不就解决了。。。。。个头！这明显就是第三方库里的代码导致的，在Unity逻辑代码里没有用线程（其实有网络线程，当时忽略了），怎么可能改嘛！可是这个问题必须要解决啊，没办法，虽然现在定位了问题的原因，但是还没有定位问题产生的位置，至少定位是哪个第三方组件的问题不行找人家解决呗，也算能有个交代。
那么继续看，注意到log中第二和第三字段，92是进程ID，386是线程ID，如果能知道386这个线程是谁启动的就好了。这个log里是看不出来了，没关系，看看其他的log，在大概看了100多个上报设备的log以后，我在其中几个log中发现了相同点！
Nailed It! MSDK!这口锅给我背了一个月！那么现在的情况是已知MSDK有个一个GetLoginRecord的线程，没有调用Thread.Detach，导致游戏崩溃了。怎么办呢？让人家大厂改肯定是不现实了，不过既然定位了问题产生的点，那么就进一步继续定位逻辑代码中的调用位置，看看是不是调用的方式不对或者是有什么办法可以绕过去。那么下一步，在调用GetLoginRecord的地方添加上UnityLog并输出调用堆栈，出包重新测试，发现原来这些调用都是在TCP Socket Receive回调线程中调用的，查看了一下SVN，这一块的添加日志与crash首次上报日期吻合（在两次版本发布时间的中间）！
唉，到头来这口锅还是得我们程序来背了（哭），可是那也不是我写的啊（大哭！）！
总结一下这个crash，native thread exited without detaching，原因是在Socket线程中调用了一个第三方接口，生成了一个线程attach了socket线程但是却没有做detach，所以当这个socket资源被回收时attach的第三方线程本应调用detach却没有调用，导致了程序的崩溃。解决方法就是只在主线程中调用这个接口，这样也就不存在需要detach的情况了。
最后再总结一下crash定位，一句话，不要怨天尤人，这口锅咱得背瓷实了！
