Related posts:

1. 15个网站设计和开发的Chrome插件
2. 在Windows上安装配置Redis及Python使用
3. 怎样设计一个好的URL

相关文章

• 阅微堂博客系统演变史
• 阅微堂WordPress主题的一些更新
• 拥抱社交化评论系统
• 启用七牛云存储解决流量问题
• 博客启用InstantClick

正如专利名称所显示的一样，这一种辨别身份的技术主要是基于 iPhone 用户设备里的联系人名单。据了解，新技术会通过用户联系人名单里的绑定头像进行辨别，如果联系人没有绑定头像，系统会分别针对男性和女性自动显示相关的默认头像。另外，用户在聊天时还可以在自己的设备上看到对方是否已经收到、又或者是正在准备发送信息的画面。

苹果还表示，这一项功能对于电子邮件同样有效。对于那些经常需要进行群聊天的商务人士，这一项发明可谓作用巨大。由于用户在商务领域经常会遇到各种各样的（准）合作伙伴，因此他们在进行群聊天的时候如果能够迅速辨别对方身份，有助于双方进行更深入的商务讨论。

依照每年一度的惯例，谷歌创始人在公司网站上发布了今年的公开信。信中谈到了谷歌现在广泛开展业务的原因，以及投资新奇项目背后的理念。以下为谷歌“2013年创始人公开信”全文：

谢尔盖与我建立谷歌，是因为我们想要“开发服务，让它们改善尽可能多的人的生活”（见2004年招股书中创始人的一封信）。一直以来，我们都在坚持这个使命，把那些用户真正喜爱的新技术作为公司未来的赌注——从谷歌搜索到谷歌邮箱、Chrome、YouTube以及安卓。我们在较短的时间里参与到了很多领域中，所以人们自然会问，今天的谷歌到底算什么，未来的目标是什么？这是个好问题。

搜索不止......

谷歌的核心是信息。知识会让人类进步，这个信念激励着我们。在还是孩子的时候，我俩就有很大的好奇心。我记得自己曾用大量时间阅读书籍和杂志，或是在家拆东西，想搞清楚它们运作的机理。今天，搞清楚事情的过程容易多了。你只需要打开谷歌搜索就能发现答案。搜索之所以有这样重要的意义，是因为即便是小小的知识就能让事情发生巨大的改变——无论是日常生活中看似琐碎的小事，例如避开塞车，还是说更重要的事情，例如非洲农民在思考如何能挽救自己的马铃薯庄稼。

谷歌搜索上的活动量级是惊人的。每月有超过1000亿次搜索（而其中15%的搜索内容是全新的），而且现在我们将索引升级到了以数秒为间隔，确保总是可以给人最新的结果。为了让生活更轻松，我们逐渐可以直接给出问题的答案。例如，像“哪个湖泊全球最深？（答案是西伯利亚的贝加尔湖，深1741米）”，“我的航班几点起飞？”，或者“一块薄饼有多少卡路里？”这样的问题都可以得到答案。而且我对我们在语音搜索上取得的进展非常激动，这项服务现在可以支持超过38种语言，包括新近加入的越南语和泰语。发问的最快、最简单方式通常都是说话，尤其是在使用移动设备时。

不过，从很多方面看，我们离打造自己梦想中的搜索引擎这个目标还有万里之遥。这种搜索引擎应该是在用户需要的时候，无需他们花什么力气，就能提供正确信息的工具。之所以说离这个目标很远，部分是因为从深层次上理解信息是个难题。Google Now正在应对这个挑战。它甚至可以在用户不发问的情况下提供信息，可以让人免去翻遍收件箱查找物流需要的订单号码这种苦恼，而把号码直接显示在屏幕上。基于兴趣的Google+推荐，也可以提供大量信息。我总是可以看到高度相关的东西，我最近在Google+中谈到过风筝冲浪，接着就看到了这段关于风筝冲浪历史的YouTube视频。

虽然它尚处早期，我们还是在背景理解上获得了长足的进步。如果想要改进人机交互，这就是至关重要的一点。想一想你上班的路程，你需要非常方便地看到交通信息，这样就可以做好准备，避免堵车。如果你要去赴另一个约会，你就需要知道从现在所在的位置要怎么走（而不是非要在屏幕上输入地点信息）。更丰富的背景也会让搜索更加自然，而不再是手动把一堆关键词敲到电脑里。我们离目标越来越近了：你可以直接问艾菲尔铁塔有多高，“它”是什么时候建立起来的。“它”在不同的背景里可以指代很多东西，理解了“它”代表的是什么，我们就可以让搜索变得可以交流。

生活在一个多屏世界中

由于设备的增多，确保人们能有效地在其间浏览就变得越来越重要。我们的Chrome浏览器可以流畅地运行在各种设备上，这款产品已经拥有了超过7.5亿用户，非常快，非常安全。在台式机上打开地图，当切换到移动设备时，同样的页面会被保留下来，让你继续查看。

想想照片吧：它们无疑可以成为多屏世界里的大麻烦。不同的设备上存储着不同的照片，找不到也无法分享，我们都体会过这种沮丧的滋味。G+可以即时将照片传导网上，方便你在任何设备上查看。更妙的是，如果手机丢了，也不会影响到你的照片。

在不到6年的时间里，有超过10亿部安卓设备被激活（而且这一速度还在加快）——为全球越来越多的应用开发者打造了一个绝佳的平台。看到这个产业链腾飞起来是非常令人激动的。在2013年，安卓开发者从用户处挣到的钱，平均起来是前一年的4倍还多。我们现在将安卓移植到手表这样的可穿戴产品上以及汽车上，让查找方位、打电话或听音乐变得非常容易。

Google Play网店背后的理念是相似的。用户可以在这里一站式下载应用、电影、书籍以及音乐，而且可以省去同步工作在任何设备上查阅这些内容。你在平板电脑上听的歌，切换到手机上同样存在。还有最近的谷歌电视棒Chromecast，用它我们就能更方便地在家里或朋友那里观看Google Play或是Netflix上的电影。你可以扔掉所有遥控器，靠手机或平板电脑控制电视，使用习惯完全和上网一样——就像在网上看YouTube一样。最妙的是，这款设备仅售35美元。

现在，如果没有优秀的设计，这一切都只是空想。我记得自己在密歇根大学上过一节关于实用性的课程。学生们必须挑选一个自己非常熟悉的项目（我选的是邮件），估算出让它开展不同的任务，需要专家开发多长时间。我从中获益颇多，明白了打造优秀的、有效的界面是件难事，比你想象得更贴近工程师的工作。这里放一个标签，那里放一个下拉菜单。你扔给人们越多的选项（即便从来不会被用到），人们完成工作的时间就越长。到现在人们还会谈论谷歌首页的简洁，说这是我们最初获得成功的一大因素。同样的原则没理由不能用在我们其他的产品上，特别是现在，有了如此多的设备和选择，有了如此多的机会让人分心。

上网是个尚未解决的问题

当然，这一切的前提都是假设你已经是20亿网民中的一员。其实在这之外还有50亿人。今天的世界有如此丰富的信息，但还有三分之二的人口却没有最基本的互联网连接，这不得不说是个悲剧。这就是为什么我对启动了“气球计划”（Project Loon）特别激动的原因。这个理念是在最偏僻的地区打造一个气球联成的网络（它们的高度是商用飞机的两倍），为乡村和偏远地区提供网络连接。很快，巴西东北部就会出现首个上网的教室，靠得就是“气球”。而且随着项目的深入开展，我们还希望能把这种联网的能力带给越来越多的人——创造出我们从未想过的机遇。

创新与再创新

有一只小而专注的团队，用不寻常的办法从基础做起，成就一番事业，这种感觉非常了不起。然而随着时间流逝，我意识到让团队斗志昂扬、充满干劲是件非常难的事情，因为大多数人接受的不是这种“登月”式的教育。他们倾向于假设事情是不可能的，或是会被失败吓倒。这就是我们为什么要投入如此多的精力，在谷歌招聘独立思考的人，并设定宏大的目标。因为只要你能找到合适的人，梦想够大胆，一般都能将目标实现。而且即便你失败，应该也能从中获益不少。

另外一种情况也真实存在。那就是很多公司会逐渐习惯自己做事的方式，只会做渐进式的改变。时间一长，这种渐进主义就会导致走上歧途，尤其是在科技行业，因为改变本身更像是种革命，而不是进化。这就是为什么我们要持续从长远出发，在下一代产品上押重注。在医疗保健领域，我们有Calico——这是一间由Genentech前任首席执行官Art Levinson带领的新公司，专注于健康和长寿；还有智能隐形眼镜Iris，可以改变糖尿病患者的生活。我们近期还收购了Nest，这家公司让暖气这些本是无爱的家居产品变得更有用。而且我们对新推出的谷歌购物速递服务（Google Shopping Express）——它可以提供当日送抵的服务，以及无人驾驶汽车（这已经无需解释！）都非常激动。在今天看来，这些都是非常疯狂的想法。但是，如果说过去有那么一点能证明我们今后的成功，那么用不了几年，现在的这些赌注看上去就不会那么不着边际了。

在谷歌成立16年后，我们才刚刚触及到梦想的表面。谢尔盖和我参与日常工作，对前景非常激动，对我们能与杰出的人才共事非常激动。谷歌人要让一切成为可能，让这些可能成为我们的未来。虽然世界千变万化，但激励我们的始终是我们自身的潜质，即改变人们今天生活，这一点从一开始就未曾更改。

拉里·佩奇

from: http://bbs.chinaunix.net/thread-1688208-1-1.html

MySQL相对于PostgreSQL的劣势：

PostgreSQL主要优势：
　　1. PostgreSQL完全免费，而且是BSD协议，如果你把PostgreSQL改一改，然后再拿去卖钱，也没有人管你，这一点很重要，这表明了 PostgreSQL数据库不会被其它公司控制。oracle数据库不用说了，是商业数据库，不开放。而MySQL数据库虽然是开源的，但现在随着SUN 被oracle公司收购，现在基本上被oracle公司控制，其实在SUN被收购之前，MySQL中最重要的InnoDB引擎也是被oracle公司控制 的，而在MySQL中很多重要的数据都是放在InnoDB引擎中的，反正我们公司都是这样的。所以如果MySQL的市场范围与oracle数据库的市场范 围冲突时，oracle公司必定会牺牲MySQL，这是毫无疑问的。
　　2. 与PostgreSQl配合的开源软件很多，有很多分布式集群软件，如pgpool、pgcluster、slony、plploxy等等，很容易做读写分离、负载均衡、数据水平拆分等方案，而这在MySQL下则比较困难。
      3. PostgreSQL源代码写的很清晰，易读性比MySQL强太多了，怀疑MySQL的源代码被混淆过。所以很多公司都是基本PostgreSQL做二次开发的。
      4. PostgreSQL在很多方面都比MySQL强，如复杂SQL的执行、存储过程、触发器、索引。同时PostgreSQL是多进程的，而MySQL是线 程的，虽然并发不高时，MySQL处理速度快，但当并发高的时候，对于现在多核的单台机器上，MySQL的总体处理性能不如PostgreSQL，原因是 MySQL的线程无法充分利用CPU的能力。
     目前只想到这些，以后想到再添加，欢迎大家拍砖。


PostgreSQL与oracle或InnoDB的多版本实现的差别

PostgreSQL与oracle或InnoDB的多版本实现最大的区别在于最新版本和历史版本是否分离存储，PostgreSQL不分，而oracle和InnoDB分，而innodb也只是分离了数据,索引本身没有分开。
   PostgreSQL的主要优势在于：
   1. PostgreSQL没有回滚段，而oracle与innodb有回滚段，oracle与Innodb都有回滚段。对于oracle与Innodb来说， 回滚段是非常重要的，回滚段损坏，会导致数据丢失，甚至数据库无法启动的严重问题。另由于PostgreSQL没有回滚段，旧数据都是记录在原先的文件 中，所以当数据库异常crash后，恢复时，不会象oracle与Innodb数据库那样进行那么复杂的恢复，因为oracle与Innodb恢复时同步 需要redo和undo。所以PostgreSQL数据库在出现异常crash后，数据库起不来的几率要比oracle和mysql小一些。
   2. 由于旧的数据是直接记录在数据文件中，而不是回滚段中，所以不会象oracle那样经常报ora-01555错误。
   3. 回滚可以很快完成，因为回滚并不删除数据，而oracle与Innodb，回滚时很复杂，在事务回滚时必须清理该事务所进行的修改，插入的记录要删除，更新的记录要更新回来(见row_undo函数)，同时回滚的过程也会再次产生大量的redo日志。
   4. WAL日志要比oracle和Innodb简单，对于oracle不仅需要记录数据文件的变化，还要记录回滚段的变化。
    PostgreSQL的多版本的主要劣势在于：
   1、最新版本和历史版本不分离存储，导致清理老旧版本需要作更多的扫描，代价比较大，但一般的数据库都有高峰期，如果我们合理安排VACUUM，这也不是很大的问题，而且在PostgreSQL9.0中VACUUM进一步被加强了。
　　2、由于索引中完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，直接从索引中返回所需的属性，还需要访问表。而oracle与Innodb则可以;


进程模式与线程模式的对比
PostgreSQL和oracle是进程模式，MySQL是线程模式。
进程模式对多CPU利用率比较高。
进程模式共享数据需要用到共享内存，而线程模式数据本身就是在进程空间内都是共享的，不同线程访问只需要控制好线程之间的同步。
线程模式对资源消耗比较少。
所以MySQL能支持远比oracle多的更多的连接。
对于PostgreSQL的来说，如果不使用连接池软件，也存在这个问题，但PostgreSQL中有优秀的连接池软件软件，如pgbouncer和pgpool，所以通过连接池也可以支持很多的连接。

堆表与索引组织表的的对比

Oracle支持堆表，也支持索引组织表
PostgreSQL只支持堆表，不支持索引组织表
Innodb只支持索引组织表
索引组织表的优势：
表内的数据就是按索引的方式组织，数据是有序的，如果数据都是按主键来访问，那么访问数据比较快。而堆表，按主键访问数据时，是需要先按主键索引找到数据的物理位置。
索引组织表的劣势：
索引组织表中上再加其它的索引时，其它的索引记录的数据位置不再是物理位置，而是主键值，所以对于索引组织表来说，主键的值不能太大，否则占用的空间比较大。
对于索引组织表来说，如果每次在中间插入数据，可能会导致索引分裂，索引分裂会大大降低插入的性能。所以对于使用innodb来说，我们一般最好让主键是一个无意义的序列，这样插入每次都发生在最后，以避免这个问题。
由于索引组织表是按一个索引树，一般它访问数据块必须按数据块之间的关系进行访问，而不是按物理块的访问数据的，所以当做全表扫描时要比堆表慢很多，这可能在OLTP中不明显，但在数据仓库的应用中可能是一个问题。




　 PostgreSQL9.0中的特色功能：   
    PostgreSQL中的Hot Standby功能
    也就是standby在应用日志同步时，还可以提供只读服务，这对做读写分离很有用。这个功能是oracle11g才有的功能。

    PostgreSQL异步提交（Asynchronous Commit）的功能：
　 这个功能oracle中也是到oracle11g R2才有的功能。因为在很多应用场景中，当宕机时是允许丢失少量数据的，这个功能在这样的场景中就特别合适。在PostgreSQL9.0中把 synchronous_commit设置为false就打开了这个功能。需要注意的是，虽然设置为了异步提交，当主机宕机时，PostgreSQL只会 丢失少量数据，异步提交并不会导致数据损坏而数据库起不来的情况。MySQL中没有听说过有这个功能。

     PostgreSQL中索引的特色功能：
     PostgreSQL中可以有部分索引，也就是只能表中的部分数据做索引，create index 可以带where 条件。同时PostgreSQL中的索引可以反向扫描，所以在PostgreSQL中可以不必建专门的降序索引了。

转自  http://www.raywenderlich.com/zh-hans/30818/ios应用崩溃日志揭秘

本文作者是  Soheil Moayedi Azarpour, 他是一名独立iOS开发者。

作为一名应用开发者，你是否有过如下经历?

为确保你的应用正确无误，在将其提交到应用商店之前，你必定进行了大量的测试工作。它在你的设备上也运行得很好，但是，上了应用商店后，还是有用户抱怨会闪退 !
如果你跟我一样是个完美主义者，你肯定想将应用做到尽善尽美。于是你打开代码准备修复闪退的问题……但是，从何处着手呢？
这时iOS崩溃日志派上用场了。在大多数情况下，你能从中了解到关于闪退的详尽、有用的信息。
通过本教程，你将学习到一些常见的崩溃日志案例，以及如何从开发设备和iTunes Connect上获取崩溃日志文件。你还将学习到符号化（ symbolication）,从日志追踪到代码 。你还将学习调试一个在待定情况下会闪退的应用。
让我们开始动手吧!

什么是崩溃日志，从哪里能得它?

iOS设备上的应用闪退时，操作系统会生成一个崩溃报告，也叫崩溃日志，保存在设备上。
崩溃日志上有很多有用的信息，包括应用是什么情况下闪退的。通常，上面有每个正在执行线程的完整堆栈跟踪信息，所以你能从中了解到闪退发生时各线程都在做什么，并分辨出闪退发生在哪个线程上。
有几种方法可以从设备上获取崩溃日志。
设备与电脑上的iTunes Store同步后，会将崩溃日志保存在电脑上。根据电脑操作系统的不同，崩溃日志将保存在以下位置:
Mac OS X:

~/Library/Logs/CrashReporter/MobileDevice/

Windows XP:

C:Documents and Settings<USERNAME>Application DataApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

Windows Vista or 7:

C:Users<USERNAME>AppDataRoamingApple ComputerLogsCrashReporterMobileDevice<DEVICE_NAME>

当用户抱怨闪退时，你可以要求他让设备与iTunes同步，并根据操作系统的不同，到上述位置把崩溃日志下载下来，然后通过电子邮件发送给你。
你必需尽量获取用户设备生成的所有崩溃日志。因为崩溃日志越多，就越容易诊断问题所在!
另外，如果你装了Xcode，也能很容易通过Xcode从你的设备上获得崩溃日志。将iOS设备连接到电脑上，然后打开Xcode。从菜单栏上选择  Window  菜单, 然后选择  Organizer (快捷方式是 Shift-CMD-2).
在 Organizer 窗口上, 选中  Devices 标签栏. 在左侧的导航面板上，选中  Device Logs, 如下图所示:

看看上图，左侧有好几个 Device Logs 菜单项.  LIBRARY 下面的Device Logs是你所有设备（曾经连接到Xcode的）的日志 。每个设备下面的 Device Logs 是对应设备的日志。
应用提交到App Store后，你也能从  iTunes Connect 获取到用户的崩溃日志. 登录到 iTunes Connect 上, 选择 Manage Your Applications, 点击相应的应用, 点击应用图标下面的  View Details 按钮, 然后点击右栏Links部分的   Crash Reports 。

如果没有崩溃日志，试试点击 Refresh 按钮刷新一下。如果你的应用还卖得不多，或者刚上架不久，iTunes Connect账号上也可能还没有任何崩溃日志。
如果iTunes Connect上有崩溃日志，你将看到如下图:

有时，尽管有用户报告闪退，你仍然看不到崩溃报告。这时，最好让用户直接把崩溃报告发送给你。

什么情况下会产生崩溃日志?

两种主要情况会产生崩溃日志:

1. 应用违反操作系统规则。
2. 应用中有Bug。

违反iOS规则包括在启动、恢复、挂起、退出时watchdog超时、用户强制退出和低内存终止。让我们详细了解一下吧。
Watchdog 超时机制
从iOS 4.x开始，退出应用时，应用不会立即终止，而是退到后台。
但是，如果你的应用响应不够快，操作系统有可能会终止你的应用，并产生一个崩溃日志。这些事件与下列UIApplicationDelegate方法相对应:

• application:didFinishLaunchingWithOptions:
• applicationWillResignActive:
• applicationDidEnterBackground:
• applicationWillEnterForeground:
• applicationDidBecomeActive:
• applicationWillTerminate:

上面所有这些方法，应用只有有限的时间去完成处理。如果花费时间太长，操作系统将终止应用。

用户强制退出
iOS 4.x开始支持多任务。如果应用阻塞界面并停止响应， 用户可以通过在主屏幕上双击Home按钮来终止应用。此时，操作应用将生成一个崩溃日志。

低内存终止
子类化UIViewController时,你或许已经注意到 didReceiveMemoryWarning方法。
在前台运行的应用拥有访问和使用内存的最高优化级。然而，这并不意味着该应用能使用设备的所有可用内存 ——每个应用只能使用一部分可用内存。
当内存使用达到一定程度时，操作系统将发出一个  UIApplicationDidReceiveMemoryWarningNotification 通知。同时,调用  didReceiveMemoryWarning 方法。
此时，为了让应用继续正常运行，操作系统开始终止在后台的其他应用以释放一些内存。所有后台应用被终止后，如果你的应用还需要更多内存，操作系统会将你的应用也终止掉，并产生一个崩溃日志。而在这种情况下被终止的后台应用，不会产生崩溃日志。

应用中有Bug
如你所想，大多数闪退都是由于应用中有Bug，因此大多数崩溃日志的产生都是因为应用中的Bug。Bug的种类的有很多。

在本教程的后半部分，你将通过调试一个会产生崩溃日志的含有Bug的应用，学习如何找到问题所在并进行修复!

崩溃日志的实例

让我们看看一个崩溃日志的实例，以使你在处理一些实际问题之前心里有谱。
事不宜迟，见见你的新朋友吧:

Incident Identifier: 30E46451-53FD-4965-896A-457FC11AD05F
CrashReporter Key:   5a56599d836c4f867f6eec76afee451bf9ae5f31
Hardware Model:      iPhone4,1
Process:         Rage Masters [4155]
Path:            /var/mobile/Applications/A5635B22-F5EF-4CEB-94B6-FE158D885014/Rage Masters.app/Rage Masters
Identifier:      Rage Masters
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]
// 2: 基本信息
Date/Time:       2012-10-17 21:39:06.967 -0400
OS Version:      iOS 6.0 (10A403)
Report Version:  104
// 3: 异常
Exception Type:  00000020
Exception Codes: 0x000000008badf00d
Highlighted Thread:  0
// 4: 线程回溯
Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   libsystem_kernel.dylib            0x327f2eb4 mach_msg_trap + 20
1   libsystem_kernel.dylib            0x327f3048 mach_msg + 36
2   CoreFoundation                    0x36bd4040 __CFRunLoopServiceMachPort + 124
3   CoreFoundation                    0x36bd2d9e __CFRunLoopRun + 878
4   CoreFoundation                    0x36b45eb8 CFRunLoopRunSpecific + 352
5   CoreFoundation                    0x36b45d44 CFRunLoopRunInMode + 100
6   CFNetwork                         0x32ac343e CFURLConnectionSendSynchronousRequest + 330
7   Foundation                        0x346e69ba +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242
8   Rage Masters                      0x000d4046 0xd2000 + 8262
Thread 1:
0   libsystem_kernel.dylib            0x32803d98 __workq_kernreturn + 8
1   libsystem_c.dylib                 0x3a987cf6 _pthread_workq_return + 14
2   libsystem_c.dylib                 0x3a987a12 _pthread_wqthread + 362
3   libsystem_c.dylib                 0x3a9878a0 start_wqthread + 4
// 5: 线程状态
Thread 0 crashed with ARM Thread State (32-bit):
    r0: 0x00000000    r1: 0x00000000      r2: 0x00000001      r3: 0x39529fc8
    r4: 0xffffffff    r5: 0x2fd7d301      r6: 0x2fd7d300      r7: 0x2fd7d9d0
    r8: 0x2fd7d330    r9: 0x3adbf8a8     r10: 0x2fd7d308     r11: 0x00000032
    ip: 0x00000025    sp: 0x2fd7d2ec      lr: 0x001bdb25      pc: 0x30301838
  cpsr: 0x00000010
// 6: 二进制映像
Binary Images:
0xd2000 -    0xd7fff +Rage Masters armv7   /var/mobile/Applications/A5635B22-F5EF-4CEB-94B6-FE158D885014/Rage Masters.app/Rage Masters
0x2fe41000 - 0x2fe61fff  dyld armv7   /usr/lib/dyld
0x327f2000 - 0x32808fff  libsystem_kernel.dylib armv7   /usr/lib/system/libsystem_kernel.dylib
0x328a8000 - 0x328bdfff  libresolv.9.dylib armv7   /usr/lib/libresolv.9.dylib
0x32a70000 - 0x32b35fff  CFNetwork armv7   /System/Library/Frameworks/CFNetwork.framework/CFNetwork
0x32b7a000 - 0x32cc3fff  libicucore.A.dylib armv7   /usr/lib/libicucore.A.dylib
0x32cc4000 - 0x32cc5fff  CoreSurface armv7   /System/Library/PrivateFrameworks/CoreSurface.framework/CoreSurface
0x32f65000 - 0x32f8afff  OpenCL armv7   /System/Library/PrivateFrameworks/OpenCL.framework/OpenCL

这报告看起来像天书。:) 我们分几部分来解读吧:

(1) 进程信息
第一部分是闪退进程的相关信息。

• Incident Identifier是崩溃报告的唯一标识符。
• CrashReporter Key 是与设备标识相对应的唯一键值。虽然它不是真正的设备标识符，但也是一个非常有用的情报:如果你看到100个崩溃日志的CrashReporter Key值都是相同的，或者只有少数几个不同的CrashReport值，说明这不是一个普遍的问题，只发生在一个或少数几个设备上。
• Hardware Model 标识设备类型。 如果很多崩溃日志都是来自相同的设备类型，说明应用只在某特定类型的设备上有问题。上面的日志里，崩溃日志产生的设备是iPhone 4s。
• Process 是应用名称。中括号里面的数字是闪退时应用的进程ID。
• 接下来几行不言自明，无需赘述。

(2) 基本信息
这部分给出了一些基本信息，包括闪退发生的日期和时间，设备的iOS版本。如果有很多崩溃日志都来自iOS 6.0，说明问题只发生在iOS 6.0上。
(3) 异常
在这部分，你可以看到闪退发生时抛出的异常类型。还能看到异常编码和抛出异常的线程。根据崩溃报告类型的不同，在这部分你还能看到一些另外的信息。
(4) 线程回溯
这部分提供应用中所有线程的回溯日志。 回溯是闪退发生时所有活动帧清单。它包含闪退发生时调用函数的清单。看下面这行日志:

2    XYZLib    0x34648e88    0x83000 + 8740

它包括四列:

1. 帧编号—— 此处是2。
2. 二进制库的名称 ——此处是 XYZLib.
3. 调用方法的地址 ——此处是 0x34648e88.
4. 第四列分为两个子列，一个基本地址和一个偏移量。此处是0×83000 + 8740, 第一个数字指向文件，第二个数字指向文件中的代码行。

(5) 线程状态
这部分是闪退时寄存器中的值。一般不需要这部分的信息，因为回溯部分的信息已经足够让你找出问题所在。
(6) 二进制映像
这部分列出了闪退时已经加载的二进制文件。

符号化Symbolication

第一次看到崩溃日志上的回溯时，你或许会觉得它没什么意义。我们习惯使用方法名和行数，而非像这样的神秘位置:

6    Rage Masters    0x0001625c    0x2a000 + 3003

将这些十六进制地址转化成方法名称和行数的过程称之为符号化。
从Xcode的Organizer窗口获取崩溃日志后过几秒钟，崩溃日志将被自动符号化。上面那行被符号化后的版本如下 :

6    Rage Masters    0x0001625c    -[RMAppDelegate application:didFinishLaunchingWithOptions:] (RMAppDelegate.m:35)

Xcode符号化崩溃日志时，需要访问与App Store上对应的应用二进制文件以及生成二进制文件时产生的  .dSYM 文件。必需完全匹配才行。否则，日志将无法被完全符号化。
所以，保留每个分发给用户的编译版本非常重要。提交应用前进行归档时，Xcode将保存应用的二进制文件。可以在Xcode Organizer的Archives标签栏下找到所有已归档的应用文件。
在发现崩溃日志时，如果有相匹配的.dSYM文件和应用二进制文件，Xcode会自动对崩溃日志进行符号化。如果你换到别的电脑或创建新的账户，务必将所有二进制文件移动到正确的位置，使Xcode能找到它们。

低内存闪退

因为低内存崩溃日志与普通崩溃日志略有不同，所以本教程特别分开说明一下。:]
iOS设备检测到低内存时，虚拟内存系统发出通知请求应用释放内存。这些通知发送到所有正在运行的应用和进程，试图收回一些内存。
如果内存使用依然居高不下，系统将会终止后台线程以缓解内存压力。如果可用内存足够，应用将能够继续运行而不会产生崩溃报告。否则，应用将被iOS终止，并产生低内存崩溃报告。
低内存崩溃日志上没有应用线程的堆栈回溯。相反，上面显示的是以内存页数为单位的各进程内存使用量。(在撰写本文的时候，一个内存页的大小是4KB。)
被iOS因释放内存页终止的进程名称后面你会看到 jettisoned 字样。如果看到它出现在你的应用名称后面，说明你的应用因使用太多内存而被终止了。
低内存崩溃日志看起来像这样：

Incident Identifier: 30E46451-53FD-4965-896A-457FC11AD05F
CrashReporter Key:   5a56599d836c4f867f6eec76afee451bf9ae5f31
OS Version:          iPhone OS 3.1.3 (7E18)
Date/Time:           2012-10-17 21:39:06.967 -0400
Free pages:        96
Wired pages:       10558
Purgeable pages:   0
Largest process:   Rage Masters
Processes
         Name                 UUID                    Count resident pages
    Rage Masters     9320 (jettisoned) (active)
    mediaserverd      255
     dataaccessd      505
         syslogd       71
            apsd      171
       securityd      243
         notifyd     2027
      CommCenter      189
     SpringBoard     2158 (active)
      accessoryd       91
         configd      371
       fairplayd       93
   mDNSResponder      292
       lockdownd     1204
         launchd       72

当应用发生低内存闪退时，你必需看看应用中内存使用的方式，以及是如何处理低内存警告的。你可以使用Instruments工具中使用Allocations 和 Leaks来发现内存分配问题和内存泄漏问题。如果你不知道如何利用 Instruments 检查内存问题，可以看看 这个教程 。
还有，别忘记虚拟内存！ Instruments工具的Leaks 和 Allocations 不能跟踪显存使用情况。必需使用 VM Tracker 才能查看显存使用情况。
VM Tracker 默认是关闭的。打开Instrument,手动 选中 Automatic Snapshotting 标志或者按下 Snapshot Now 按钮。
本教程后面将会学习如何研究低内存崩溃日志。

异常编码

在研究真实闪退场景之前，还有一点需要重点介绍一下：就是那些有趣的异常编码 。
你可以在报告的异常部分——前面代码的第3部分找到异常编码。有些编码比较常见。
通常，异常编码以一些文字开头，紧接着是一个或多个十六进制值，此数值正是说明闪退根本性质的所在。  从这些编码中，可以区分出闪退是因为程序错误、非法内存访问或者是其他原因。
下面是一些常见的异常编码:

• 0x8badf00d: 读做 “ate bad food”! (把数字换成字母，是不是很像 :p)该编码表示应用是因为发生watchdog超时而被iOS终止的。  通常是应用花费太多时间而无法启动、终止或响应用系统事件。

• 0xbad22222: 该编码表示 VoIP 应用因为过于频繁重启而被终止。
• 0xdead10cc: 读做 “dead lock”!该代码表明应用因为在后台运行时占用系统资源，如通讯录数据库不释放而被终止 。
• 0xdeadfa11: 读做 “dead fall”! 该代码表示应用是被用户强制退出的。根据苹果文档, 强制退出发生在用户长按开关按钮直到出现 “滑动来关机”, 然后长按 Home按钮。强制退出将产生 包含0xdeadfa11 异常编码的崩溃日志, 因为大多数是强制退出是因为应用阻塞了界面。

大展身手的时候到了!

好了! 你已经学习了所有分析崩溃日志和修复错误的基础知识!
假设你刚进入Rage-O-Rage有限公司工作。该公司有一个在App Store上热销的应用，叫 Rage Masters。
你的老板安迪要你帮忙解决几个用户经常抱怨闪退问题。你的任务就是研究这些闪退，符号化用户提供的崩溃日志，查找问题所在，并修复之。
你可以从  这里下载应用的源代码。

场景 1: 糟糕的代码

一封来自用户的邮件: “大哥，你的应用就是一坨屎! 我将其下载到我自己的iPod Touch和iPhone上，还下载到我儿子的iPod Touch上。在所有的设备上，都是还没打开就闪退了……”
别一封来自用户的邮件说, “我下载了你们的应用，一打开就闪退。真悲催…”
另一封邮件说得更明确：”你们的应用不能运行。我把它下载到我和妻子的设备上。所有设备都是 一打开就闪退了…”

好吧，别灰心! 这些意见藏着什么玄机呢？让我们看看崩溃日志吧:

Incident Identifier: 85833DBA-3DF7-43EE-AF80-4E5C51091F42
CrashReporter Key:   5a56599d836c4f867f6eec76afee451bf9ae5f31
Hardware Model:      iPhone4,1
Process:         Rage Masters [20067]
Path:            /var/mobile/Applications/B2121A89-3D1F-4E61-BB18-5511E1DC150F/Rage Masters.app/Rage Masters
Identifier:      Rage Masters
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]
Date/Time:       2012-11-03 13:37:31.148 -0400
OS Version:      iOS 6.0 (10A403)
Report Version:  104
Exception Type:  00000020
Exception Codes: 0x000000008badf00d
Highlighted Thread:  0
Application Specific Information:
Soheil-Azarpour.Rage-Masters failed to launch in time
Elapsed total CPU time (seconds): 8.030 (user 8.030, system 0.000), 20% CPU 
Elapsed application CPU time (seconds): 3.840, 10% CPU
Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   libsystem_kernel.dylib            0x327f2eb4 mach_msg_trap + 20
1   libsystem_kernel.dylib            0x327f3048 mach_msg + 36
2   CoreFoundation                    0x36bd4040 __CFRunLoopServiceMachPort + 124
3   CoreFoundation                    0x36bd2d9e __CFRunLoopRun + 878
4   CoreFoundation                    0x36b45eb8 CFRunLoopRunSpecific + 352
5   CoreFoundation                    0x36b45d44 CFRunLoopRunInMode + 100
6   CFNetwork                         0x32ac343e CFURLConnectionSendSynchronousRequest + 330
7   Foundation                        0x346e69ba +[NSURLConnection sendSynchronousRequest:returningResponse:error:] + 242
8   Rage Masters                      0x000ea1c4 -[RMAppDelegate application:didFinishLaunchingWithOptions:] (RMAppDelegate.m:36)
9   UIKit                             0x37f30ad4 -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 248
10  UIKit                             0x37f3065e -[UIApplication _callInitializationDelegatesForURL:payload:suspended:] + 1186
11  UIKit                             0x37f28846 -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] + 694
12  UIKit                             0x37ed0c3c -[UIApplication handleEvent:withNewEvent:] + 1000
13  UIKit                             0x37ed06d0 -[UIApplication sendEvent:] + 68
14  UIKit                             0x37ed011e _UIApplicationHandleEvent + 6150
15  GraphicsServices                  0x370835a0 _PurpleEventCallback + 588
16  GraphicsServices                  0x370831ce PurpleEventCallback + 30
17  CoreFoundation                    0x36bd4170 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
18  CoreFoundation                    0x36bd4112 __CFRunLoopDoSource1 + 134
19  CoreFoundation                    0x36bd2f94 __CFRunLoopRun + 1380
20  CoreFoundation                    0x36b45eb8 CFRunLoopRunSpecific + 352
21  CoreFoundation                    0x36b45d44 CFRunLoopRunInMode + 100
22  UIKit                             0x37f27480 -[UIApplication _run] + 664
23  UIKit                             0x37f242fc UIApplicationMain + 1116
24  Rage Masters                      0x000ea004 main (main.m:16)
25  libdyld.dylib                     0x3b630b1c start + 0

发现问题了吗? 异常编码是 0x000000008badf00d,还有后面的报告:

Application Specific Information:
Soheil-Azarpour.Rage-Masters failed to launch in time
Elapsed total CPU time (seconds): 8.030 (user 8.030, system 0.000), 20% CPU 
Elapsed application CPU time (seconds): 3.840, 10% CPU

这说明应用在启动时就闪退了，iOS的watchdog机制终止了应用。帅! 找到问题了，但是为什会发生这样的事呢？
接着往下看日志。 从下向上读回溯日志。最底下的帧 (frame 25: libdyld.dylib)是最先调用的，然后是帧24, Rage Masters, main (main.m:16) ，依此类推。
跟应用源代码相关的帧是最重要的。忽略掉系统库和框架。下一个与代码相关的帧是:

8    Rage Masters    0x0009f244 -[RMAppDelegate application:didFinishLaunchingWithOptions:] (RMAppDelegate.m:35)

应用在执行RMAppDelegate (RMAppDelegate.m:35)类 application:didFinishLaunchingWithOptions: 方法第35 行代码时闪退。打开Xcode看看那行代码：

NSData *directoryData = [NSURLConnection sendSynchronousRequest:request returningResponse:nil error:nil];

就是它了! 同步调用web服务?! 在主线程上?! 在  application:didFinishLaunchingWithOptions: 方法上?!! 谁写的代码呀?!

Network calls on the main thread makes kittens sad.

不管如何，问题得你来修复了。这个调用必需异步进行，甚至更理想的情况是，在 application:didFinishLaunchingWithOptions:返回YES之后的其他部分再执行Web服务。
在其他地方调用可能需要比较多的修改。当下，我们只要使应用不闪退就行。可以在日后再实现更好的设计。 将上面那行讨厌的代码（及其下面的三行代码）换成下面这个异步的版本吧:

 [NSURLConnection sendAsynchronousRequest:request
                                           queue:[NSOperationQueue mainQueue]
                               completionHandler:^(NSURLResponse *response, NSData *data, NSError *error)
         {
             NSURL *cacheDirectory = [[[NSFileManager defaultManager] URLsForDirectory:NSUserDirectory inDomains:NSCachesDirectory] lastObject];
             NSURL *filePath = [NSURL URLWithString:kDirectoryFile relativeToURL:cacheDirectory];
             [data writeToFile:[filePath absoluteString] atomically:YES];
         }];

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

一名用户说: “我不能将某个rage master添加到书签里面。我想添加的时候应用就闪退…”
用一名用户说 ：”书签不能用 … 在详细页面上，点击书签按钮,应用就闪退了!”
上面的抱怨说得不是很清楚，引起问题的原因肯定有多样。看看崩溃日志:

Incident Identifier: 3AAA63CC-3088-41CC-84D9-82FE03F9F354
CrashReporter Key:   5a56599d836c4f867f6eec76afee451bf9ae5f31
Hardware Model:      iPhone4,1
Process:         Rage Masters [20090]
Path:            /var/mobile/Applications/B2121A89-3D1F-4E61-BB18-5511E1DC150F/Rage Masters.app/Rage Masters
Identifier:      Rage Masters
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]
Date/Time:       2012-11-03 13:39:00.081 -0400
OS Version:      iOS 6.0 (10A403)
Report Version:  104
Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0
Last Exception Backtrace:
0   CoreFoundation                    0x36bff29e __exceptionPreprocess + 158
1   libobjc.A.dylib                   0x34f0f97a objc_exception_throw + 26
2   CoreFoundation                    0x36c02e02 -[NSObject(NSObject) doesNotRecognizeSelector:] + 166
3   CoreFoundation                    0x36c0152c ___forwarding___ + 388
4   CoreFoundation                    0x36b58f64 _CF_forwarding_prep_0 + 20
5   UIKit                             0x37fbb0a8 -[UIApplication sendAction:to:from:forEvent:] + 68
6   UIKit                             0x37fbb05a -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26
7   UIKit                             0x37fbb038 -[UIControl sendAction:to:forEvent:] + 40
8   UIKit                             0x37fba8ee -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 498
9   UIKit                             0x37fbade4 -[UIControl touchesEnded:withEvent:] + 484
10  UIKit                             0x37ee35f4 -[UIWindow _sendTouchesForEvent:] + 520
11  UIKit                             0x37ed0804 -[UIApplication sendEvent:] + 376
12  UIKit                             0x37ed011e _UIApplicationHandleEvent + 6150
13  GraphicsServices                  0x3708359e _PurpleEventCallback + 586
14  GraphicsServices                  0x370831ce PurpleEventCallback + 30
15  CoreFoundation                    0x36bd416e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 30
16  CoreFoundation                    0x36bd4112 __CFRunLoopDoSource1 + 134
17  CoreFoundation                    0x36bd2f94 __CFRunLoopRun + 1380
18  CoreFoundation                    0x36b45eb8 CFRunLoopRunSpecific + 352
19  CoreFoundation                    0x36b45d44 CFRunLoopRunInMode + 100
20  GraphicsServices                  0x370822e6 GSEventRunModal + 70
21  UIKit                             0x37f242fc UIApplicationMain + 1116
22  Rage Masters                      0x000ca004 main (main.m:16)
23  libdyld.dylib                     0x3b630b1c start + 0

异常代码是SIGABRT。通常,  SIGABRT 异常是由于某个对象接收到未实现的消息引起的。 或者，用简单的话说，在某个对象上调用了不存在的方法。
这种情况一般不会发生，因为A对象调用了B方法，如果B方法不存在，编译器会报错。但是，如果你是使用selector间接调用方法的，编译器则无法检测对象是否存在该方法了。
回到崩溃日志。它指出闪退发生在编号为0的线程上。 这意味着很可能是在主线程上调用了某个对象没有实现的方法。
如果你接着阅读回溯日志，会发现跟你的代码相关的只有帧22, main.m:16. 这没有多大帮助。 :[
继续向上查看框架调用，出现这个:

2    CoreFoundation    0x36c02e02 -[NSObject(NSObject) doesNotRecognizeSelector:] + 166

这不是你自己写的代码。但至少它确认了是对象调用了一个没有实现的方法。
回到 RMDetailViewController.m文件, 因为那是书签按钮实现动作的地方。 找到书签功能代码:

-(IBAction)bookmarkButtonPressed {
 
    self.master.isBookmarked = !self.master.isBookmarked;
 
    // Update shared bookmarks
    if (self.master.isBookmarked)
        [[RMBookmarks sharedBookmarks] bookmarkMaster:self.master];
    else
        [[RMBookmarks sharedBookmarks] unbookmarkMaster:self.master];
 
    // Update UI
    [self updateBookmarkImage];
}

看起来没什么问题，再检查一下storyboard (XIB文件) ，确认按钮连接的正确性。

就是它了! 在  MainStoryboard.storyboard,按钮连接的是 bookmarkButtonPressed: 而不是bookmarkButtonPressed (注意后面的分号说明方法有一个参数）。 只要将上面的方法签名修改成这样就能修复问题了:

-(IBAction)bookmarkButtonPressed:(id)sender {
    // Remain unchanged..
}

当然，你也可以简单地在XIB文件上删除错误的连接，然后重新连接方法，使XIB文件连接到正确的方法上。两者方法都行。
又处理了一个闪退问题，好样的。:]

场景 3: 表格上的Bug

另一用户抱怨道, “在书签视图上无法删除书签…” 还有另一用户抱怨同样的问题, “当我试图删除书签时，应用闪退…”
这些邮件没什么作用，还是看看崩溃日志!

Incident Identifier: 5B62D681-D8FE-41FE-8D52-AB7E6D6B2AC7
CrashReporter Key:   5a56599d836c4f867f6eec76afee451bf9ae5f31
Hardware Model:      iPhone4,1
Process:         Rage Masters [20088]
Path:            /var/mobile/Applications/B2121A89-3D1F-4E61-BB18-5511E1DC150F/Rage Masters.app/Rage Masters
Identifier:      Rage Masters
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]
Date/Time:       2012-11-03 13:38:45.762 -0400
OS Version:      iOS 6.0 (10A403)
Report Version:  104
Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0
Last Exception Backtrace:
0   CoreFoundation                    0x36bff29e __exceptionPreprocess + 158
1   libobjc.A.dylib                   0x34f0f97a objc_exception_throw + 26
2   CoreFoundation                    0x36bff158 +[NSException raise:format:arguments:] + 96
3   Foundation                        0x346812aa -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 86
4   UIKit                             0x37f04b7e -[UITableView(_UITableViewPrivate) _endCellAnimationsWithContext:] + 7690
5   UIKit                             0x3803a4a2 -[UITableView deleteRowsAtIndexPaths:withRowAnimation:] + 22
6   Rage Masters                      0x000fd9ca -[RMBookmarksViewController tableView:commitEditingStyle:forRowAtIndexPath:] (RMBookmarksViewController.m:68)
7   UIKit                             0x3809a5d4 -[UITableView(UITableViewInternal) animateDeletionOfRowWithCell:] + 80
8   UIKit                             0x37fbb0a8 -[UIApplication sendAction:to:from:forEvent:] + 68
9   UIKit                             0x37fbb05a -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26
10  UIKit                             0x37fbb038 -[UIControl sendAction:to:forEvent:] + 40
11  UIKit                             0x37fba8ee -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 498
12  UIKit                             0x37fbb0a8 -[UIApplication sendAction:to:from:forEvent:] + 68
13  UIKit                             0x37fbb05a -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26
14  UIKit                             0x37fbb038 -[UIControl sendAction:to:forEvent:] + 40
15  UIKit                             0x37fba8ee -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 498
16  UIKit                             0x37fbade4 -[UIControl touchesEnded:withEvent:] + 484
17  UIKit                             0x37ee35f4 -[UIWindow _sendTouchesForEvent:] + 520
18  UIKit                             0x37ed0804 -[UIApplication sendEvent:] + 376
19  UIKit                             0x37ed011e _UIApplicationHandleEvent + 6150
20  GraphicsServices                  0x3708359e _PurpleEventCallback + 586
21  GraphicsServices                  0x370831ce PurpleEventCallback + 30
22  CoreFoundation                    0x36bd416e __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 30
23  CoreFoundation                    0x36bd4112 __CFRunLoopDoSource1 + 134
24  CoreFoundation                    0x36bd2f94 __CFRunLoopRun + 1380
25  CoreFoundation                    0x36b45eb8 CFRunLoopRunSpecific + 352
26  CoreFoundation                    0x36b45d44 CFRunLoopRunInMode + 100
27  GraphicsServices                  0x370822e6 GSEventRunModal + 70
28  UIKit                             0x37f242fc UIApplicationMain + 1116
29  Rage Masters                      0x000fb004 main (main.m:16)
30  libdyld.dylib                     0x3b630b1c start + 0

这看起来跟前面那个崩溃日志很像。是另一个SIGABRT 异常。 你可能想知道是否是相同的问题：发送信息到一个没有实现相应方法的对象?
让我们从回溯日志看看哪些方法被调用了。从底部开始，你的源代码最后被调用的是帧 6:

6    Rage Masters    0x00088c66 -[RMBookmarksViewController tableView:commitEditingStyle:forRowAtIndexPath:] (RMBookmarksViewController.m:68)

这是UITableViewDataSource 的一个方法. 呵呵?! 毫无疑问苹果已经实现了该方法 —— 你可以重载它, 但不像是还没有实现。而且,这是个可选的委派方法。 所以问题不是调用了一个没有实现的方法。

再看看上面的几个帧:

3    Foundation    0x346812aa -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 86
4    UIKit         0x37f04b7e -[UITableView(_UITableViewPrivate) _endCellAnimationsWithContext:] + 7690
5    UIKit         0x3803a4a2 -[UITableView deleteRowsAtIndexPaths:withRowAnimation:] + 22

帧 5, UITableView调用了它自己的另一个方法  deleteRowsAtIndexPaths:withRowAnimation: 然后是看起来像苹果内部方法的 _endCellAnimationsWithContext: 被调用。然后Foundation framework发生异常 handleFailureInMethod:object:file:lineNumber:description:.
这些分析结合用户的抱怨，看起来是你在处理UITableView删除行过程中有Bug。回到Xcode。你知道看哪里吗 ? 能从崩溃日志中判断出来? 就是 RMBookmarksViewController.m文件的第68行:

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {
 
    [self.tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationAutomatic];
}

发现问题了吗? 给你点时间，仔细看一下。
找到了吧! 数据源呢? 代码在表格视图上删除了一行，但并没有修改背后的数据源。把上面的代码替换成下面的就能修复问题了:

-(void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {
 
    RMMaster *masterToDelete = [bookmarks objectAtIndex:indexPath.row];
    [bookmarks removeObject:masterToDelete];
    [[RMBookmarks sharedBookmarks] unbookmarkMaster:masterToDelete];
 
    [self.tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationAutomatic];
}

搞定了!走起，讨厌的 bug!!

场景 4: 吃棒棒糖时闪退!

用户邮件说, “当rage master吃棒棒糖时应用就闪退…” 另一用户说, “我让rage master 吃棒棒糖，没几次应用就闪退了!”
崩溃日志如下:

Incident Identifier: 081E58F5-95A8-404D-947B-5E104B6BC1B1
CrashReporter Key:   5a56599d836c4f867f6eec76afee451bf9ae5f31
Hardware Model:      iPhone4,1
OS Version:          iPhone OS 6.0 (10A403)
Kernel Version:      Darwin Kernel Version 13.0.0: Sun Aug 19 00:28:05 PDT 2012; root:xnu-2107.2.33~4/RELEASE_ARM_S5L8940X
Date:                2012-11-03 13:39:59 -0400
Time since snapshot: 4353 ms
Free pages:        968
Active pages:      7778
Inactive pages:    4005
Throttled pages:   92319
Purgeable pages:   0
Wired pages:       23347
Largest process:   Rage Masters

Processes
     Name                    <UUID>                       rpages       recent_max       [reason]          (state)
 
             lsd <6a9f5b5f36b23fc78f87b6d8f1f49a9d>          331              331         [vm]         (daemon) (idle)
            afcd <b0aff2e7952e34a9882fec81a8dcdbb2>          141              141         [vm]         (daemon) (idle)
    itunesstored <4e0cd9f873de3435b4119c48b2d6d13d>         1761             1761         [vm]         (daemon) (idle)
softwareupdatese <2bc4b5ae016431c98d3b34f81027d0ae>          311              311         [vm]         (daemon) (idle)
          Amazon <4600481f07ec3e59a925319b7f67ba14>         2951             2951         [vm]         (suspended)
       accountsd <ac0fce15c1a2350d951efc498d521ac7>          519              519         [vm]         (daemon) (idle)
coresymbolicatio <edba67001f76313b992056c712153b4b>          126              126         [vm]         (daemon) (idle)
           Skype <504cf2fe60cb3cdea8273e74df09836b>         3187             3187         [vm]         (background)
      MobileMail <bff817c61ce33c85a43ea9a6c98c29f5>        14927            14927         [vm]         (continuous)
       MobileSMS <46778de076363d67aeea207464cfc581>         2134             2134         [vm]         (background)
     MobilePhone <3fca241f2a193d0fb8264218d296ea41>         2689             2689         [vm]         (continuous)
      librariand <c9a9be81aa9632f0a913ce79b911f27e>          317              317         [vm]         (daemon)
             kbd <3e7136ddcefc3d77a01499db593466cd>          616              616         [vm]         (daemon)
            tccd <eb5ddcf533663f8d987d67cae6a4c4ea>          224              224         [vm]         (daemon)
    Rage Masters <90b45d6281e934209c5b06cf7dc4d492>        28591            28591         [vm]         (frontmost) (resume)
            ptpd <04a56fce67053c57a7979aeea8e5a7ea>          879              879                      (daemon)
   iaptransportd <f784f30dc09d32078d87b450e8113ef6>          230              230                      (daemon)
       locationd <892cd1c9ffa43c99a82dba197be5f09e>         1641             1641                      (daemon)
         syslogd <cbef142fa0a839f0885afb693fb169c3>          237              237                      (daemon)
    mediaserverd <80657170daca32c9b8f3a6b1faac43a2>         4869             4869                      (daemon)
     dataaccessd <2a3f6a518f3f3646bf35eddd36f25005>         1786             1786                      (daemon)
      aosnotifyd <d4d14f2914c3343796e447cfef3e6542>          549              549                      (daemon)
           wifid <9472b090746237998cdbb9b34f090d0c>          455              455                      (daemon)
     SpringBoard <27372aae101f3bbc87804edc10314af3>        18749            18749                     
      backboardd <5037235f295b33eda98eb5c72c098858>         5801             5801                      (daemon)
  UserEventAgent <6edfd8d8dba23187b05772dcdfc94f90>          601              601                      (daemon)
    mediaremoted <4ff39c50c684302492e396ace813cb25>          293              293                      (daemon)
     pasteboardd <8a4279b78e4a321f84a076a711dc1c51>          176              176                      (daemon)
springboardservi <ff6f64b3a21a39c9a1793321eefa5304>            0                0                      (daemon)
    syslog_relay <45e9844605d737a08368b5215bb54426>            0                0                      (daemon)
      DTMobileIS <23303ca402aa3705870b01a9047854ea>            0                0                      (daemon)
notification_pro <845b7beebc8538ca9ceef731031983b7>          169              169                      (daemon)
    syslog_relay <45e9844605d737a08368b5215bb54426>            0                0                      (daemon)
             ubd <74dc476d1785300e9fcda555fcb8d774>          976              976                      (daemon)
        twitterd <4b4946378a9c397d8250965d17055b8e>          730              730                      (daemon)
         configd <4245d73a9e96360399452cf6b8671844>          809              809                      (daemon)
   absinthed.N94 <7f4164c844fa340caa940b863c901aa9>           99               99                      (daemon)
filecoordination <fbab576f37a63b56a1039153fc1aa7d8>          226              226                      (daemon)
       distnoted <a89af76ec8633ac2bbe99bc2b7964bb0>          137              137                      (daemon)
            apsd <94d8051dd5f5362f82d775bc279ae608>          373              373                      (daemon)
        networkd <0032f46009f53a6c80973fe153d1a588>          219              219                      (daemon)
      aggregated <8c3c991dc4153bc38aee1e841864d088>          112              112                      (daemon)
        BTServer <c92fbd7488e63be99ec9dbd05824f5e5>          522              522                      (daemon)
   fairplayd.N94 <7bd896bd00783a48906090d05cf1c86a>          210              210                      (daemon)
       fseventsd <996cc4ca03793184aea8d781b55bce08>          384              384                      (daemon)
         imagent <1e68080947be352590ce96b7a1d07b2f>          586              586                      (daemon)
   mDNSResponder <3e557693f3073697a58da6d27a827d97>          295              295                      (daemon)
       lockdownd <ba1358c7a8003f1b91af7d5f58dd5bbe>          389              389                      (daemon)
          powerd <2d2ffed5e69638aeba1b92ef124ed861>          174              174                      (daemon)
      CommCenter <1f425e1e897d32e8864fdd8eeaa803a8>         2212             2212                      (daemon)
         notifyd <51c0e03da8a93ac8a595442fcaac531f>          211              211                      (daemon)
     ReportCrash <8c32f231b2ed360bb151b2563bcaa363>          337              337                      (daemon)

这日志跟我们前面见到的相差很多。

这个一个来自iOS 6的低内存崩溃日志。正如我们前面所说的，低内存崩溃日志与其他类型的崩溃日志很不一样，它们不指向特定的文件和代码行。相反，它们画出了闪退时设备上的内存使用情况的图表。

至少，头部还是跟其他崩溃日志很像的:  提供了 Incident Identifier, CrashReporter Key, Hardware Model, OS Version等信息。

接下来部分是低内存崩溃日志特有的:

• Free pages 指可用内存页数。每页大小约是4KB, 上面的日志中，可用内存约为3,872 KB (或者说 3.9 MB)。
• Purgeable pages 是那部分可被清除或重用的内存。在上面的日志中，是0KB。
• Largest process是闪退时使用大部分内存的应用名称，在上面的日志中，正是你的应用!
• Processes显示了闪退时各进程列表，还包含内存使用量。包含进程名 (第一列), 进程唯一标识符(第二名), 进程使用的内存页数(第三列)。最后一列是每个应用的状态。通常，发生闪退的应用的状态是 frontmost。 这里是 Rage Masters, 使用28591 页 (or 114.364 MB) 内存——这内存太多了!

通过，最大进程和frontmost状态的应用是相同的， 而且也是引起低内存闪退的应用进程。但是也可能看到最大进程和 frontmost状态应用不同的例子。比如，如果最大进程是SpringBoard, 忽略它 , 因为 SpringBoard 进程是显示主屏幕的应用，出现在你双击home按钮等情况，而且它是一直活动的。
低内存发生时，iOS向活动的应用发出低内存警告并终止后台应用。如果前台应用仍然继续增长内存，iOS将终止它。
为了查找低内存问题的原因，你必需使用Instruments剖析应用。如果你不知道怎么做，可以看一下我们 一篇关于这个方面的教程.。 :] 另外, 你也可以走捷径，响应低内存警告通知，以解决部分闪退问题。
回到Xcode查看RMLollipopLicker.m文件。 这是实现吃棒棒糖的视图控制器。看看源代码:

#import "RMLollipopLicker.h"

#define COUNT 20

@interface RMLollipopLicker ()
@property (weak, nonatomic) IBOutlet UIProgressView *progressView;
@property (weak, nonatomic) IBOutlet UILabel *label;
@property (weak, nonatomic) IBOutlet UILabel *lickedTimeLabel;
@end

@implementation RMLollipopLicker {
    NSOperationQueue *queue;
    NSMutableArray *lollipops;
}

#pragma mark - Life cycle

- (void)viewDidLoad {
    [super viewDidLoad];
    
    self.progressView.progress = 0.0;
    self.label.text = [NSString stringWithFormat:@"Tap on run and I'll lick a lollipop %d times!", COUNT];
    self.lickedTimeLabel.text = @"";
    
    lollipops = [[NSMutableArray alloc] init];
    queue = [[NSOperationQueue alloc] init];
}

- (void)lickLollipop {
    NSURL *fileURL = [[NSBundle mainBundle] URLForResource:@"Lollipop" withExtension:@"plist"];
    NSDictionary *dictionary = [NSDictionary dictionaryWithContentsOfURL:fileURL];
    NSString *lollipop = [dictionary objectForKey:@"Lollipop"];
    [lollipops addObject:lollipop];
}

#pragma mark - IBActions

- (IBAction)doneButtonPressed:(id)sender {
    
    [self dismissViewControllerAnimated:YES completion:nil];
}

- (IBAction)runButtonPressed:(id)sender {
    
    [sender setEnabled:NO];
    [queue addOperationWithBlock:^{
        
        for (NSInteger i = 0 ; i = COUNT) {
            self.label.text = [NSString stringWithFormat:@"Tap on run and I'll lick a lollipop %d times!", COUNT];
            self.progressView.progress = 0.0;
            [sender setEnabled:YES];
        }
    }];
}
}];

}

@end

当用户点击运行按钮, 应用开始一个背景线程，调用 lickLollipop 方法若干次，然后更新界面反映吃棒棒糖的数量。 lickLollipop 方法从属性列表文件(PLIST）文件读取一个长字符串，然后添加到数组上。这些数据并不重要, 能在不影响用户体验的前提下重新创建。
利用每种能够清除和重建数据而不影响用户体验的情况是好习惯。这样能够方便地释放内存，减少低内存警告。
那么，如何提高代码质量呢? 实现 didReceiveMemoryWarning 方法，像下面这样处理数据:

-(void)didReceiveMemoryWarning {
    [lollipops removeAllObjects];
    [super didReceiveMemoryWarning];
}

搞定!

下一步?

万岁，你研究了4个闪退案例! 你的应用更完善了，并且学到了一些重要的调试技巧。
你可以到 这里下载改进后的项目代码。
你喜欢iOS崩溃日志揭秘吗? 希望你能将学到的运用到你自己的应用中，也希望你能处理闪退，使你的应用更强壮!