我为什么使用 Crashlytics——第一部分

我为什么使用 Crashlytics——第二部分

引言

在编写新的 Greenfield Android 应用时，或者在帮助客户处理他们现有的已上线应用程序时，我经常被问到我使用的是哪些库。当然，我总是依赖一些关键库，例如 Dagger、Otto/RxJava、Retrofit 等，但有一个我绝对会使用的库是 Crashlytics。

Crashlytics 是 Twitter 提供的一项免费服务，用于收集您的崩溃以及各种其他信息。它非常容易设置和安装，并且一旦安装即可立即开始提供价值——是的，即使在开发过程中。它是完全免费的，拥有无限的应用、无限的用户、无限的崩溃、无限的密钥等——一切都是免费的。我不是在开玩笑，这是我安装的第一件事。没有崩溃报告，我根本不知道我的应用程序在实际使用中（生产环境）发生了什么。

为什么崩溃报告很重要

当您的应用程序在用户设备上崩溃时，您需要知道。原因很简单——发生了您未预料到的事情。也许您使用了发布版本不支持的 API（例如，在 API 级别 15 上使用了 Renderscripts InstrinsicBlur，而该 API 直到 17 级才发布）。当这种情况反复发生时，用户就会开始对您的应用程序失去信心，然后差评就开始涌入。

通过监控您的崩溃，您可以评估特定崩溃造成的风险级别。例如，假设您发布了应用程序的 2.0 版本。在此版本中，您在一个特定的屏幕上引入了一个错误。在开发和测试过程中，您从未遇到过此问题，但一旦向现有用户发布更新，您就会收到大量崩溃报告。通过崩溃监控工具，您可以观察到崩溃发生在特定屏幕上，因为工具会提供崩溃的堆栈跟踪。出于某种原因，崩溃发生在 Fragment 的 getActivity() 调用中——确切地说，是一个 NullPointerException。经过进一步调查，您会意识到/想起 Fragment 中所有的 getActivity() 调用都可能返回 null（并且在生产环境和大规模使用时确实会返回）。然后，您将实现 null 检查，并发布一个热修复版本来解决当前的问题。这是我为各种客户亲身经历过的真实案例。没有崩溃报告工具，我们永远无法捕获它。

并非所有崩溃报告工具都一视同仁

在 Crashlytics 之前，我安装过各种其他崩溃报告工具，例如 Bugsense、Crittercism、ACRA、HockeyApp 等。我遇到的问题很多，而且因我使用的工具而异。我遇到的一些问题包括：

• 该工具是托管的，而且费用高得离谱
• 该工具是免费的，但除非我构建后端 API 来支持它，否则无法扩展
• 集成相当麻烦
• 账户管理非常痛苦，几乎不存在
  • 例如
    • 团队
    • 组织
• 共享错误报告困难
• IDE 集成不存在
• 如果我使用 Proguard，我的堆栈跟踪就会被混淆，导致我无法修复问题。

在 Crashlytics 出现之前，我通常使用 ACRA 或 Bugsense。ACRA 适用于预算很少或用户基数非常小的较小应用程序，而 Bugsense 适用于大型客户。我曾尝试过几次使用 HockeyApp，但我的客户从未抽出时间设置账户，而且发现他们更喜欢 Bugsense，或者更喜欢 ACRA 的免费成本。

ACRA 工作得不错，但有一件事我注意到，我从未检查过崩溃被发送到的 Google 表格。不幸的是，由于崩溃在 Google 表格中的存储方式，我发现它们不适合阅读。检查新崩溃的过程是轮询式的，我发现这很糟糕。当然，也有一些工具可以帮助解决其中的一些问题，但解决方案远非完美、优雅或快速。我也缺少我想要的统计数据，例如受影响的 Android 2.x 用户与 Android 4.x 用户等的百分比。这类数据有助于识别崩溃的影响。如果您的用户群 95% 是 Android 4.x 并且崩溃发生在 Android 2.x 上，那么您的影响相当小。然而，当情况相反时，您会发现大量的用户受到崩溃的影响，此时就需要做出不同的决定（热修复等）。关键在于，ACRA 并不是像其他高级崩溃报告工具那样一个完全成熟的解决方案。

Bugsense 和 Crittercism（以及其他服务）解决了 ACRA 的许多问题，但我发现价格点几乎让我的所有客户都望而却步。这些服务的一个很棒的功能是推送式系统，可以通知您何时发生新的崩溃。可以通过电子邮件等方式通知。无需手动登录检查，这节省了大量时间。我的客户要么拥有非常大的 Android 应用（数百万甚至数千万的安装/用户），要么非常小（新创业公司等）。价格点对两者都存在问题。在较低端，新创业公司正试图在各个方面省钱，他们不想为崩溃报告付费。每一分钱都会影响他们的运营资金。因此，我们通常会选择 ACRA 这样性能稍差的解决方案。在高端，我们遇到了另一个问题——应用程序规模。这些客户的规模之大，以至于他们所属的价格等级直接写着：“致电我们获取报价”。这通常相当于每月数万美元的许可费。虽然这些大客户能够支付（有些也支付了），但他们并不真的喜欢为崩溃报告解决方案支付这么多钱。

去年 Crashlytics 在 Android 上发布时，似乎好得令人难以置信，但事实并非如此。考虑到 Crashlytics 是一项免费解决方案，能够处理大规模应用程序，并为我的大中小型客户提供所需的指标——这简直是明智之举。Crashlytics 的用户管理也非常简单。作为一名顾问，我能够一次性参与多个 Crashlytics 的“组织”，只需一次登录。目前我有一个登录，并且参与了七个不同的团队，这些团队在不同行业拥有不同的应用程序。Crashlytics 提供了一种推送式机制（在 IDE 和电子邮件中），以便在发生新崩溃时通知我。

幸运的是，去年我被邀请参加了面向 Maven 用户和 Android Studio 用户的 Android 私有 Beta 测试。我抓住了这个机会，并带上了我的客户 MyFitnessPal（Google Play 上排名第一的免费健康与健身应用程序）。在 MyFitnessPal，我们现在使用 Crashlytics 作为管理崩溃和评估新版本发布后风险的主要工具。

在生产环境中使用 Crashlytics

在使用 Crashlytics 时，我们获得了访问其 Android 开发人员的私有门户（现已公开）的权限。这使我们能够访问提供插件安装说明的区域。通常，此类说明通过网页和几个步骤提供。Crashlytics 则不同。他们在网站 www.crashlytics.com/downloads/plugins 上提供了功能齐全的导览。您可以选择您的 IDE 或构建工具，如下图所示。

我通常选择 Android Studio 或 IntelliJ，因为它们是我首选的 IDE。根据我正在为哪个客户工作，我可能需要使用不同的 IDE。需要注意的是，如果您不使用这些 IDE 中的任何一个，您仍然有办法，可以选择您喜欢的构建工具，如下所示。

选择 IDE 的好处是可以为该 IDE 安装一个插件，Crashlytics 会为每个 IDE 引导您完成该过程。这是 Android Studio 导览中的一个示例截图。

安装插件后，您可以通过确保选中 View → Toolbar 来打开 Android Studio 中的工具栏来查看插件（对于其他 IDE，请参阅文档）。打开此项后，您将看到 Crashlytics 登录页面，如下所示。

选择电源按钮，插件将检测您当前打开的应用程序，然后您将通过设置过程。非常重要的一点是，作为一名顾问，参与多个团队（在 Crashlytics 中称为“组织”）对我来说非常重要。在设置项目时，我会被问到我想将这个新应用程序归入哪个组织。从下面的列表中可以看到，我参与了几个组织。我可以选择我希望该应用程序所属的组织，然后就可以开始了。

选择组织后，Crashlytics 会告知您它将更新一些文件。这太棒了！我可以预览更改，Crashlytics 会为我实现这些更改。太棒了！这是设置应用程序时的样子。

这里需要注意的一点是，Crashlytics 插件能够检测到我这个项目正在使用 Gradle 作为构建工具，并且正在为我实现正确的 Gradle 语法！我在设置 IDE 时没有从选项中选择 Gradle，我只选择了“Android Studio”，Crashlytics 就完成了其余的工作。

点击下一步按钮后，它会通知您需要运行您的应用程序，以便 Crashlytics 检测到它正在运行。

应用程序构建并部署后，Crashlytics 插件将识别该应用程序，并显示崩溃界面，如下所示。

Crashlytics 识别您的应用程序后，甚至会为您提供如何强制崩溃的说明。一旦崩溃开始出现，您就可以通过插件看到它们，如下所示。

点击该问题（上图中显示的 MainActivity.java 中的崩溃）后，您将被带到基于 Web 的问题详细信息屏幕，在那里您可以获得有关导致崩溃的问题的大量信息。仅在此屏幕上就提供了以下数据：

 

1.	应用程序和包名	出现此问题的应用程序和包名。
2.	错误位置	源代码中发生崩溃的位置。
3.	总崩溃次数	此问题报告的总崩溃次数。
4.	总用户数	遇到此问题的唯一用户总数。
5.	打开/关闭开关	将此问题的状态在当前应用程序版本中切换为打开或关闭。如果在关闭问题后，对于同一应用程序版本又收到了崩溃，问题将保持关闭状态。但是，如果您发布了新版本的应用程序并且崩溃再次发生，则会打开一个新的问题。
6.	崩溃图	此图表显示了一段时间内每天发生的崩溃数量。
7.	分享选项	通过 Twitter、电子邮件/复制短问题链接等选项，可以将问题发送给其他人进行审查。
8.	Android 设备细分图表	这些图表显示了受此问题影响的各种设备。
9.	Android 操作系统图表	这些图表显示了遇到此崩溃的各种 Android 操作系统。
10.	已 Root 设备百分比	显示了遇到此崩溃的已 Root 设备的百分比。
11.	可用空间	发生此崩溃的设备的平均可用空间。
12.	可用 RAM	发生此崩溃的设备的平均可用 RAM 量。
13.	应用聚焦	崩溃发生时应用程序处于聚焦状态的百分比。
14.	接近传感器开启	崩溃发生时设备接近传感器开启的百分比。
15.	可展开的崩溃堆栈跟踪	用于崩溃的可展开堆栈跟踪浏览器。在此问题报告区域，您可以检查导致崩溃的代码的各种方面。
16	注释字段（未显示）	底部有一个注释字段，您和您的团队可以在其中为问题添加各种注释。

利用这些数据，您可以确定这是否是一个关键崩溃，以及是否应该修复。我通常会重点查看崩溃次数、受影响用户数、设备和操作系统细分。Crashlytics 为每个问题提供自动严重性级别分配，这将帮助您确定如何处理。

那么，您可以使用 Crashlytics 的所有这些数据做什么？在本系列的第二部分中，我们将深入探讨这些数据如何帮助您以最小的努力修复最关键的崩溃，并为您的业务创造满意的用户/客户。我们将在下周发布第二部分——敬请期待！

在此期间，了解更多关于Crashlytics for Android 的信息。