29

我将在 AppStore 上启动我的应用程序，我想跟踪崩溃并尽快修复它们。如果可能的话，收集一些关于用户活动和其他有用信息的附加信息会很好。为此，我寻找了一些崩溃报告工具，我发现最有趣的是：TestFlight Live、QuincyKit和Crashlytics。

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

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

  1. 在您看来并根据您的个人经验，这些工具中哪一个是最好的（考虑到我的目标和需求）？
  2. 通过使用 TestFlight Live 或 Crashlytics 我会让我的应用程序太慢吗？
  3. 是否存在使设备过载的风险？
  4. QuincyKit 提供的报告是否足够精确？我可以从他们那里检索到多少信息？

谢谢！

这是我的决定：

我正在使用 Crashlytics 进行崩溃报告（是的，它似乎真的很棒）和 TestFlight 用于跟踪用户活动（检查点对于了解用户通常做什么并找出趋势非常有用）。我按照这里写的说明

4

5 回答 5

43

老实说，我认为 Crashlytics 是比 Testflight 更好的崩溃报告解决方案。

这是您通过 Crashlytics 获得的，而其他人则无法获得的。

  • 重复剔除（TF 也这样做，但它不太擅长，Crashlytics 几乎完美无缺）
  • 您实际上可以将崩溃标记为已关闭/已解决，并将它们从给定版本的列表中删除。
  • Crashlytics 可以完成 TF 的 Crash 报告所做的所有事情，但更好一些（日志记录、堆栈跟踪等）
  • 受影响用户的百分比，以及随之而来的数字。（即：我应该修复发生在一个人身上的错误，还是修复发生在 10k 身上的错误？）Testflight 没有告诉你这一点。
  • 基于发生的优先级。这可能是我认为最重要的收获。

这些只是一些，但我认为它们可能对你来说是最重要的。

我们在一个非常受欢迎的应用程序（数百万 D/L）上使用了 Testflight 的崩溃报告近 2 年。它绝对比没有好，如果您也使用 TF 进行分发，它也非常方便，但是您从 Crashlytics 中获得更多好处。今年夏天我们改用 Crashlytics，现在我们实际上能够管理崩溃并就修复的内容和时间做出明智的决定，而不仅仅是筛选一个巨大的永无止境的列表。

我看到您已经接受了答案，但即使您选择继续使用 Testflight，我也会认真地再看一遍。我发现在你的应用程序发布之前很难真正掌握你所缺少的东西，此时更难改变。

于 2012-12-27T17:16:37.403 回答
16

Crashlytics在崩溃报告方面是首屈一指的。

我们与您在同一条船上试图找到最佳的崩溃报告解决方案。在对 TestFlight、HockeyApp 和 Crashlytics 进行了一些彻底的调查和测试运行之后，我们最初选择了 HockeyApp，因为它们允许我们在 iOS 和 Android 上进行测试版分发以及崩溃报告（我们希望这两种解决方案都适用于两个平台）。然而，HockeyApp 的异常回溯并没有给我们任何额外的崩溃细节。这就是Crashlytics 大放异彩的地方。他们的异常回溯是惊人的。时期。

所以这是我对所有 3 个 SDK 的总结：

崩溃分析器

  • #1 崩溃报告
  • #1 异常回溯，没有例外（提供非常有用的额外崩溃细节）
  • 非常快速和轻量级
  • 用于附加崩溃上下文的自定义键日志记录
  • 最佳重复崩溃识别和剔除
  • 自动 SDK 更新（他们的 Mac 应用程序会自动更新您项目中的 Crashlytics iOS SDK）
  • 没有测试版分发（我喜欢崩溃报告和测试版分发的一站式解决方案）
  • 自动构建服务器支持

试飞

  • 有点重，并为您的应用程序包增加了膨胀
  • 出色的 beta 分布
  • 不支持 Android（至少当我们在 6 个多月前进行测试时）

HockeyApp（HockeyKit - Beta 分发版，QuincyKit - 崩溃报告）

  • 轻的
  • 崩溃报告 UI 有点混乱
  • 异常回溯受到严重限制（至少在我们在 2011 年 3 月测试时）
  • 非常好的 beta 分布

综上所述，我们选择 Crashlytics 进行崩溃报告，选择 HockeyApp 进行 beta 分发。但是您必须选择最适合您需求的方法。

于 2012-12-31T16:15:05.143 回答
9

绝对推荐Crashlytics。

TestFlight Live 过去曾给我带来过问题。似乎每次我去使用TestFlight，它反正是下来。

Crashlytics 很棒。原因如下：

  • 将它添加到您的项目中再简单不过了。有一个 Mac 应用程序可以为您完成大部分繁重的工作。
  • 自动更新自己
  • 为您优先考虑崩溃
  • 提供方便的统计数据，如操作系统和设备百分比以及可用的平均内存等

我在所有应用程序中都使用 Crashlytics。当我在那里时，我将它添加到 Hipstamatic，我们得到的数据令人震惊。它确实有助于改进我们的产品。我还尝试了 TestFlight Live，并在第一个测试版后迅速将其删除，因为它会导致崩溃。

Crashlytics 很棒。你应该使用它。

于 2013-01-04T15:25:35.707 回答
6

如果我们只谈论崩溃报告，Crashlytics 比 TestFlight 好得多。（从未尝试过 QuincyKit，所以我无法比较这 3 个选项）

我们在 Weddar 上使用 Crashlytics 已经一年多了，效果非常好。在我不得不说之前尝试过其他解决方案之前，我对他们所说的强大功能有点怀疑，但安装确实在大约 5 分钟内完成，它只为应用程序增加了大约 40-45Kb。

崩溃报告非常详细，可以非常快速地确定错误的解决方案，并且对 sdk 的更新非常稳定。团队也非常支持。我记得我们在 iPhone5 推出时遇到了新的 ARM7s 的问题，他们在大约 30 分钟内解决了这个问题。

我使用 TestFlight 进行用户 beta 测试管理，所以我在夏天尝试了 TestFlight Live SDK，只是想看看它是否是一个将所有内容集成到一个服务中的解决方案，但我们对它的体验非常糟糕。我第一次在 App Store Approval 中拒绝了 2 个更新（Weddar 于 2011 年 4 月推出），我们失去了大约一个月的时间来试图捕捉这个错误。在 LIVE beta 测试时，没有用户会抱怨任何问题，我们通过移除 TF SDK “解决”了它。一直不太明白是什么问题。我们联系了 TestFlight 团队，但从未联系过。（另一个大细节是 TF SDK 为我们的应用增加了大约 800Kb。）

因此，即使我仍然使用 TestFLight 进行 beta 测试，如果您正在寻找一个出色且轻量级的崩溃报告 SDK，我肯定会说您应该使用 Crashlytics。

希望这可以帮助。

于 2012-12-28T11:56:10.940 回答
4

我会说去TestFlight (Live)

根据我的经验，TestFlight SDK 不会使您的设备崩溃/减速，并且具有非常通用的崩溃报告 - 允许您相当准确地调试报告的错误。

当您在开发中进行测试时，TestFlight 还兼作反馈包。

它也是一个非常轻量级的 SDK。

更具体地说（在回答您的问题列表时）：

  1. TestFlight 允许您对用户“检查点”进行剥头皮，并拥有自己的 NSLog 版本，允许您在运行时动态记录事件。
  2. 由于网络请求是在主线程之外处理的，因此您的应用程序不会变慢。
  3. 我不明白为什么使用您提到的任何一个 SDK 都会使设备过载。
  4. QuincyKit 报告似乎相当精确，但是您需要自行决定所需的精度 - 您可以在此处找到 QuincyKit 文档。
于 2012-12-26T15:26:04.963 回答