查看崩溃日志(2)

异常代码

在研究真实的闪回场景之前，还有一点需要强调: 有趣的异常代码.

您可以在先前代码的报告部分3的异常部分中找到异常代码. 一些代码更常见.

通常，异常代码以一些文本开头，后跟一个或多个十六进制值，该值正是闪回的基本性质. 从这些代码中，可以区分出闪回是由于程序错误，非法内存访问还是其他原因.

以下是一些常见的异常代码:

0x8badf00d: 发音为“ ate bad food”！ （用字母替换数字，看起来是否像: p）此代码表明应用程序由于看门狗超时而被iOS终止. 通常，应用程序花费太多时间来启动，终止或响应系统事件.

0xbad22222: 此代码表明VoIP应用程序由于重启频率太高而被终止.

0xdead10cc: 读为“死锁”！此代码表明该应用程序已终止，因为该应用程序在后台运行时会占用系统资源，例如通讯簿未释放.

0xdeadfa11: 读作“死亡倒下”！此代码表明该应用程序被用户强制退出. 根据Apple的文档，当用户长按开关按钮直到出现“滑动关闭”，然后长按“主页”按钮时，就会发生强制退出. 强制退出将生成带有0xdeadfa11异常代码的崩溃日志，因为大多数强制退出是由于应用程序阻塞了接口.

（注意: 在后台任务列表中关闭挂起的应用程序不会产生崩溃日志. 一旦挂起该应用程序，终止该程序是合理的，因此不会生成崩溃日志. ）

是时候展示您的技能了！好的！您已经了解了分析崩溃日志和修复错误的所有基础知识！

假设您刚刚进入Rage-O-Rage Co.，Ltd.工作. 该公司在App Store上有一个流行的应用程序，称为Rage Masters.

您的老板安迪（Andy）希望您帮助解决一些经常抱怨闪回的用户. 您的任务是研究这些崩溃，象征用户提供的崩溃日志，找到问题并修复.

您可以从此处下载应用程序的源代码.

（注意: 如果要自己重新生成崩溃报告，请遵循以下准则:

1. 下载源代码并在Xcode中打开项目文件.

2. 使用正确的配置配置文件连接到iOS设备.

3. 从Xcode工具栏中选择iOS设备，而不以模拟器为目标，然后构建应用程序.

4. 当您到达设备上的默认页面（应用程序的全屏图像）时，请立即单击Xco​​de上的“停止”按钮.

5. 关闭Xcode.

6. 直接在设备上打开应用程序.

7. 测试方案，完成后将设备连接到计算机，并通过Xcode获取崩溃日志. ）

场景1: 错误代码

来自用户的电子邮件: “大哥，您的应用很糟糕！我将其下载到我自己的iPod Touch和iPhone上，还下载到了我儿子的iPod Touch. 在所有设备上，在打开前闪回...”

另一封来自用户的电子邮件说: “我下载了您的应用程序，当我打开它时它就崩溃了. 真是可悲...”

另一封电子邮件更清楚地表明: “您的应用程序无法运行. 我将其下载到了妻子和我的设备上. 所有设备一打开便闪烁...”

好吧，不要灰心！这些评论中隐藏了哪些奥秘？让我们看一下崩溃日志:

您找到问题了吗？异常代码为0x000000008badf00d，以及以下报告:

这意味着应用程序启动时崩溃，并且iOS看门狗机制终止了该应用程序. 英俊！我找到了问题，但是为什么会这样？

接下来，阅读日志. 从下至上阅读回溯日志. 首先调用最底端的帧（第25帧: libdyld.dylib），然后调用第24帧，Rage Masters，main（main.m: 16），等等.

与应用程序源代码相关的框架最为重要. 忽略系统库和框架. 与代码有关的下一帧是:

当在应用程序的第35行执行代码时，应用程序崩溃: RMAppDelegate（RMAppDelegate.m: 35）类的didFinishLaunchingWithOptions: 方法. 打开Xcode并查看该行代码:

就是这样！同步调用Web服务吗？在主线程上！在应用程序上: didFinishLaunchingWithOptions: 方法？ !!谁写的代码？！

主线程上的网络调用使小猫感到难过.

无论如何，您都必须对其进行修复. 该调用必须异步进行，更理想的是，将在应用程序之后执行Web服务: didFinishLaunchingWithOptions: 返回YES.

在其他地方打电话可能需要更多修改. 现在，我们只需要防止应用程序回闪即可. 将来可以实现更好的设计. 用此异步版本替换上面令人讨厌的代码（以及下面的三行）:

场景2: 无法响应事件的按钮

一个用户说: “我无法在书签中添加一个rage master. 当我要添加它时，应用程序会闪回...”

用户说: “不能使用书签. 在详细页面上，单击书签按钮，应用程序会闪回！”

上述投诉不是很清楚，问题的原因必须多种多样. 查看崩溃日志:

异常代码为SIGABRT. 通常，SIGABRT异常是由对象接收到未实现的消息引起的. 或者简单地说，在对象上调用不存在的方法.

通常不会发生这种情况windows日志事件编号分类，因为A对象调用了方法B. 如果不存在B方法，则编译器将报告错误. 但是，如果使用选择器间接调用该方法，则编译器将无法检测到该方法是否存在于对象中.

返回崩溃日志. 它表明闪回发生程号0上. 这意味着最有可能在主线程上调用了未由对象实现的方法.

如果您随后阅读了回溯日志，则会发现代码仅是第22帧main.m: 16. 这没有太大帮助.

继续查看调出的帧，出现:

这不是您自己的代码. 但至少它证实了该对象调用了一个未实现的方法.

返回到RMDetailViewController.m文件，因为这是书签按钮执行操作的地方. 查找书签功能代码:

看起来不错. 再次检查情节提要（XIB文件）以确认按钮连接的正确性.

就是这样！在MainStoryboard.storyboard中，按钮连接到bookmarkButtonPressed: 而不是bookmarkButtonPressed（请注意，分号描述方法具有参数）. 只需修改上面的方法签名即可解决问题:

当然，您也可以简单地删除XIB文件上的错误连接，然后重新连接该方法，以便将XIB文件连接到正确的方法. 两种方法都可以.

另一个闪回问题已经解决，很好.

场景3: 表单上的错误

另一个用户抱怨“无法在书签视图中删除书签...”另一个用户抱怨了同样的问题，“当我尝试删除书签时，应用程序崩溃了……”

这些电子邮件无效，因此请检查崩溃日志！

这看起来与先前的崩溃日志非常相似. 是另一个SIGABRT例外. 您可能想知道是否是同一问题: 将信息发送到未实现相应方法的对象？

让我们看一下追溯日志，看看调用了哪些方法. 从底部开始，您的源代码最终被称为第6帧:

这是UITableViewDataSource的方法. 哈哈 ？！毫无疑问，Apple已经实现了此方法-您可以重载它，但似乎尚未实现. 此外，这是一种可选的委派方法. 因此，问题不在于调用尚未实现的方法.

再次查看上面的帧:

第5帧，UITableView调用了它自己的另一个方法deleteRowsAtIndexPaths: withRowAnimation: 然后是_endCellAnimationsWithContext: ，它看起来像是苹果的内部方法. 然后在Foundation框架handleFailureInMethod中发生异常: 对象: 文件: lineNumber: 说明: .

这些分析加上用户的抱怨，似乎在删除UITableView中的行的过程中存在一个错误. 返回Xcode. 你知道去哪里看吗？您可以从崩溃日志中得知吗？这是RMBookmarksViewController.m文件的第68行:

您找到问题了吗？给您一些时间仔细看看.

找到了！数据源呢？该代码在表视图上删除了一行，但没有修改其后面的数据源. 用以下代码替换上面的代码以解决问题:

完成了！走路，讨厌的虫子！！

场景4: 吃棒棒糖时倒叙！

用户电子邮件中说: “当愤怒大师吃完一根棒棒糖时，应用程序会闪烁...”另一位用户说: “我让愤怒大师吃完一根棒棒糖，然后它会闪烁几次！”

崩溃日志如下:

此日志与我们之前看到的完全不同.

这是来自iOS 6的低内存崩溃日志. 如前所述，低内存崩溃日志与其他类型的崩溃日志有很大不同. 它们没有指向特定的文件和代码行. 相反，他们绘制了崩溃期间设备上内存使用情况的图表.

至少，该标头与其他崩溃日志非常相似: 它提供事件标识符，CrashReporter密钥，硬件型号，操作系统版本和其他信息.

下一部分是低内存崩溃日志所独有的:

可用页数是指可用内存页数. 每页的大小约为4KB. 在上面的日志中，可用内存约为3,872 KB（或3.9 MB）.

可清除页是可以清除或重用的内存部分. 在上面的日志中，它是0KB.

最大进程是在闪回期间使用大部分内存的应用程序的名称. 在上面的日志中，它是您的应用程序！

进程显示闪回期间的进程列表，还包括内存使用情况. 包含进程名称（第一列），进程唯一标识符（第二位）和进程使用的内存页数（第三列）. 最后一列是每个应用程序的状态. 通常，崩溃的应用程序状态是最前面的. 这是Rage Masters，使用28591页（或114.364 MB）的内存-这太多的内存！

因此，最大进程的应用程序和最前面的状态是相同的，并且也是导致低内存崩溃的应用程序进程. 但是您可能还会看到一些示例，其中最大进程和最前端状态的应用方式有所不同. 例如，如果最大的进程是SpringBoard，则将其忽略，因为SpringBoard进程是一个显示主屏幕的应用程序，双击主屏幕按钮时将显示该屏幕，并且该屏幕始终处于活动状态.

发生内存不足时，iOS会向活动应用程序发出内存不足警告，并终止后台应用程序. 如果前台应用程序继续增加内存，iOS将终止它.

为了找到内存不足问题的原因，您必须使用Instruments分析应用程序. 如果您不知道该怎么做，可以看一下我们的教程. : ]此外，您还可以采用快捷方式来响应内存不足警告通知，以解决某些闪回问题.

返回Xcode并查看RMLollipopLicker.m文件. 这是实现吃棒棒糖的视图控制器. 查看源代码:

当用户单击运行按钮时，应用程序启动后台线程，多次调用lickLollipop方法，然后更新界面以反映棒棒糖的数量. lickLollipop方法从属性列表文件（PLIST）文件中读取一个长字符串，并将其添加到数组中. 这些数据并不重要，可以重新创建而不会影响用户体验.

优良作法是在不影响用户体验的情况下使用可以清除和重建数据的所有情况. 这样可以轻松释放内存并减少内存不足警告.

那么，如何提高代码质量？实现didReceiveMemoryWarning方法并按以下方式处理数据:

万岁，您研究了4个崩溃案例！您的应用程序更加完整，您已经学习了一些重要的调试技术.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-195623-2.html