本文把重点自己介绍的放在了前面，后面两部分是扩充，大牛写的比我的好，后面两部分大家可以参考他们完整的文章。
3. 代码bug 重点解析
1.首先必须有，crash日志和.DSYM文件：步骤
1.找到之前上传到AppStore的.xcarchive文件，XCode->Window->Orgainize，右键在Finder中显示
2.右键显示包内容进入dSYMs文件夹，找到.dSYM文件
3.然后通过Terminal工具跳转到.dSYM文件
$ cd ~/Library/Developer/Xcode/Archives/yyyy-mm-dd/appname.xcarchive/dSYMs/appname.app.dSYM
4.通过ls与cd指令进入DWARF路径
kermitdeMacBook-Air:appname.app.dSYM kermit$ ls
Contents
kermitdeMacBook-Air:appname.app.dSYM kermit$ cd contents
kermitdeMacBook-Air:contents kermit$ ls
Info.plist Resources
kermitdeMacBook-Air:contents kermit$ cd resources
kermitdeMacBook-Air:resources kermit$ ls
DWARF
kermitdeMacBook-Air:resources kermit$ cd dwarf
kermitdeMacBook-Air:dwarf kermit$ ls
appname
5.根据处内存地址反编译找到源码行
$ atos -arch arm64 -o appname 0x********
如果以上没有找到具体的行的话：那么如图：转成16进制【偏移地址】
接着如图输入，即可找到对应的行了。
也可以转成16进制后进入crash文件中找到对应的基地址，按第五步执行也能找到。
1.获取崩溃日志的几种方法：
-
1、当用户抱怨闪退时，你可以要求他让设备与iTunes同步，设备与电脑上的iTunes Store同步后，会将崩溃日志保存在电脑上(路径：Mac OS X:~/Library/Logs/CrashReporter/MobileDevice/)到上述位置把崩溃日志下载下来，然后通过电子邮件发送给你；
用这个方法获取崩溃日志时，你必需尽量获取用户设备生成的所有崩溃日志。因为崩溃日志越多，就越容易诊断问题所在。
-
2、如果你装了Xcode，也能很容易通过Xcode从你的设备上获得崩溃日志；将iOS设备连接到电脑上，然后打开Xcode；
xcode7.3中从菜单栏上选择 Window菜单, 然后选择 Devices (快捷方式是 Shift-CMD-2)在窗口上, 选中 Devices 标签栏，在左侧的导航面板上，选中设备名称；Devices information下面的Device Logs是你所有设备（曾经连接到Xcode的）的日志；每个设备下面的Device Logs是对应设备的日志。
3、应用提交到App Store后，你也能从iTunes Connect 获取到用户的崩溃日志，登录到iTunes Connect 上，选择 Manage Your Applications， 点击相应的应用，点击应用图标下面的View Details按钮， 然后点击右栏Links部分的 Crash Reports；如果没有崩溃日志，试试点击Refresh按钮刷新一下。如果你的应用用户量还不多，或者刚上架不久，iTunes Connect账号上也可能还没有任何崩溃日志；如果有的话你就会看到不同iOS版本用户下的崩溃信息。
2.crash日志分析
一、如何获得crash日志
当一个iOS应用程序崩溃时，系统会创建一份crash日志保存在设备上。这份crash日志记录着应用程序崩溃时的信息，通常包含着每个执行线程的栈调用信息（低内存闪退日志例外），对于开发人员定位问题很有帮助。
如果设备就在身边，可以连接设备，打开Xcode - Window - Organizer，在左侧面板中选择Device Logs（可以选择具体设备的Device Logs或者Library下所有设备的Device Logs），然后根据时间排序查看设备上的crash日志。这是开发、测试阶段最经常采用的方式。
如果应用程序已经提交到App Store发布，用户已经安装使用了，那么开发者可以通过iTunes Connect（Manage Your Applications - View Details - Crash Reports）获取用户的crash日志。不过这并不是100%有效的，而且大多数开发者并不依赖于此，因为这需要用户设备同意上传相关信息。
考虑到并不是所有iPhone用户都允许自动发送诊断报告（crash日志），而且对于部分提交到Apple得crash日志，开发者还需要手动去拉取，然后找到对应的符号文件进行解析——这是一件很繁琐的事情。所以实际项目开发中，通常接入现有的crash收集工具，或者自己编写一个进行自动化收集、解析和统计汇总。
二、如何解析crash日志
当获得一份crash日志时，我们需要将初始展示的十六进制地址等原始信息映射为源代码级别的方法名称和代码行数，使其对开发人员可读。这个过程称为符号化解析。要成功地符号化解析一份crash日志，我们需要有对应的应用程序二进制文件以及符号（.dSYM）文件。
如果处于开发调试阶段，通常Xcode都能匹配到crash日志对应的二进制文件和符号文件，所以能够帮我们自动解析。
如果处于测试阶段，测试人员已经安装了不同的版本（比如alpha、beta版本），那么需要保存好对应版本的二进制文件和符号文件，以便在应用程序崩溃时对crash日志进行解析。对于这种场景下产生的crash日志，只需要将.crash文件、.app文件和.dSYM文件三者放在同一个目录下，然后将.crash文件拖放到Xcode - Window - Organizer中左侧面板Library下的Device Logs中，即可进行解析。
如果要提交发布，那么我们通常会先执行Clean，再Build，最后通过Product - Archive来打包。这样，Xcode会将二进制文件和符号文件归档在一起，可以通过Organizer中的Archives进行浏览。
三、如何分析crash日志
1.iOS策略
1.1 低内存闪退
1.2 Watchdog超时
1.3 用户强制退出
2.常见错误标识
2.1 Exception codes
2.2 Exception types
3.代码bug 重点分析
以上只是列举了一些crash日志的情况，具体的分析请参考：
http://blog.csdn.net/jasonblog/article/details/19031517
http://www.cocoachina.com/industry/20130725/6677.html
那么，比较常见的崩溃基本都源于代码bug，比如数组越界、插空、多线程安全性、访问野指针、发送未实现的selector等。如果引入Core Data，则又有另外一些常见问题，不过这是另一个话题了。
遇到这些bug时，都有比较清楚的错误原因说明，比如“index 0 beyond bounds for empty array”等。需要稍微注意点的是多线程问题，当一时找不到解决思路时，不妨往多线程方面考虑下。
