【译】理解与分析ios应用的崩溃报告

 

理解与分析ios应用的崩溃报告

 

源网址：

http://developer.apple.com/library/ios/#technotes/tn2151/_index.html

      当一个应用程序崩溃时，创建一份“崩溃报告”对于理解崩溃是如何引起的非常有用。本文档包含有关如何识别，了解并解释崩溃报告的基本信息。

    简介

      当一个应用程序在一台iOS 设备上崩溃时，一份“崩溃报告”将在该设备上次创建并存储起来。崩溃报告描述应用程序是在何种条件下崩溃的，大部分情况下包含一份当前正在运行线程的完整的堆栈跟踪，通常这在调试问题时非常有用。如果你是一位iOS 开发者，你应该查看这些崩溃报告，了解导致你的应用程序崩溃的原因，然后修复它。

      内存不足报告与其他的崩溃报告的不同之处在于这种类型的报告没有堆栈跟踪。当一个内存崩溃发生时，你必须研究一下你的内存使用方式以及你对于内存警告的处理方式。你可能会发现本文档为你指出几种内存管理方式是非常有用的。

      包含堆栈跟踪的崩溃报告需要先进行符号化（symbolicated）才可以进行分析。符号化的过程是将内存地址替换为便于人们阅读的函数名称和行号。滑假如你通过Xcode的Organizer窗口获取崩溃日志，那么该报告将在几秒钟后自动进行符号化。否则你需要将.crash文件导入到Xcode的Organizer进行符号化。你可以通过符号化来了解更多细节。

    了解内存不足报告

      当监测到内存不足时，iOS的虚拟内存系统依靠应用程序间的合作来释放内存。内存不足的通知被发送到所有正在运行的应用程序，并作为内存释放的请求来进行处理，以期望降低所使用的内存总量。如果内存的压力始终存在，那么系统可能会终止一些后台进程来降低内存压力。如果可以释放足够多的内存，那么你的应用程序将继续运行而不会产生崩溃报告。如果不可以，那么你的程序将被iOS终止，因为此时已没有足够的内存来满足应用程序的需求，一份内存不足的报告将被产生并存储在设备中。

      内存不足报告与其他崩溃报告的不同之处在于它里面没有应用程序的堆栈跟踪。每个进程的内存使用量依据内存页面的数量进行报告，每个内存页面量的大小为4KB。你将会看到“抛弃（jettisoned）”紧跟在iOS为了释放内存而终止的进程名称后。如果你看到它紧跟在你的应用程序名称后面，那么可以确定这个应用因为使用了太多的内存而被终止。否则，应该不是内存压力引起的崩溃。你可以通过查看.crash文件（下一节中进行描述）获取更多信息。

      当你看到一个内存不足报告时，你更应该研究一下你使用内存的方式和你对内存不足警告的处理方式，而不是去关心在程序终止时你的哪一部分代码被执行了。内存分配帮助（Memory Allocations Help）列举了如何使用泄露工具（Leaks Instrument）来发现内存泄露，以及如何使用分配工具（Allocations Instrument's）的标记堆功能来避免被抛弃的内存。内存使用性能指导方案（Memory Usage Performance Guidelines）讨论了像其他内存使用秘诀一样的适当的方案来响应内存不足通知。同时也建议你看一下WWSC2010中的关于使用工具进行高效内存分析的视频（Advanced Memory Analysis with Instruments）。

      注意

      泄露和分配工具不能跟踪显存。你需要使用VM Tracker工具（包含在分配工具模板中）来运行你的应用以便观察显存的使用情况。VM Tracker默认是禁用的。为了在你的应用程序使用VM Tracker，请点击工具，选中“自动快照Automatic Snapshotting”标志或者手工按下“获取快照（Snapshot Now）”按钮。

    分析崩溃报告

      和内存不足报告不同，大部分的崩溃报告都包含每一个线程在程序终止时的堆栈跟踪。本节将讨论这类报告。

      符号化

      在崩溃报告中最令人感兴趣的部分是在你的应用程序执行终止时的堆栈跟踪。这个跟踪和你在调试器中停止执行时的类似，但遗憾的是这里没有提供被认为是符号的方法或函数的名称。取而代之的是16位的内存地址和它所指向的你的应用程序或系统框架的可执行代码。你需要将这些地址映射到符号中。崩溃日志在输出时并不包含土豪信息，你需要在你分析日志前进行符号化处理。

      符号化——将堆栈跟踪地址转化为源代码方法名称及行号——需要上次到苹果应用商店的应用程序的二进制文件以及构建二进制文件时产生的.dSYM文件。这些必须是精确匹配的，否则你的报告将不能完整地符号化。基本要求你保持每个分发给用户（忽略那些分发的细节）的构建和它的.dSYM是一致的。

      注意：

      你必须保存应用程序的二进制文件和.dSYM文件以便于完整地符号化崩溃日志。你应该打包每一个你所提交到iTunes Connect中的构建。.dSYM文件和应用程序的二进制文件应该绑定到一起，不管是基础版本的构建还是后续版本的构建。即便是相同的源代码，不同构建的文件也不会弄混。假如你使用“构建并打包”命令，那么它们将会被自动放置到一个合适的位置。虽然任何位置都可以用Spotlight搜索到。

      Xcode的“打包（Archive）”命令使保持二进制文件和.dSYM匹配变得很简单，当你使用打包命令（通过点击产品（“Product”）-）打包（Archive）或是按下Shift+Command+B），Xode将会把应用程序的二进制文件及包含符号信息的.dSYM文件收集到一起，并存储到你的主目录文件夹下的一个合适位置。你可以在Xcode中的Organizer下的“已打包（Archived）”中知道你所打包的所有应用程序。Xcode在符号化崩溃日志时会自动寻找打包的应用程序，在确认你要的发布应用程序和.dSYM文件匹配的情况下，你可以将它们打包，直接提交到ITunes Connect。

      如果Xcode拥有产生崩溃日志的应用程序的二进制代码和.dSYM文件，那么它将自动进行符号化。Xcode Organizer符号化所需要提供的是崩溃日志及相应的二进制文件和.dSYM文件。打开Xcode Organizer，选择“设备（Devices）”选选看，选择边栏顶部“文库（LIBRARY）”下的“设备日志（Device Logs）”，点击导入按钮，选择需要符号化的.crash文件，当这些步骤完成后，Xcode将自动符号化崩溃日志并显示结果。

异常代码

在崩溃日志的16行中，你可以看到以一个或多个16进制值开头一行，这些数字代表的是处理器的特殊代码，可以为你提供更多的崩溃的本质信息。你可以通过这些代码辨别应用程序的崩溃是由于程序错误（例如，错误的内存访问，发生异常，等等）还是其他的一些原因，例如：

  1）异常代码0x8badf00d表明应用程序已被iOS终止，原因是watchdog超时引起的。该应用程序花了太长的时间加载，终止或响应系统时间。一个常见的原因是在主线程中进行网络同步（synchronous networking on the main thread.）。

  2）异常代码0xbad22222表明一个VoIp应用程序因其频繁重启而被iOS终止，。

  3）异常代码0xdead10cc表明一个应用程序被iOS终止，因其在后台运行时锁定了系统资源（如联系人数据库）。

  4）异常代码0xdeadfa11表明一个应用程序被用户强制退出。当用户第一次按下开关键直到“移动滑锁关机”屏幕出现，然后按下Home键。用户之所以这么做的合理假设是应用程序变得翻译迟钝，但不是肯定的，任何应用程序都可以强制退出。

提示：

从多任务窗口中终止一个暂停的应用程序不会产生崩溃日志。一旦一个应用被暂停，它有资格被iOS在任何时间终止，因此不会产生崩溃日志。

<!--EndFragment-->