Unity工具团队经常会开发一些内部工具，用于提高产品开发与QA效率，最终改善产品整体质量并提升用户体验。本文我们就一起来了解一下其中自动化分析处理程序崩溃的工具Crash Analyzer。

早期方法
Unity处理Bug最初的办法是借助编辑器中的工具Bug Reporter。Bug Reporter可以手动启动或者在程序崩溃时自动加载(您可以在这里了解更多Reporting-a-bug)，并提交错误报告。在用户提交错误报告后，QA团队需要重现这个错误（最初叫作事件）并将它转换为Bug，然后移交给开发团队进行分类或修复。

一般来说，符合要求的错误报告需要包含很多元素，比如描述标题、重现步骤并附带项目（理想情况是能直接重现问题的小项目），以便进行问题查验与重现。这样的错误报告会更容易被Unity的员工所认同（在Attaching-your-project-to-a-bug-report了解更多）。

出现问题
随着Unity注册开发者超过百万，我们发现了新的问题：出现太多相同的Bug报告！我们平均每月会收到6000份Bug报告，都需要经历逐份查验、回复等流程。不仅如此，在我们查证甚至已经修复某个Bug之后，依然会收到很多相似的错误报告，这个过程花费了QA团队大量的时间。只有自动化才能解决问题！

解决方案
大多数情况下，定位问题最好的办法就是崩溃日志，因为这些崩溃日志都有着一个共同特征，就是崩溃的堆栈调用信息。例如，编辑器程序的函数调用顺序最终导致的崩溃，日志顶部会带有崩溃函数的名称。所以相对其他Bug而言，这类问题更容易被机器聚类，而无须其他人工干预（特殊情况稍后讨论）。这为自动化处理程序崩溃带来了希望！

优点
几年前我们就已展开此项目，当时并不知道它能带来多少额外的洞见。根据多个版本编辑器中程序崩溃的历史数据（数量、动态等），可以及时察觉用户机器上发生的崩溃是否已经在某个Unity版本中修复。

于是我们开发了一款工具用于分析用户发送的所有报告、解析编辑器附带的所有日志、定位崩溃的调用堆栈，并将相同或相似的崩溃映射在一起，如下图所示。
 

 
Crash Analyzer

 
相似的崩溃和报告数据统计

这样做可以为修复问题的开发者和测试人员带来巨大的价值。有了这样一款工具，发布主管可以在着手A/B测试之前先评估某个版本产品的稳定性和成熟度，也可以快速定位由版本回归造成的Bug以及通过User Pain系统产生的Bug。
 

在Crash Analyzer中处理重复错误报告
如果已经将某类崩溃报告转换为Bug，那么其他相似的错误报告最好可以被关闭（但会为用户提供Issue Tracker链接跟踪Bug修复的进展）。为了解决这个问题，我们可以将其中一份错误报告标记为崩溃的重现工程（Repro），并将其他报告标记为重复，如下图所示。
 

 
如果已存在对应的重现工程(repro)，则解决并关闭相同的错误报告

为了方便所有人，我们添加了Slack集成功能，所以如果您想接收新的崩溃报告提醒，包括该Bug是否为已知，Bug报告对应的Unity版本等信息，订阅如下图所示的新频道即可。
 

 
Slack提示有新的崩溃报告产生

已知问题或定位问题
纵然如此，这个问题并未完全解决。我们一直在改进算法，堆栈上有些毫无意义的函数调用信息需要被过滤。一些平台为我们提供了更好的调用堆栈收集机制。一些崩溃完全可以通过调用堆栈来识别，也就可以全自动化处理。有时相同Bug的崩溃日志一定是100%完全一致的，但有时仅需“相似”就可以判定为同一Bug了，比如日志顶部信息一致，如崩溃函数名等，但堆栈信息大不相同。

还有一种特殊情况，即使调用堆栈相同也可能是不同的Bug。这种情况通常出现在调用第三方库或驱动时，不足以判定崩溃本身的确切位置，并且调用的参数和配置不同也会带来不同的问题。这类崩溃无法做到完全自动化处理，需要人工调研来进行区分。我们的目标是至少做到半自动化，即在自动处理之前需要人工检查并解决部分问题。

未来展望
我们计划进一步整合已有的Issue Tracker和Bug Reporter工具，不再像之前那样收集用户的崩溃报告并存储在我们的服务器中、分析并为已有的Bug提供参考或解决方案，而是在Bug Reporter和Crash Analyzer后台直接进行数据交换，以免提交已经被解决的Bug报告，并为用户提供最及时的反馈或解决方案，用户再也不用提交错误报告并等待QA团队的回复了。

总结
有关该工具的更多进展，敬请期待。