转 理解与分析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-->