原文地址：redsweater.com/blog/860/cr…
原文作者：
发布时间：2009年7月28日
本文由 简悦SimpRead 转码，原文地址 redsweater.com
崩溃很糟糕。当一个应用程序遇到崩溃的错误时，它很可能会停止运行并采取wi......。
崩溃很糟糕。当一个应用程序出现崩溃的错误时，它很可能会停止运行，并带走你可能已经打开的任何未保存的工作。一般来说，对自己的代码感到自豪的开发者也会对确保代码能够抵抗崩溃而感到自豪。
不幸的是，开发人员可能很难知道一个应用程序有多容易崩溃，因为许多用户在应用程序崩溃时不会积极主动地发送错误报告。谁能责怪他们呢？他们刚刚承受了产品完全失控的耻辱，而现在你想慷慨地利用他们的时间来帮助你？
苹果公司认识到了这一点，这就是为什么他们让用户在Mac上报告崩溃情况变得异常容易。当一个应用程序被烧毁时，会出现一个对话框，提供直接向公司发送崩溃的细节。这对苹果公司来说很好，但对开发者来说却相对无用。 你看，尽管苹果公司很乐意收集你的Mac上每个崩溃的应用程序的信息，但他们不会与有关产品的开发者分享这些信息。
是的，这很糟糕。
发布我们自己的
很明显，苹果应该通过分享这些信息来帮助开发者。这对我们有好处，对平台也有好处。这对苹果也有好处。一个稳定的环境对感知质量是如此重要，以至于在iPhone上支持第三方软件不到一年的时间，他们就决定与iPhone应用开发者分享崩溃信息。
谁知道呢，我们可能会很幸运。苹果对这些信息的慷慨程度可能随时会有转机。但就目前而言，如果你想了解你的应用程序在野外的稳定性，你将不得不安排一个简单的方法，让用户直接向你发送崩溃信息。
我最近决定咬紧牙关，我发现虽然有一些非常有用的开放源代码来帮助实现这个目标，但每个软件包的优点和缺点都没有很好的记录。我希望这个关于几个选项的综述能够帮助你在你的产品中寻找最合适的解决方案。
UKCrashReporter是一个流行的选项，它的操作是自豪的低技术。它依赖于在用户的主目录中寻找崩溃日志。如果它们在那里，UKCrashReporter会询问用户是否可以通过HTTP POST请求将崩溃信息传送到你的网络服务器。
SFBCrashReporter和CMCrashReporter都与UKCrashReporter非常相似，在应用程序启动时检测崩溃日志，并提供通过HTTP POST将其提交到你选择的URL。
FeedbackReporter也依赖于崩溃日志的启动检测，但在你的应用程序中发生未捕获的Cocoa异常时提供报告。虽然这里列出的其他解决方案都紧紧围绕着崩溃，但FeedbackReporter也提供了一个通用的反馈界面，用户可以从你的应用程序中的一个菜单项调用，以获得一般的、非崩溃的反馈。
HDCrashReporter采用了与UKCrashReporter相同的方法，但选择了通过电子邮件而不是HTTP请求来传递崩溃信息。它使用苹果公司的NSMailDelivery类，如果失败了，就尝试打开一个mailto: URL，让用户使用他们最喜欢的电子邮件客户端。
ILCrashReporter及其分支ILCrashReporter-NG解决了迄今为止列出的所有选择中的一个缺点：在用户再次启动应用程序之前，不会出现提交崩溃日志的选项。为了确保用户能立即得到这个机会，ILCrashReporter启动了第二个看门狗进程，它在旁边等待你的应用程序意外地终止。如果它终止了，崩溃的信息就会被收集起来，并像HDCrashReporter一样通过电子邮件发送。与HDCrashReporter不同的是，电子邮件是通过直接连接到一个SMTP服务器来发送的，这个服务器可以从用户的设置中推断出来，也可以由你明确提供。
plcrashreporter是最新加入的程序之一，它采取了一种明显不同的方法，即忽略了苹果自己的崩溃日志，而是选择仔细检查内存状态，并将自己的、自定义格式的崩溃日志写入磁盘。它安装了自定义信号和异常处理程序，并包括对如何在不同平台上检查内存的深入理解的代码，包括iPhone、Mac i386和Mac PPC。虽然crashreporter在崩溃的时候是活跃的，但它需要一个诸如UKCrashReporter或HDCrashReporter的方法，即检测并在下次启动应用程序时提交崩溃信息。
Breakpad是Mozilla使用的崩溃报告设施，它在这里的解决方案中是独一无二的，因为它是跨平台的，支持Mac OS X、Windows和Linux。崩溃和异常在发生时被检测到，产生一个单独的崩溃报告程序，通过HTTP POST提交崩溃信息。与其他解决方案不同的是，该项目包括服务器端软件，用于收集崩溃信息和通过网络界面浏览。
Unsanity的Smart Crash Reports采取了一种更加警觉的方法，安装的软件会被加载到系统的每一个应用程序中。通过劫持标准的崩溃报告对话框，SCR能够将其重新利用为一个对开发者友好的对话框，提供给苹果和应用程序的开发者发送报告。开发者可以选择通过电子邮件或通过HTTP POST向你的服务器发送崩溃信息。在这里列出的所有解决方案中，它可能是最脆弱的，因为它劫持了苹果的用户界面。它还需要安装对你的应用程序有影响的软件，这可能是许多开发者不愿意要求他们的用户的原因。
太好了! 那么，哪一个是最好的？
如果你想在你的应用程序中进行崩溃报告，你需要从上述解决方案中做出决定，或者从头开始自己的解决方案。当然，问题是所列的解决方案中没有一个是明显的最佳选择。这取决于你自己的特定优先级和你如何回答手头的许多问题，包括。
- 解决方案的侵入性/脆弱性应该有多大？
- 立即报告崩溃，还是在下一个应用程序启动之后？
- 必须支持哪些平台和架构？
- 应该向用户展示什么样的用户界面？
- 报告应该通过电子邮件、HTTP或其他方式来传递？
希望上面的胶囊评论能给你一些方向，让你评估现有的选项，并做出适当的选择。当然，在评估和放弃这里的选项后，我相信你们中的一些人会决定蛰伏起来，在列表中添加另一个项目。如果你这样做，请让我知道_。
所有的最佳解决方案
上面的解决方案清单是在一个下午收集的（在我的微博粉丝的帮助下！），我相信这不是详尽的。种类繁多的选择首先告诉我的是，苹果公司只要分享他们该死的崩溃报告，就可以结束很多痛苦。选择的数量和实施细节的多样性已经超出了控制。而这些仅仅是一些 开源 的解决方案。我和一些同事谈过，他们为自己的目的从头开始实施类似的计划。
苹果：停止疯狂！ 释放崩溃报告，让我们不必再一次、一次、一次地重新发明这个轮子的痛苦。对我们有好处，对平台有好处，对你有好处。谢谢。
