异常退出分析
iOS 异常退出分析包含了 App 进程的所有退出情况，包括异常和正常的退出。Bugly 原有监控下，与进程退出相关的指标有 Crash、ANR 和 FOOM 三类退出。
- Crash 是指程序崩溃导致退出的情况，在 iOS 系统中，crash 是指程序运行过程中出现了严重错误而终止运行的情况；
- ANR 是指 App 在响应用户或系统事件时超时，被系统通过 SIGKILL 信号终止进程的情况；
- FOOM 是指 App 进程占用了过多内存，触发到系统内存上限后，被系统通过 SIGKILL 信号终止的情况。
但在实践中发现，除此以上情况外，还有其他因素导致 App 进程异常退出。而上述类型未考虑到这类情况，部分退出不是被错误归类到其他类型中，就是丢弃无感知了。为了将这些情况都监控起来，Bugly 新增了异常退出分析能力。
异常退出类型
在异常退出中，Bugly 会在每一次进程启动时，检查上一次进程退出前的最后状态，以判读上一次退出的原因。因此，理论上每一次进程的退出，都可以在异常退出中找到其进程退出前的最后信息。
按照进程最后信息进行分类判断，目前情况下，Bugly 将退出进行了以下分类：
异常退出
- Crash(可捕获)：传统的 crash 退出；
- ANR：主线程卡死超时，被系统杀死；
- FOOM：触发到系统内存限制，被系统杀死；
- 启动超时：启动超时，被系统杀死（也可以理解为启动阶段卡死）；
- 键盘启动超时：键盘创建超时退出，仅适用于键盘 Extension，App 进程无此项；
- 其他：其他未判断出的退出情况；
正常退出
- 用户退出：用户杀进程；
- 设备重启/升级：设备重启或 App 更新导致的进程重启动；
- 后台被杀：App 在后台被系统杀死（基于 iOS 进程管理方式，后台回收资源等情况杀死 App 进程）；
异常退出数据
每一次进程退出的上报，会包含如下信息：
基本信息
基本信息与 Bugly 中的其他个例上报类似，包含基本信息，如用户ID、设备ID 等，此处不再赘述。与该监控相关的信息只有退出原因一条，其取值为对应的退出原因，时上述退出类型的枚举值之一。
上报信息
上报信息也会类似，包含的是退出的基本信息，如上报时间、发生时间等，不再赘述。有两点不同需要格外强调：
- 发生时间：由于退出事件的特殊，例如被 SIGKILL 杀死或着后台挂起进程的退出等，无法直接获得其发生的时间，Bugly 会取监控到的最后活跃时间作为事件发生时间；
- 关联异常：若此次退出为 Crash、ANR 或 FOOM，这类已监控到的类型，此处会展示其对应链接，可点击跳转到对应事件的详细信息查看；
退出附件
退出附件中包含的信息为目前 Bugly 为监控 App 退出收集到的各类信息，因此并非每一条信息都与当前的退出有直接的关联，此处提供仅是为了方便查看和作为判定的参考作用。
tick info
tick info 包含的是 Bugly 周期监控采集到 App 中的最后状态，其主要字段和含义如下：
last_vc: 最后一次采集到的 ViewController 名称，若业务通过+[Bugly setSecene:]设置了自定义场景，则此处为设置的对应值；last_app_state: App 最后状态，为 int 枚举值，其取值与UIApplicationState一致；app_state_update_time: App 最后状态更新时间，标准 UNIX 时间戳，单位为秒；app_fg_active_time: App 前台活跃时常，单位为秒。需要注意的是，此值在 App 退后台时才会更新，因此当前表现的值为上一次退后台前的活跃时长，若一直未进入后台，则此值为 0；last_enter_fg_time: App 上一次进入前台的时间，标准 UNIX 时间戳，单位为秒。使用最后活跃时间last_active_time减去此值，便可以获得最后一次在前台的活跃时长，即可用这种方式更新app_fg_active_time；last_active_time: App 最后活跃时间，标准 UNIX 时间戳，单位为秒；main_thread_tick_last_time: 主线程最后活跃时间，标准 UNIX 时间戳，单位为秒；main_thread_tick_times: 主线程活跃次数，在主线程的每一个 runloop 中，进行一次活跃检查，记录最后活跃时间，并统计此次数；looper_monitor_tick_last_time: 卡顿监控线程的最后活跃时间，标准 UNIX 时间戳，单位为秒；looper_monitor_tick_times: 卡顿监控线程活跃次数，在卡顿监控线程的每一个检查周期中，更新其最后活跃时间，并统计此次数；
tick info 中的信息主要用于判定 App 的最后状态。例如 App 最后状态是在前台还是后台，主线程是否正常活跃，最有状态是否与监控线程同步活跃而非卡死等信息。
exit info
exit info 包含的是监控到 App 退出相关的信息，其主要字段和含义如下：
signal: Crash 监控到的 signal 信号，该值与<sys/signal.h>中的SIGXXX一致；exception: Crash 监控到的 exception 值，该值与<mach/exception_types.h>中的EXC_XXX_XXX一致；exc_code: exception 对应的 code 值，其包含两个值 code1 与 code2，详细定义可查看ux_exception.c中定义（XNU内核源码）；code1code2
is_deadlock: 是否是 deadlock（ANR），由 Bugly 卡顿监控模块提供；is_crash: 是否是已捕获 crash，由 Bugly Crash 监控模块提供；is_exit: 是否是调用 exit() 产生的退出，该退出为进程正常退出；is_terminate: 是否是用户手动杀进程，该值由 UIKit 中UIApplicationWillTerminate提供；cpu_wakeups: cpu wakeups 信息，由 Bugly 周期采集获得；wakeups_count:interrupt_wakeups_count:timer_wakeups_count:wakeups_duration: 对应 wakeups 信息的持续时间，单位为秒；
last_update_time: exit info 最后更新时间，标准 UNIX 时间戳，单位为秒；
exit info 中的信息主要是程序执行过程中的异常信息，如触发内存错误时的 signal 信号等。cpu_wakeups 的信息主要是程序执行过程中的 CPU 唤醒信息，在 iOS 系统中，高 wakeups 的情况，会触发系统告警或杀死进程。
在目前收集到的系统 wakeups 报告中，wakeups 的限制为 300s 内平均 150 次每秒。
vmmap info
vmmap info 提供进程活跃期间，最高内存峰值时采集的 vmmap 信息。其信息的含义与展示方式与 FOOM 中的 vmmap info 相同。
vmmap 信息的目的是提供 App 进程活跃期间的内存峰值大致情况，对于部分 FOOM 但未被准确判定的问题可能有一定的帮助。
统计分析
异常退出分析更重要的作用是提供给业务各退出问题的占比情况，因此统计分析的意义更大。
Bugly 目前提供“数据概览”、“上报趋势”、“异常退出原因分析”及“统计分布”几项分析能力。所有的统计分析，都是展示当前筛选条件下筛选出的数据的统计情况。
与其他指标和个例类似，Bugly 提供了丰富的筛选条件可供选择，除了基础类型外，在异常退出分析中，提供了退出原因筛选条件，可以多选，以便筛选出需要关注的退出类型。
数据概览
数据概览展示当前选中数据中的整体情况，包括“异常退出次数”、“影响用户数”、“影响设备数”、“异常退出率”、“正常退出次数”。各个指标的含义和计算如下：
- 总退出次数：总共上报的退出次数（因内存指标为每次启动报上一次的退出数据，可以理解为上报的次数，除未开启监控部分）；
- 异常退出次数：前述中属于异常退出类型的数量；
- 正常退出次数：前述中属于正常退出类型的数量；
- 异常退出率：异常退出次数/总退出次数；
- 总退出设备数：总退出次数按照设备id去重；
- 总退出用户数：总退出次数按照用户id去重；
- 异常退出设备数：异常退出按照设备id去重；
- 异常退出用户数：异常退出按照用户id去重；
- 异常退出设备率：异常退出设备数/总退出设备数；
- 异常退出用户率：异常退出用户数/总退出用户数；
需要注意的是，此处所有的计算，都是基于上面筛选条件进行的统计。意味着若是选中的退出原因中都是异常退出，则此处的异常退出率可能为 100%。
上报趋势
上报趋势中，会将数据概览中的各项指标，按照时间粒度统计，展示其对应的趋势变化情况。
异常退出原因分析
异常退出原因分析，则是将现选中数据中的退出，按照退出类型进行统计，可以选择对应的指标进行展示。
统计分布
统计分布则是对应数据在不同维度下的分布情况，例如当前数据下，按照应用版本统计，看各个版本中的占比。可在“设置”中选择需要展示的维度，此处支持的维度选择和其他统计分布类似。