TestFlight Live，QuincyKit和Crashlytics之间的比较
我将在AppStore上启动我的应用程序，我想跟踪崩溃并尽快修复它们。 如果可能的话，最好收集一些关于用户活动和其他有用信息的附加信息。 为了做到这一点，我寻找了一些崩溃报告工具，我发现最有趣的是TestFlight Live ， QuincyKit和Crashlytics 。
在这三个中，QuincyKit应该是最轻的一个，但另外两个似乎相当有趣，因为它们提供了更复杂的报告和其他有趣的东西。
我的目标是在用户可以遇到的任何问题上获得尽可能多的信息，但同时我不想让应用程序变慢或消耗更多的资源。
- 在你看来，从你的个人经验来看，哪些工具是最好的（考虑到我的目标和我的需求）？
- 通过使用TestFlight Live或Crashlytics我会让我的应用程序太慢？
- 设备过载有风险吗？
- QuincyKit提供的报告足够精确吗？ 我可以从中检索多less条信息？
谢谢！
这是我决定的：
我正在使用Crashlytics进行崩溃报告（是的，这看起来确实很棒），TestFlight用于跟踪用户活动（检查点对于了解用户通常做什么以及弄清楚趋势是非常有用的）。 我遵循这里写的指示
我真的认为Crashlytics是比Testflight更好的解决崩溃报告的解决scheme。
Crashlytics得到的是你没有得到的。
- 重复扑杀（TF也这样做，但它不是太好，Crashlytics几乎是完美的）
- 实际上，您可以将崩溃标记为已closures/已解决，并将它们从给定版本的列表中取出。
- Crashlytics可以完成TF's Crash报告所做的一切，但是更好，然后是一些（logging，堆栈跟踪等）
- 受影响的用户的百分比，以及随之而来的数字。 （即：我应该修正发生在一个人身上的错误，还是发生在10K的错误？）Testflight不会告诉你这个。
- 基于事件的优先级。 这可能是我认为最重要的收益。
这些只是一些，但我认为他们可能是你最重要的。
我们在一个非常stream行的应用程序（数百万D / L）上使用了Testflight的近2年的崩溃报告。 它肯定比没有好，而且如果你使用TF进行发布也很方便，但是你从Crashlytics中获得更多的好处。 今年夏天，我们转而使用Crashlytics，现在我们实际上能够pipe理崩溃事件，并且做出明智的决定，决定什么时候解决，什么时候解决，而不是仅仅通过一个巨大的永无止境的清单来筛选。
我看到你已经接受了一个答案，但即使你select继续使用Testflight，我也会认真的再看一遍。 我发现很难真正掌握你所缺less的东西，直到你的应用程序已经发货，在这一点上更难以改变。
Crashlytics是崩溃报告首屈一指的。
当你试图find最好的崩溃报告解决scheme时，我们就在同一条船上。 经过TestFlight，HockeyApp和Crashlytics的一些彻底的调查和testing之后，我们最初select了HockeyApp，因为他们允许我们在iOS和Android上同时发布崩溃报告（我们希望两个平台都在一个解决scheme中）。 然而，HockeyApp的例外回溯只是没有给我们任何额外的崩溃细节。 这是Crashlytics闪耀的地方。 他们的例外回溯是惊人的。 期。
所以这里是所有3个SDK的总结：
Crashlytics
- ＃1崩溃报告
- ＃1exception回溯，bar none（提供非常有用的额外崩溃细节）
- 非常快速和轻量级
- 自定义键logging额外的崩溃上下文
- 最好的重复的崩溃识别和扑杀
- 自动更新SDK（他们的Mac应用程序自动更新项目中的Crashlytics iOS SDK）
- 没有testing版发行版（我很喜欢用于崩溃报告和testing版发行的一站式解决scheme）
- 自动构build服务器支持
TestFlight
- 有点沉重，并增加你的应用程序包的膨胀
- 很棒的beta版本
- 没有Android支持（至less在6个月前我们testing过）
HockeyApp（HockeyKit – Beta发行版，QuincyKit – 崩溃报告）
- 轻量级
- 崩溃报告用户界面有点混乱
- 例外回溯严重有限（至less在2011年3月份testing时）
- 很好的beta版本
所有这一切，我们select了Crashlytics进行崩溃报告，而HockeyApp进行beta版发布。 但是你必须select最适合你需求的东西。
绝对推荐Crashlytics 。
TestFlight Live给了我过去的问题。 似乎每次我去使用TestFlight，反正它是失败的。
Crashlytics真棒。 原因如下：
- 把它添加到你的项目中不是那么容易。 有一个Mac应用程序，为您做了大部分的辛苦工作。
- 自动更新自己
- 优先处理你的崩溃
- 提供方便的统计信息，如操作系统和设备的百分比以及平均可用内存等
我在所有的应用程序中使用Crashlytics。 当我在那里的时候，我把它添加到了Hipstamatic，我们得到的数据令人震惊。 这确实有助于改进我们的产品。 我也尝试过TestFlight Live，并在第一次testing之后很快将它移除，因为它导致崩溃。
Crashlytics真棒。 你应该使用它。
如果我们只是在谈论崩溃报告，Crashlytics远胜于TestFlight。 （从未尝试QuincyKit，所以我不能比较3个选项）
我们在Weddar使用Crashlytics已经有一年多的时间了，它一直很棒。 尝试其他解决scheme之前，我不得不说，安装之前，我有点怀疑他们说的伟大的function，但安装确实在5分钟内完成，它只增加了约40-45Kb的应用程序。
崩溃报告非常详细，使得确定错误的解决scheme非常快，并且sdk的更新非常稳定和稳定。 球队也非常支持。 我记得当iPhone5出来时，我们遇到了一个新的ARM7问题，他们在30分钟内解决了这个问题。
我使用TestFlight进行用户betatestingpipe理，所以我在夏天尝试了TestFlight Live SDK，看看它是否是一个集成在一个服务中的解决scheme，但是我们对它有很不好的体验。 我第一次在App Store批准中拒绝了2个更新（Weddar在2011年4月推出），我们失去了大约一个月的时间来试图捕捉这个bug。 当进行betatesting时，没有用户会抱怨任何问题，我们通过删除TF SDK来“解决”它。 从来没有完全明白是什么问题。 我们联系了TestFlight团队，从来没有联系过。 （另一个很大的细节是TF SDK为我们的应用程序增加了大约800Kb）。
所以，即使我仍然使用TestFLight进行betatesting，如果你正在寻找一个优秀的，轻量级的崩溃报告SDK，我肯定会说你应该使用Crashlytics。
希望这可以帮助。
我会说与TestFlight （实时）
根据我的经验，TestFlight SDK不会使您的设备崩溃/放慢速度，并且具有非常全面的崩溃报告function – 允许您相当准确地debugging报告的错误。
当您正在testing开发中时，TestFlight也可以作为反馈包加倍。
这也是一个非常轻的SDK。
更具体的（回答您的问题列表）：
- TestFlight允许用户检查用户的“检查点”，并拥有自己的NSLog版本，允许您在运行时dynamic地logging事件。
- networking请求在主线程处理之后，您的应用程序不会变慢。
- 我不明白为什么一个设备会通过使用您提到的任何一个SDK来超载。
- QuincyKit的报告看起来相当精确，但是您需要对您需要的精度做出自己的想法 – 您可以在这里findQuincyKit文档。