为何应该关心崩溃报告

设想一个用户安装了一个移动应用程序的情况。由于抱有很高的预期，该应用程序被频繁地使用，或许在前几个星期一天使用好几次。应用程序创建的数据以及用户投入该应用程序中的精力在不断积累。然后，突然之间，应用程序崩溃了。用户的数据现在被损坏或丢失。尽管等待了好几天，该应用程序仍未更新，这些问题仍未得到解决。用户为该应用程序提供了一星评价和批评性评论，然后放弃了该应用程序。即使以后某个时刻提供了修复程序，用户也不可能返回再使用该应用程序。

作为应用程序供应商，您投入了数月时间来设计和开发该应用程序，然后又花费了几星期测试它，最后才将该应用程序提交到应用商店。目前为止，评论是正面的。许多一星评价可能是打消潜在用户的积极性的最重要因素。最糟的情况是，没有配置信息可用于理解和诊断该问题。您可以尝试联系用户来收集数据（设备型号、操作系统版本、应用程序版本、堆栈轨迹等），但您有时可能甚至无法联系到用户。隐私、庞大的用户群等因素和其他原因可能阻止您建立联系。即使您可以联系一些用户，他们也可能不知道如何再现该问题。获取日志和其他设备信息可能需要大量的工作和技术经验。用户可能无法向您提供此数据。

这种情形真实存在，而且十分可怕。您的应用程序由于崩溃而获得了负面评价，而且没有崩溃细节，在您应用程序声誉骤然下跌时，您会束手无策。即使您修复了这个问题，可能也已经太迟了 - 人们已陆续远离您的应用程序。

如果有一种途径自动检测崩溃，检查崩溃的细节和发生崩溃的条件，以及发生崩溃的时间，而无需联系用户，那就太好了。

在本文中，您将了解：

• Android 和 iOS 的崩溃细节
• 崩溃报告
• IBM Mobile Quality Assurance for Bluemix (MQA) 和 IBM Worklight Quality Assurance (WQA)
• 如何使用 MQA 启用崩溃报告
• 如何在 MQA 中检查崩溃

崩溃

Andriod

Android 日志系统提供了一种机制来收集和查看系统调试输出。来自崩溃的堆栈轨迹和使用 Log 类从应用程序获得其他消息输出都会记录下来。您可以使用 LogCat 查看并过滤这些日志。日志级别示例包括详细信息、调试、信息、警告和错误。

LogCat 是 Android 日志系统的一部分。它可以从 Dalvik Debug Monitor Server (DDMS) 或 Android Debug Bridge (ADB) shell 内调用。

Eclipse 中的一个 LogCat 视图的示例如图 1 所示。图中显示了 Java NullPointerException 所导致的一次崩溃的堆栈轨迹。

图 1. Eclipse 中的 LogCat 视图

LogCat 视图中的每个条目包含以下信息：

• 日志级别
• 日期和时间
• 进程 ID
• 线程 ID
• 应用程序
• 标签
• 文本

标签帮助您识别或过滤消息。可以按照应用程序、日志级别等来过滤数据。

iOS

当 iOS 中的应用程序崩溃时，将会创建一个崩溃报告并将该报告存储在设备上。崩溃报告中的堆栈轨迹包含与方法名称和行号对应的十六进制地址。十六进制地址本身对用户没有任何意义。因此，在分析堆栈轨迹之前，需要将这些地址解析人类可读的符号，比如方法名称和行号。此过程被称为符号化。符号化需要应用程序二进制文件和 .dSYM 文件，该文件是在构建该二进制文件时生成的。应用程序二进制文件和 .dSYM 文件需要完全匹配。

崩溃报告

除了日志和堆栈轨迹之外，其他信息在诊断崩溃时可能也很重要，比如：

• 应用程序的版本
• 平台（比如 iOS、Android 等）
• 崩溃的日期和时间
• 崩溃期间设备的详细状态（电池级别、网络状态、屏幕朝向等）

在崩溃发生时向应用程序供应商提供此信息的过程被称为崩溃报告。

IBM Mobile Quality Assurance for Bluemix (MQA) 和 IBM Worklight Quality Assurance (WQA) 都支持移动应用程序测试和用户验端验证：

• 向移动测试设备分发最新的构建版本
• 应用程序内错误报告
• 自动化的崩溃报告
• 应用程序内用户反馈
• 情绪分析

本文的剩余部分将会使用 MQA 作为 Bluemix SaaS。但是，内部部署的 WQA 产品也能执行本文中的所有操作。

使用 IBM Mobile Quality Assurance for Bluemix 启用崩溃报告

要使用 MQA 启用崩溃报告，首先需要在 MQA 中注册您的应用程序，然后为您的应用程序装备一个 MQA SDK 库，最后重新构建该应用程序。图 2 演示了这些步骤。

图 2. 启用崩溃报告的步骤

注册您的应用程序

要在 MQA Web 仪表板中注册您的应用程序，需要指定您应用程序的名称和平台（Android 或 iOS）。MQA 为您的应用程序生成一个应用程序密钥来惟一标识它。还为您提供了一个下载 MQA SDK 的链接。SDK 可用于原生 Android、原生 iOS 和 Worklight JavaScript 应用程序。

装备您的应用程序

有了应用程序密钥和 SDK 库之后，就可以装备您的应用程序了。这里所说的装备是这样一个过程：在您的应用程序中包含 SDK 库，指定您的惟一应用程序密钥，根据需要调用 SDK API。

您可以为应用程序装备预生产或生产 SDK 库。当应用程序仍处在测试阶段，仅有一小群人在使用它时，预生产库是理想选择。在默认情况下，使用具有预生产库的应用程序的测试人员会被提示登录到应用程序中。登录之后，MQA 就会开始记录谁报告了哪些错误和问题。生产库包含一个 MQA 特性子集，这些特性被设计为在应用程序发布后使用，而且由客户使用。生产库不会提示用户登录到 MQA。MQA 会匿名报告所有数据。生产模式会尊重用户的隐私，使用日志、会话数据和崩溃报告从应用程序收集较少的细节。

表 1 显示了预生产和生产 SDK 库中提供的特性。

表 1. SDK 库

重新构建应用程序

最后一步是重新构建应用程序二进制文件。重新构建应用程序二进制文件后，就可以分发应用程序进行测试，或者将应用程序发布给最终用户。

检查崩溃摘要

当测试人员或最终用户使用装备的应用程序时，您就可以开始在 MQA 中看到会话。只要应用程序在移动设备或模拟器中启动，就会报告相关会话。图 3 显示了应用程序的来自所报告会话的基本质量指标。如果应用程序崩溃，那么这些指标就会和支持细节一起报告给 MQA。

图 3. 应用程序质量摘要

可以单击此页上的会话数量来检查每个会话的细节。对于报告了崩溃的会话，还会提供堆栈轨迹。

会话报告的顶部部分显示了设备的状态信息，这些信息包括：

• 会话持续时间
• 用户（测试人员）
• 应用程序和 MQA 库的版本
• 设备配置
• 网络配置
• 电池级别和状态
• 屏幕分辨率和朝向
• 电话配置
• 地点

图 4. 应用程序会话细节

单击任何图标，就会打开相关的细节页面。图 5 显示了会话时间的细节。

图 5. 会话时间的细节

图 6 显示了会话细节页面的底部部分。它显示了与一次崩溃关联的堆栈轨迹。

图 6. 崩溃细节

自定义报告

可配置要显示会话的哪些信息。图 7 显示了 Condition Filtering 页面，您可以在其中选择想要在报告上显示的信息。

图 7. 条件过滤选择

结束语

在本文中，您了解了：

• 崩溃报告的重要性
• 如何在 MQA 中启用崩溃报告

还了解会话和崩溃的摘要和细节，以及来自崩溃的堆栈轨迹。

崩溃报告指示 MQA 的许多功能之一。MQA 还提供了其他指标，比如错误和用户反馈。即使您的应用程序没有发生崩溃，人们可能仍然不喜欢它并在应用商店上发表这一看法。应用商店情绪分析提供了用户对您的应用程序的喜欢程度的深入信息。MQA 也提供了此功能。

有了这些功能，您的应用程序不仅像桥梁一样坚固，而且还会引人注目！

参考资料

学习

• 进一步了解 IBM Worklight Quality Assurance（Mobile Quality Assurance 的内部部署版本）。
• 查阅 IBM Mobile Quality Assurance 入门，获取 MQA 简介。
• 查阅 开始在 Bluemix 上使用 MQA，获取 MQA 作为软件即服务的更多信息。
• 有关在 Bluemix 上使用 MQA 的详细信息，请参阅 IBM Mobile Quality Assurance for Bluemix V6.0
• 查阅 准备配置应用程序以创建报告，了解如何注册应用程序，下载和安装库等。
• 查阅 IBM Bluemix 是什么？
• 访问 IBM Bluemix，在云上开发您的下一个应用程序。
• 访问 IBM MobileFirst 获取 IBM 移动产品的技术资源。
• 访问 Bluemix 专栏：在这里您可以获得最新最实用的 Bluemix 资讯和技术资源。
• 访问 IBM developerWorks 中国网站 Rational 专区，获得关于 IBM Rational 软件交付平台（Rational Software Delivery Platform）产品的技术资源和最佳实践。