课程：

• 1、苹果手机ios系统崩溃了怎么办？
• 2、iOS常见启动crash
• 3、iOS Crash收集与分析详解（基础篇）
• 4、如何查看iOS已上架app的崩溃情况以及定位crash代码行
• 5、ios 线程crash怎么解决
• 6、itools崩溃日志怎么看 ios crash的原因与抓取crash日志的方法

苹果手机ios系统崩溃了怎么办？

1、诊断与用量：不发送！

关掉方法：打开【设置】--【通用】--【关于本机】--【诊断与用量】--【不发送】

为什么要关掉：因为这个功能会收集你手机上所有由于崩溃产生的日志文件(有些会记录你的位置等隐私信息)，然后打包这些记录发送给苹果。举个栗子：比如你打开QQ然后闪退了或崩溃了，系统会记录这些崩溃信息并发送到苹果服务器。你点击【诊断与用量数据】就可以看到崩溃信息了如下图：

所以建议选择“不发送”。这功能对用户没有一点用处还浪费你的流量，还可能发送你的隐私信息。虽然发送“诊断与用量”理论上是可以改善苹果的服务但是效果是微乎其微的。关掉没任何不良影响！

2、基于定位服务的诊断与用量：关！

关掉方法：打开【设置】--【隐私】--【定位服务】--【系统服务】--【诊断与用量】--关闭

为什么要关掉：跟上面说的一样，这个服务会记录你的位置信息连同你的崩溃诊断数据发送给苹果服务器。对用户没一点用处。关掉没任何不良影响！

3.基于位置的iAd广告：关！

关掉方法：打开【设置】--【隐私】--【定位服务】--【系统服务】--【基于位置的iAd广告】--关闭

为什么要关掉：打开会发送你的位置信息给苹果，然后苹果根据你的位置信息给你显示跟你位置信息相关的广告。关于这个苹果也做了说明如上图右。这功能对用户没啥用处。关掉没任何不良影响！

iOS常见启动crash

1、 “Application windows are expected to have a root view controller at the end of application launch” error

    原因：All the Windows must have a rootViewController

    解决方案：给没设置rootViewController的window补充上，某些启动阶段的弹窗容易引发。

2、__abort_with_payload crash

    原因：基本上是某些库没有链接进安装包导致

    案例：前段时间在进行Xcode10适配时遇到一个挺有趣的问题，编译出的Release包在iOS11以下机型crash，而iOS11运行正常。查看了系统给出的crash日志，发现是 libprotobuf-lite.dylib没找到，这个就很诡异了，protobuf库在工程里本应是以静态库的形式链接进去的，为何这里变为了动态库，而且其路径变为了系统库路径？

莫非是链接到系统自带的pb库里去了？ 仔细检查下工程Linked Frameworks and Libraries,果然是漏掉了libprotobuf-lite.a，添加上即可。

    解决方案：double check  Linked Frameworks and Libraries settings.

iOS Crash收集与分析详解（基础篇）

最近测试妹子老是抱怨我偶现的Bug不好复现，我这边出于偷懒（其实是工作很忙）一直再说不能复现Bug的妹子不是好测试，最近闲下来了，正好谈谈Crash的收集和分析。

噔噔噔噔~万能的官方文档又出现了，先上地址

Understanding and Analyzing Application Crash Reports

如果你把你的手机连接到Mac，并选择Xcode-Windows-Device and Simulator，然后点击View Device Logs，你会看到手机上会有好多Log，其中Type为Crash的就是崩溃的Log,如下图：

1）打开设置-隐私-分析-分析数据，在其中找到你想要的应用程序的日志，日志将使用以下格式命名：应用名称 _ 崩溃时间 _ 设备名

2）选择所需的日志，复制文本或点击右上角的分享按钮分享出去，并且把分享得到的.ips.synced或者复制文本而来的.txt文件的后缀名改为.crash，因为Xcode不接受没有.crash扩展名的崩溃日志。

What the fuck??面对一大串的16进制数字你可能会感到一脸懵逼，莫惊慌，如果你仔细的看了看官方文档，你就会发现收集Crash的Log是一件很轻松的事情，然而分析Crash却并不是那么容易的事情（看完这篇文章后你会发现也很容易！！！！）

我们能把16进制数字转换成能看懂的东西么？当然可以，这个时候就需要理解dSYM符号集，细心的小伙伴在看第一张Crash流程图中可能已经发现.xcarchive文件中包含了.dSYM文件。

看到这里你可能已经知道，通过dSYM中存储的信息可以把crash日志中的16进制数字一一对应成我们看得懂的文件名、函数名和行号，这个过程就叫做符号化，那么如何做呢？

获取.crash的UUID

获取.dSYM的UUID

获取.app的的UUID

比如上图能看到三者的UUID都是一致的，可以安心去符号化文件啦。

1）如果本地存在.crash对应的.dSYM文件，则直接到上文中（1、使用Xcode从设备获取崩溃日志：）到 View Device Logs 这步，把文件拖入右边的logs列表，Xcode会自动去符号化文件，如果满眼都是16进制数字的化，点击 Re-Symbolicate Log 即可

如果你不想用Xcode去符号化，你也可以通过 symbolicatecrash 来手动符号化crash日志， symbolicatecrash 是Xcode下的一个工具。

1）首先先找到这个工具，我们通过Spotlight搜索找到 symbolicatecrash 并复制到桌面的CrashSignifying文件夹中，在这个文件夹下同样放入.crash、.dSYM文件。

2）打开终端，进入你刚才创建的CrashSignifying文件夹中，输入命令行

然后在输入

如果报No such file or directory : at ./symbolicatecrash line 909.错误，尝试执行

以上图为例，大部分字段都是不言而喻的，下面列举一些有用处的。（在官方文档都有解释，这里做归纳与翻译）

接着是最重要的堆栈信息，由下到上为最后调用的顺序：

文章写了一半开始忙了起来，第三第四节的内容现在才补上来（已经三天过去啦），如果能给小伙伴带来一点帮助，那我就很开心了，咱们下周再见。

如何查看iOS已上架app的崩溃情况以及定位crash代码行

一、先分析app的崩溃的分布情况 这个需要有（iTunes connect账号），通过分析可以查看到自己的app奔溃主要发生在那些机型上。 如果没有账号，别着急，直接走第二步。 二、打开xcode，下载崩溃日志，直接定位出问题代码行。

ios 线程crash怎么解决

Crash原因

Crash原因有共性，归纳起来有：

�6�1 内存管理错误

�6�1 程序逻辑错误

�6�1 SDK错误 （部署版本 编译版本）

�6�1 主线程阻塞

内存管理错误

内存管理是iPhone开发所要掌握的最基本问题，特别是使用引用计数手动管理内存的情况。内存管理错误包括：

�6�1 内存泄漏：未释放不会再使用对象。比如alloc忘记release,malloc忘记free。可用XcodeProduct菜单下的Analyze功能来解决该问题；

�6�1 引用出错：引用已经被释放的对象指针。很多“莫名其妙”的Crash都是由于窗体经历的生命周期所导致的（viewDidUnload、viewDidLoad），在iOSSimulator里模拟内存警告就可以解决该问题；

�6�1 内存警告：App使用的内存超出设备的限制，iOS将强制挂起App，强制挂起iOS是不会记录Crashlog，Flurry也无法记录。内存泄漏、快速/大量的分配内存都可能导致内存警告，这时候应该尽可能的释放不需要的资源。通过Instruments-Allocations里的Heapshot功能能够找出哪些资源未被释放。

WWDC 2012的Session242 - iOS App Performance_ Memory是专门讨论内存管理这个话题。

程序逻辑错误

数组越界、堆栈溢出、并发操作、逻辑错误。扎实的编码基础、严谨细致的工作习惯、清晰的思路可以避免这类错误；

SDK错误

这个错误出现的现象是有的设备运行正常，有的会Crash。原因是未找到框架、类、方法、属性。比如：用iOS5.0 SDK编译并运行在iOS4.0的设备上，5.0的Twitter框架在4.0的设备上找不到。这种问题常出现在用苹果新发布的Xcode编译原有的工程。

未找到框架的解决办法是：部署版本= 编译版本。iOS框架向后兼容做的很棒，部署版本 编译版本一般不会出现问题。

未找到类、方法、属性的解决办法是：先判断是否存在再使用

if(NSClassFromString(@"MFMailComposeViewController"))

respondsToSelector:

主线程阻塞

主线程阻塞超过10s，iOS将强制挂起App。把长时间的任务放到后台线程去执行，可使用NSThread,NSOperation, dispatch。WWDC2012的Session235 - iOS App Performance_ Responsiveness有详细的介绍。

解决Crash

思路是：定位Crash的程序代码，预测Crash原因，寻找解决方案，测试。

有多种方式可以定位Crash的程序代码：

�6�1 Debug模式时，iOSSimulator断点测试定位Crash的堆栈；

�6�1 真机连接iTunes查看Crashlog (Debug模式下)；

�6�1 通过Flurry的错误记录查看；

定位之后，就是重新思考程序上下文逻辑，并有理由的预测Crash出现的原因。预测的越多，理解的越深。

寻找解决方案的方法有：

�6�1 浏览苹果官方SDK文档，找出错误原因；

�6�1 Google搜索Crash输出的信息，重点查找行业内技术论坛：cocoachina、stackoverflow、iphonedevsdk等；

�6�1 查看历届WWDC的视频、示例代码；

�6�1 在工程里添加环境变量: NSZombieEnabled、NSDebugEnabled，输出有价值的信息；

�6�1 如果未找到任何信息，可以寻求苹果官方论坛、业内技术论坛的帮助；

测试

找到解决方案后就需要测试，测试功能输入输出的准确性、程序性能、是否引入新的bug。测试有专业的测试工程师来负责，但开发工程师不能依赖测试工程师来发现问题，尽量独立解决已知存在的问题。

由于Xcode部署工程到真机上比较耗时间，如果可以的话尽可能用iOSSimulator来测试，以减少测试的时间。

建议开发工程师有一个checklist，在产品测试时自己逐一过一下上面常见的问题，这个能够避免大部分Crash。下图是我们一个产品的FlurryError记录，那120个错误Session是测试Crash时留下的。当然这个记录是没有包括iOS将强制挂起App的情况。

itools崩溃日志怎么看 ios crash的原因与抓取crash日志的方法

一、先分析app的崩溃的分布情况 这个需要有（iTunes connect），通过分析可以查看到自己的app奔溃主要发生在那些机型上。 如果没有，别着急，直接走第二步。 二、打开xcode，崩溃日志，直接定位出问题代码行。