Crash分析

SIGABRT：异常终止条件，例如abort()所发动者

SIGSEGV：非法内存访问（段错误）

SIGTERM: 发送给程序的终止请求

SIGINT: 外部中断，通常为用户所发动

SIGILL: 非法程序映像，例如非法指令

SIGFPE: 错误的算术运算，例如除以零

0x8badf00d表示app在一定时间内无响应被watchdog杀掉,对此类crash，应该审查app在初始化时的 *** 作是否正确，是否在主线程请求了网络调用或者其他耗时的 *** 作方法卡住了正常初始化流程。简单来说就是看门狗超时，在iOSapp上，经常出现在执行一个同步网络请求调用而阻塞主线程的情况

0xdeadfa11 表示app被用户强制退出

0xc00010ff 表示app因运行温度过高而被杀掉

用户手机上 设置 ->隐私 ->分析 里面的，可以连接电脑 Xcode 导出。

在 Xcode ->Window ->Organizer ->Crashes 里面可以查看

优点: 理论上捕获类型最全，因为是 launchd 进程捕获的日志。

缺点：不是全量日志，因为需要用户隐私授权才会上报，没有数据化支撑。

接入一些 APM 产品， 如 EMAS、mPaaS、phabricator 等。

接入 PLCrashReporter 、 KSCrash 等 SDK 进行收集，上报到自建平台统计

优点：可以自建数据化支撑，获取 Crash 率等指标。

缺点：存在无法捕获的 Crash 的类型。

苹果收集的日志，Xcode会自动帮我们符号化，如果你没有发布包，比如是别人电脑打包的发布包，或者是一些平台上打的包，只需要你把 xcarchive 拷贝到 $HOME/Library/Developer/Xcode/Archives 目录下之后，Xcode 就可以自动帮你符号化了。

“.app”, “.dSYM”和 ".crash"文件放到同一个目录下

设置环境变量路径

终端下执行命令：

在审核时或线上版本中经常会出现各种离奇的崩溃，本文以命令行分析崩溃定位：

准备：

参考&引用&拓展阅读

android framework分为java和native两层

native运行于C的runtime，高效。一般java层只是封装，通过jni访问native底层HAL,driver的crash也会导致上层的crash ‍

，有效利用Log信息并对其进行分析与实时的监控管理，对于分析Android手机发生Crash的原因具有极为重要的作用。

Android Log 文件类型

由于Android上的应用程序千差万别，出现的问题也不尽相同。不过Bug类型还是有规律可循的，可以根据生成的Log文件找到相应的错误，通常错误信息里记录了错误的大致位置，据此可以捕获到问题的关键信息。

Log文件记录着每次 *** 作的信息，在出现问题后可以借助log信息分析以达到解决问题的目的，Log文件类型主要分为以下几种：

(1) Logcat: Main缓存日志，通过运行logcat命令，可以获得系统中使用的标记和优先级的列表，也可以加上过滤器进行表达式限制，只输出测试人员及研发人员感兴趣的标记-优先级组合。

……………………

(2) Bugreport: Java应用程序Crash时会产生一个Bugreport文件，该文件主要包括三个方面的内容：

Dumpstate：内存信息，Cpu信息，Procrank信息，系统日志，Vm Trace信息等。

Build.Prop：当前版本、当前命令、显示系统Build的一些属性等；

Dumpsys：Dump Of Service Meminfo(显示某个进程更详细的内存消耗情况以及Native And Java (Dalvik)堆栈的统计数) ；

(3) Crashdump: 每次Crash都会产生一个Crashdump文件，文件包括主日志，Java 堆栈信息，本地调用堆栈，虚拟机/进程堆，Log缓存，内存信息，进程列表，Modem信息，Adb Log等信息；

(4) Bratlog: 测试用例及详细信息；

(5) Logalong: 事件，如手机通讯功能信息等；

(6) Pullfs: Traces(Java 堆栈信息)；

(7) Procrank: Uss(Unique Set Size) 值，进程独自占用的物理内存。

一、先分析app的崩溃的分布情况 这个需要有（iTunes connect账号），通过分析可以查看到自己的app奔溃主要发生在那些机型上。 如果没有账号，别着急，直接走第二步。

二、打开xcode，下载崩溃日志，直接定位出问题代码行。

---