在业界，用很多有名的 Crash 监听工具，如闭源的 Firebase(Crashlytics)、Bugly 等，也有开源 PLCrashReporter、KSCrash 等。KSCrash 就是其中享有盛名的一个开源库。KSCrash 有对准抓取准确、接口设计优秀、Crash 文件易于二次分析的优点。也因此网上有很多分析 KSCrash 的文章。但这些文章往往太过于追求逻辑细节，而没有对整体架构的梳理，使得读者还是难以自己真正理解 KSCrash 。

为了让大家对 KSCrash 有个整体的理解，我将会使用 UML 图来分析 KSCrash，不熟悉的读者建议先自行了解。

本文是Crash 系列的第三篇，这个系列的目录如下：

• Crash 的监听
• 堆栈分析
• KSCrash 源码解析

一 KSCrash 的主要模块

1. KSCrash 的核心

KSCrash 的核心在于KSCrashC.c，这个文件包括了KSCrash 系统的所有重要入口。KSCrash.m是对KSCrashC.c的封装。

KSCrashC.c的主要部分如下：

• Installation

  kscrash_install()负责初始化 KSCrash 系统以监听 Crash。你可以通过kscrash_setMonitoring文件里面的函数来配置 KSCrash

• Configuration

  所有的主要设置项都要可以通过类似kscrash_setXYZ的方法设置

• App State

  KSCrash hook 了大量的app 状态变更的通知，这些 hook 方法的命名为kscrash_notifyXYZ。

• Crash Entry Point

  onCrash函数是处理 Crash 的主要方法，它负责获取 app 状态，写 crash 文件(JSON)，分析 crash 等。

• Report Management

  这个文件包括一些底层的 C 方法用来处理 crash 文件，如：kscrash_getReportCount()、kscrash_getReportIDs()、kscrash_readReport()、kscrash_deleteReportWithID()等。

• Enabling / Disabling KSCrash

  你可以用kscrash_setMonitoring方法设置启用某些 crash 监听，如：Mach 监听、Signal 监听等

2. KSCrash 的主要架构

下图是我整理的 KSCrash 核心逻辑。通过下图可以对KSCrash 有个整体的认知:

KSCrash

限于篇幅，上图只整理了核心的 Crash 监听相关的逻辑。在上图我们会看到类似继承/抽象类的概念。可能有读者会疑惑，KSCrash 是用 C 语言写的，哪来的类哪来的继承呢。

实际上， 当我们细细去理解 KSCrash 的代码，我们会发现每一个 C 语言的文件的行为其实类似于一个类，并且每个方法可以理解为类的方法。只是在 C 语言的语法下，很多方法都会有一个参数表示类实例。

当然一下子看一个整体的类图，我们也会比较茫然。所以我将会在下面对每个主功能模块做讲解。

二 KSCrash 的主要功能模块和运行逻辑

1. Installation

首先要讲的是 KSCrash 的初始化部分，我们可以从这里粗略了解到 KSCrash 是如何设计分离各种 Crash 监听模型。

Install

KSCrashMonitorType

这个枚举定义了所有的 Crash 监听类型，比如 Mach 监听、Signal 监听等。这个枚举是 Options 类型的，也就是它的值是按位偏移的。这也意味着一个 Type 的值实际代表的是一个类型集合，比如 KSCrashMonitorTypeAll 代表的是所有监听类型，KSCrashMonitorTypeDebuggerUnsafe代表的是 Xcode 联调的时候不宜打开的监听类型等。

KSCrashMonitor 和 Monitor

Monitor 是对各种监听的一种抽象，KSCrashMonitor 持有一个 Monitor 类型的数组，并管理 Type 和 Monitor 的对应关系。在初始化的时候，KSCrashMonitor 会根据运行环境，以及传入参数，来决定需要初始化哪些 Crash 监听。并且会循环执行各种监听的初始化工作: setEnabled初始化监听，isEnabled 初始化是否成功。

Monitor

下图是Monitor抽象结构和各种 KSCrashMonitor的关系。其中setEnabled、isEnabled、addContextualInfoToEvent是抽象接口，也就是说各种底下的KSCrashMonitor都有这些方法。

Monitor

当然实际上这种抽象的实现是依赖于结构体Monitor，他的结构如下：

typedef struct
{
    KSCrashMonitorType monitorType;
    KSCrashMonitorAPI* (*getAPI)(void);
} Monitor;

typedef struct
{
    void (*setEnabled)(bool isEnabled);
    bool (*isEnabled)(void);
    void (*addContextualInfoToEvent)(struct KSCrash_MonitorContext* eventContext);
} KSCrashMonitorAPI;

在各种Monitor中，会有类似的getAPI方法，其实就是返回抽象接口对应的具体实现的函数指针。比如在KSCrashMonitor_MachException中：

KSCrashMonitorAPI* kscm_machexception_getAPI()
{
    static KSCrashMonitorAPI api =
    {
#if KSCRASH_HAS_MACH
        .setEnabled = setEnabled,
        .isEnabled = isEnabled,
        .addContextualInfoToEvent = addContextualInfoToEvent
#endif
    };
    return &api;
}

各种监听的初始化流程

KSCrash 的初始化监听的大致调用流程如上图所示，需要注意的是setMonitorEnabled后面部分是一个循环过程，KSCrashMointor_XXX代表各种类型的 Monitor。

2. Crash 信息的存储结构

在KSCrash中主要依靠KSCrash_MonitorContext、KSMachineContext来记录 Crash 发生时的上下文信息，比如线程信息、寄存器信息、Crash 类型以及特征等。这块的结构如下：

KSCrash_MonitorContext

记录 Crash 中的 crash 类型、crash 原因等，详见 KSCrash 的源码或者上图

KSMachineContext

记录 Crash 发生在哪个线程，以及 Crash 时的所有线程列表还有寄存器信息（machineContext）。如上图所示，KSMachineContext有两个初始化方法。分别靠Thread和Signal来初始化。

KSStackCursor

可以理解为是一个游标，指向当前正在分析的函数堆栈位置。这里有个核心的方法advanceCursor，这个方法的作用是函数堆栈向下溯源。从前面两篇文章，我们知道不同情况下函数溯源的方式不同，比如 Mach 异常和 Signal 异常靠的是 FP/LR 寄存器信息，NSThread 异常则是靠指针数组溯源。

上图是列举的几种实现特殊的 Cursor。比如MachineContext用于需要使用 FP/LR 寄存器溯源的情况，Backtrace用于使用堆栈指针数组的情况。

上图是简单的异常处理类溯源方式的一种对应关系。

3. Crash 的处理过程(KSCrashReport)

首先我们看一下 Crash 处理时相关的类：

KSCrashReport

从字面意义上看，KSCrashReport是将 Crash 信息变成文件的处理类。但实际上他还是 Crash 信息的进一步组织整理者。KSCrashReport会将收到的 Crash 信息分析出来，并分析函数调用栈、线程等相关信息，然后将其整理成一个 json 文件。在后续，开发者可以根据自己的需要将这个 json 文件变成标准的苹果 crash 文件或者其他格式的文件

Crash 的处理流程

从抽象角度上讲，一个 Crash 的处理流程实际上就是：

1. Monitor 监听到 Crash 发生
2. Mointor 分析 Crash 堆栈信息，错误原因等，并生成一个KSCrash_MonitorContext实例
3. Monitor 调用KSCrashMonitor的handleException方法，将第2步生成的 context 实例传入。
4. handleException调用KSCrash的onCrash方法处理 crash
5. onCrash调用KSCrashReport将 Crash 信息转换为标准文件(wrtieStandReport)，期间会循环访问 Cursor 的advanceCursor方法

以下以 MachException 为例，展示一个 crash 分析堆栈的处理过程。

需要注意的是，writeAllThreads方法里面有一个特殊的处理逻辑，在循环处理所有线程时，它会判断正在处理的线程是不是 Crash 发生时的线程，如果是则writeThread将会使用KSCrash_MonitorContext的offendingMachineContext来处理线程的回溯。如果是看过我前两篇分析 crash 的文章，就会知道 Crash 线程的回溯在不同的情况下各有不同，不能和其他线程采用同样的处理方式。

三 总结

到这里，这篇文章就结束。我没有像其他分析 KSCrash 的文章一样去详细分析 Mach 异常、Signal 异常等是怎么处理的，因为如何分析这些异常在前两篇文章我早已讲过。在这篇文章我采用大量的类图来讲解 KSCrash 的结构，是希望帮助像我一样缺少 C 语言开发经验的人可以轻松理解 KSCrash 的架构，减少理解 KSCrash 的成本。如果有读者在看完我三篇文章后，还是不能理解 KSCrash 是如何分析 Crash 的，可以结合本文参考一下网上其他分析 KSCrash 的文章，如iOS Crash 收集框架 KSCrash 源码解析等。

本文写于2022牛年的最后一天，提前祝大家新年快乐！如果我的文章帮助到你，请轻轻的点个赞喔~