Flurry 错误报告与其他错误报告服务(例如 Crittercism 和 Crashlytics 等)的对比

Question

我们正在评估 iOS 和 Android 应用程序的各种错误报告服务。我们的应用程序使用网络服务连接到服务器。

我们目前使用 Flurry 分析，但尚未使用他们新的错误报告功能。

如果您今天正在使用 Flurry 错误报告，您有什么反馈？

我试图将它与 Crittercism 和 Crashlytics 进行比较。因此，如果有人有使用 Flurry 错误报告和 Crittercism 或 Crashlytics 的经验，很高兴听到您的反馈。

谢谢。

Answer 1

虽然这个问题可能更适合论坛，但我会根据我对这些技术的经验以及从其他人那里听到的信息，尽力回答您的问题。首先让我们看看这些服务为崩溃报告提供了什么，然后让我们看看它们提供的与崩溃报告相关的内容。

Flurry提供(高级):

基于事件的指标分析(包括可选的基本崩溃报告)

服务器端符号化(但是上传符号是一个手动过程)

所有这些都很棒，但他们实际上根本不关注崩溃报告或它与其他指标的关系。

Crittercism提供(高级):

实时洞察报告(系统诊断、日志等)

智能崩溃/错误分组

带有可操作诊断信息的错误监控

记录非 volatile 错误

堆栈跟踪的服务器端符号化

与上述指标的位置相关性

崩溃报告的基于 session 的指标

客户端视角的网络性能数据(注意:这对于跟踪您的 Web 服务和其他 3rd 方服务(例如 Flurry)以了解它们的性能非常有用)

以上指标和数据的趋势

网络调用和崩溃/错误报告之间的连接(查看面包屑)

有关 Crittercism 提供的完整软件包的更多详细信息，请参阅上面的链接。有关某些功能的更多详细信息，请查看此 page .

所有这些都专注于让您全面了解您的应用对每个用户的表现。

Crashlytics提供(高级):

智能崩溃/错误分组

带有可操作诊断信息的错误监控

堆栈跟踪的服务器端符号化

记录非 volatile 错误

报告的实时洞察(系统诊断等)

Flurry 可以与更强大的崩溃报告解决方案搭配使用，根据我的经验，大多数人最终都会走这条路。

Crittercism 提供的不仅仅是崩溃报告，它与使用可操作数据优化应用程序的性能有关。他们还连接到移动就绪支持系统(例如 UserVoice 和 HelpShift)以更好地与客户沟通，以及多个工程任务管理系统(JIRA、Github、Pivo​​tal)。服务器端符号化、提取数据的 API、与构建工具(如 Jenkins)的简单集成提供了一个更成熟的解决方案。

Crashlytics 为普通开发人员提供了简单的集成。我听到开发人员提示，他们的构建过程更明确(例如使用 Jenkins 的东西)，他们的应用程序集成用于上传符号以进行符号化变得很麻烦。

他们还提供与 JIRA 和 Github 的集成。不知道是什么水平。

有些人喜欢 Crashlytics 的 UI，而其他人则表示它妨碍了。

希望这可以帮助。