使你明白崩溃日志，从而调试改Bug不再困难

一般log日记在哪里呢？在 ~/Library/Logs/CrashReporter/MobileDevice/<设备名》
什么样的情况下会产生crash 日志呢？
1，你的App违反了操作系统的政策；2，你的App有bug
关于违反操作系统的政策有如下情况：例如在启动的时候看门狗超时，执行，禁止或者退出；用户强制退出，低内存运行等。
看门狗超时
可能很多人都意识到了，自从ios4以后，当你视图退出App时候，App不再结束，相反进入了后台运行。
如果你的App响应的不足够快，你的操作系统将结束你的App和生成一个崩溃日志
这些事件的响应就会在以下方法内进行

• application:didFinishLaunchingWithOptions:
• applicationWillResignActive:
• applicationDidEnterBackground:
• applicationWillEnterForeground:
• applicationDidBecomeActive:
• applicationWillTerminate
  以上方法得到了一个有限的时间内去完成它的进程。如果你的App花费时间太久，则操作系统会结束App。如果你在后台线程执行较长的运行操作（例如网络存储），这个很容易发生，这时候就牵涉多线程的问题；
  2，用户强制退出
  iOS4.x以后支持多任务。如果一个App阻塞了UI，停止了响应，用户能双击home键返回到主屏幕。在这个情况下就会生成崩溃log。当你双击home键后，你能注意到你也得到了你在过去所有运行的App列表。这些App是没有必要进行的，或者它们必须被禁止。
  通常一个App一旦用户点击了home键后，则会在后台保持十分钟，然后被操作系统自动结束。删除这些App的icon则不会生成崩溃log。
  3，低内存终止
  当子类化UIViewController时，你会注意到一个方法-didReceiveMemoryWarning。一个运行在前台的任意App都有最高的优先级去存储和使用内存，然而这并不意味着App能得到这个设备上的可用内存-每个App得到一部分可用的内存。
  当总内存消耗到一个特定的等级后，操作系统发出UIApplicationDidReceiveMemoryWarningnotification,同时didReceiveMemoryWarning被调用。基于这一点，去使得你的App继续恰当的运行。操作系统开始终结这些App到后台以释放出一些内存，一旦所有后台的App被结束，如果你的App仍然需要更多的内存，操作系统终结你的App并且生成崩溃日志。
  3，App的bug
  一般而言，崩溃日志是由以下几部分组成
  3.1进程信息：意外的标示符（对于崩溃报告而言的统一标示符），崩溃报告key（是被mapped到设备的统一的key，它是匿名的，但是能给你有用的信息，如果你从同样的崩溃报告key中得到了100个崩溃日志，说明问题并不是广泛的，仅仅限制于一些设备或者少部分的设备），硬件模型（表明设备的类型），process（App的名字）
  3.2基本信息（包含崩溃的时间，设备运行的ios版本）
  3.3异常-可以看到异常的类型在崩溃的时刻被抛出
  3.4 线程的往返-者提供了线程往返的日志对于App中的所有线程。它一般有四行：1，帧数 2，二进制的名字 3，函数被调用的地址 4被分为二个字行 -一个基类地址和抵消
  3.5 线程状态-给你在注册的时候给你一个值，通常而言这一块是没有必要被重视的，因为线程返回已经给足够的信息让我们发现问题
  3.6 二进制图像-这一部分列举了所有在崩溃的时候被加载的二进制文件。
  异常的代码
  0x8badf00d ，这句代码提示你App因为看门狗超时被操作系统终止了。通常App花费太长的时间去启动或者响应事件。
  0xbad22222：这句代码提示一个VoIP应用被iOS结束，因为它执行太过于频繁
  0xdead10cc：它提示app呗ios终结因为它在一个系统资源上持有，当运行在后台的时候，通讯录的数据库

0xdeadfa11：它表明,一个应用程序被用户强行退出。每个苹果,当用户用力气压住开/关按钮,直到出现“滑动关机”。根据苹果公司文档,一个用力按住退出事件导致一个0 xdeadfa11异常代码,大概是因为应用程序变得反应迟钝。
From:https://www.raywenderlich.com/23704/demystifying-ios-application-crash-logs