TestFlight Live、QuincyKit和Crashlytics之间的比较

29

我将在AppStore上发布我的应用程序,并希望尽快跟踪崩溃并修复它们。如果可能的话,收集关于用户活动和其他有用信息也会很好。 为此,我寻找了一些崩溃报告工具,我发现最有趣的工具是:TestFlight LiveQuincyKitCrashlytics

在这三个工具中,QuincyKit 应该是最轻量级的,但另外两个似乎更有趣,因为它们提供了更复杂的报告和其他有趣的东西。

我的目标是尽可能多地获取用户可能遇到的任何问题的信息,但同时我不想让应用程序变得更慢或消耗更多资源。

  1. 根据您的个人经验和意见,这些工具中哪一个最适合我的目标和需求?
  2. 使用 TestFlight Live 或 Crashlytics 会使我的应用程序变得太慢吗?
  3. 有超载设备的风险吗?
  4. QuincyKit 提供的报告足够精确吗?我可以从中检索多少信息?

谢谢!

这是我的决定:

我使用 Crashlytics 进行崩溃报告(是的,它看起来真的很棒),并使用 TestFlight 跟踪用户活动(检查点非常有用,可以了解用户通常做什么,找出趋势)。 我按照这里的说明进行操作。


1
正是像这样的“观点”类型问题,使得在StackOverflow上这些问题如此有价值。 - Bradley Thomas
5个回答

43

我认为Crashlytics是比TestFlight更好的崩溃报告解决方案。

以下是使用Crashlytics而不是其他工具所能获得的优势:

  • 消除重复(TestFlight也有此功能,但效果不太好,而Crashlytics几乎完美)
  • 您可以将崩溃标记为已关闭/已解决,并在给定版本的列表中将其清除。
  • Crashlytics比TF的崩溃报告做得更好,还提供日志记录、堆栈跟踪等功能。
  • 受影响用户的百分比以及相应的数字。 (例如:我应该修复只发生在一个人身上的错误,还是修复影响10k的错误?)Testflight无法告诉您这些信息。
  • 基于发生次数的优先级设置。 在我看来,这可能是最重要的收益。

这只是其中的一部分,但我认为它们对您来说可能是最重要的。

我们在一款极其受欢迎的应用程序(数百万次下载)上使用了近2年的Testflight崩溃报告。 它绝对比没有好,如果您还在使用TF进行分发,则非常方便,但是使用Crashlytics可以获得更多的好处。 我们于今年夏天切换到Crashlytics,现在我们实际上能够管理崩溃并做出明智的决策,确定何时修复问题,而不是只是浏览一个永无止境的列表。

我看到您已经接受了一个答案,但即使您选择继续使用Testflight,我也建议您再次考虑Crashlytics。 在应用程序发布之前很难真正明白您所错过的内容,此时要进行更改会更加困难。


非常感谢您提供如此详细的答案!我一定会查看Crashlytics,并在与TF进行比较后做出最终决定!;-) - pAkY88
有没有人可以告诉或建议在iOS应用程序中使用/集成Crashlytics的教程? - Venk

16

Crashlytics是最出色的崩溃报告解决方案。

我们曾经像你一样试图找到最好的崩溃报告解决方案。在对TestFlight、HockeyApp和Crashlytics进行了全面调查和测试后,我们最初选择HockeyApp,因为他们允许我们在iOS和Android上进行beta分发以及崩溃报告(我们希望在一个解决方案中同时解决这两个平台的问题)。然而,HockeyApp的异常反向跟踪并没有给我们提供任何额外的崩溃细节。这就是Crashlytics的优点所在。他们的异常反向跟踪非常棒。

以下是我对这3个SDK的总结:

Crashlytics

  • 排名第一的崩溃报告
  • 无可比拟的排名第一的异常回溯(提供非常有用的额外崩溃细节)
  • 极其快速和轻量级
  • 自定义关键日志记录以获取附加的崩溃背景信息
  • 最佳的重复崩溃识别和去重
  • 自动SDK更新(他们的Mac应用程序会自动更新您项目中的Crashlytics iOS SDK)
  • 没有beta分发(我希望有一个一站式解决方案,可以同时处理崩溃报告和beta分发)
  • 自动构建服务器支持

TestFlight

  • 有些臃肿,增加了应用程序包的负担
  • 非常好的beta分发
  • 没有Android支持(至少在6个月前我们测试时是这样的)

HockeyApp(HockeyKit - Beta distribution, QuincyKit - Crash reporting)

  • 轻量级
  • 崩溃报告UI有点令人困惑
  • 异常反向跟踪受到严重限制(至少在2011年3月我们测试时是这样的)
  • 非常好的beta分发

尽管如此,我们选择了Crashlytics进行崩溃报告,并选择HockeyApp进行beta分发。但您必须选择最适合您需求的解决方案。


2
你能详细解释一下你所说的“#1 崩溃报告”、“#1 栈展开”和“极快且轻量级”是什么意思吗? - landonf
1
当Crashlytics首次发布时,它基于PLCrashReporter,并且受到Bryan和其他人指出的相同缺点的影响。因此,我们编写了自己的代码(请参见:http://www.crashlytics.com/blog/major-update-crashlytics-for-ios-2-0/ 以获取更多详细信息)。 - Jeff Seibert
1
@Kerni 总结一下,PL 有一些主要缺点:1. 它依赖于信号处理程序而不是 Mach 异常,这使得它无法检测/捕获许多类型的堆栈溢出崩溃。2. 当 objc_msgSend 崩溃时,它的堆栈解开器会表现出异常行为,遮盖了调用函数。需要明确的是,这只是一个摘要 - 在调整我们的技术过程中,我们收集了大量崩溃数据,并且有数十种情况 PL/HockeyApp 无法收集完整信息。 - Jeff Seibert
3
历史上,PLCrashReporter使用sigaltstack(),但是随着Apple的后续版本,这种方法失效了。在iOS上使用Mach异常处理程序会有问题,即API并没有完全公开,这意味着您必须依赖于未记录的结构和常量来实现完整的功能。我已经在这里撰写了我的初步发现:http://bit.ly/Woghtd。一旦我完成这个实现,我可能会编写更正式的内容。至于其余部分,很遗憾您没有分享任何信息来帮助改进完全免费的OSS库,而您却依赖它。 - landonf
1
无论如何,在下一个版本中我将部署增强的堆栈展开(再次作为OSS,免费,利用我自己的时间),这应该会改善我们已经知道的一些边缘情况;如果您有任何其他指针可以分享,我很乐意听取。我会注意到,在objc_msgSend()崩溃的情况下,通过寄存器转储在崩溃报告中可用的必要信息,并且主要是在服务器上正确解释它的问题。 - landonf
显示剩余9条评论

9

强烈推荐使用Crashlytics

我在过去曾遇到TestFlight Live的问题。每次我想使用它时,似乎都会出现故障。

Crashlytics非常棒。以下是原因:

  • 将其添加到您的项目中非常容易。有一个Mac应用程序可以为您完成大部分繁重的工作。
  • 自动更新
  • 为您优先处理崩溃
  • 提供实用的统计数据,如操作系统和设备百分比以及平均可用内存等

我在所有应用程序中都使用Crashlytics。当我在Hipstamatic添加它时,我们收到了令人震惊的数据。它真正帮助我们改善了产品。我也尝试过TestFlight Live,但在第一个测试版之后很快将其删除,因为它会导致崩溃。

Crashlytics非常出色。你应该使用它。


6
如果我们只谈论崩溃报告,Crashlytics比TestFlight要好得多。(我从来没有试过QuincyKit,所以无法比较这三个选项。)
我们在Weddar上使用Crashlytics已经一年多了,它非常棒。之前我们尝试过其他解决方案,但在安装之前,我对他们声称的伟大功能有点怀疑,但事实证明安装只需要大约5分钟,而且只会增加约40-45Kb到应用程序中。
崩溃报告非常详细,使得很容易找出错误的解决方案,SDK的更新也相当稳定。团队也非常支持性。我记得当iPhone5发布时,我们遇到了新的ARM7s问题,他们在大约30分钟内解决了问题。
我使用TestFlight进行用户测试管理,因此我夏季尝试了TestFlight Live SDK,只是想看看是否可以将所有集成到一个服务中,但我们的体验非常糟糕。第一次提交应用商店批准时,我的两个更新都被拒绝了(Weddar于2011年4月推出),我们花了大约一个月的时间来解决这个问题。在进行实时测试时,没有任何用户抱怨任何问题,我们通过删除TF SDK“解决”了这个问题。我从来没有真正理解过问题在哪里。我们联系了TestFlight团队,但从未得到回复。(另一个非常重要的细节是TF SDK将大约800Kb添加到我们的应用程序中。)
所以,即使我仍然使用TestFLight进行测试,如果您正在寻找一个出色且轻量级的崩溃报告SDK,我绝对建议您使用Crashlytics。
希望这有所帮助。

4

我建议使用TestFlight(现已上线)。

根据我的经验,TestFlight SDK不会导致设备崩溃/减慢,并且具有非常多功能的崩溃报告 - 让你能够相当精确地调试已报告的错误。

TestFlight也是在开发过程中测试反馈的一个很好的工具包。

它还是一个非常轻量化的SDK。

具体来说(回答您列出的问题):

  1. TestFlight允许您拦截用户“检查点”,并具有自己的NSLog版本,可以让您在运行时动态记录事件。
  2. 由于网络请求是在主线程之外处理的,因此您的应用程序不会减慢速度。
  3. 我不明白为什么使用您提到的任何SDK都会使设备超负荷运行。
  4. QuincyKit的报告似乎相当精确,但是需要您自己决定所需的精确度-您可以在这里找到QuincyKit文档。

2
QuincyKit为您提供完整的标准格式崩溃报告。因此,它具有与Apple的任何崩溃报告相同的信息细节,包括所有运行线程和在异常情况下的最后异常回溯。这很重要,因为异常由运行时重新抛出,否则您将不知道实际异常发生的位置。由于它是开源的,您需要在自己的服务器上设置它,并自己设置符号化过程。您还可以添加自己的日志数据并将其附加到崩溃中,例如使用CocoaLumberjack。 - Kerni

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接