Android

Android 基于linux内核，使用 signal机制监听异常发生。值得一提的是，android 在自定义的libc库中(bionic)的linker初始化中会将debuggerd handler注册为默认的signal handler

Kernel (linux)

在cpu运行时发生错误，linux为这类错误注册了默认的异常处理程序，异常处理程序将执行：
1.保存大部分寄存器的内容
2.使用高级的C函数处理异常（向异常调用进程发送信号），在用户态处理异常（由于libc库中注册了默认处理函数，所以会在用户态处理函数）
3.通过ret_from_exception()从异常处理程序中退出

Native Process

Native进程直接使用signal机制进行异常处理，既可以使用默认的signal_handler，也可以使用自定义的。默认的signal handler将在自定义的处理完成之后继续执行。在此层开发应用的开发者可以使用signal来感知异常的发生。

Runtime Process

取决于Runtime自己的实现
ART会在启动时注册Signal SEGV，将由kernel产生的异常解释成Java的异常
Java的异常会在调用链上抛出，直到被捕获，如果该异常在整个调用过程中没有被捕获会触发默认的异常处理函数，UncaughtExceptionHandler。虚拟机进程在API中提供setUncaughtException接口，为开发者提供VM级别的异常的感知。
当然，VM Process通过jni依然能够使用signal机制来感知native的异常。

Excecption Collector

Android提供系统级的异常事件收集器，所有运行的进程在默认配置下最终会调用addErroToDropBox将异常日志保存只dropbox路径，以便统一打包。由于DropBoxManagerService属于AOSP，这里只包含了打包以及管理的部分， 并不包含上传云端的部分。
本地使用firebase，云端使用android vitals

Recovery API

未提供异常恢复相关API

ChromeOs

ChromeOs可以近似理解为在linux(非GUI)+chrome（GUI）。所以大部分的机制与Android类似，区别在于ChromeOs未为所有进程注册统一的默认的用户态异常处理程序。ChromeOs能够运行 1.Chrome App，运行在chrome的容器里，使用H5 Js以及css编写
2.Android App，运行在Android Runtime for chrome(ARC)里
3.linux原生App，

Kernel (linux)

ChromeOs与Android区别在于没有默认注册的用户态异常处理程序，默认的处理方式为
1.coredump
2.send coredump to crash reporter
可以通过修改 /proc/sys/kernel/core_pattern 来修改默认的异常收集器

Native Process

与 Android 类似

Runtime Process

与 Android 类似

Excecption Collector

ChromeOs使用crash reporter收集异常信息,产生统计信息，并定期上报云端。

Recovery API

未提供异常恢复相关API

基于liunx的系统在kernel、Native Process、以及Vm Process上有着相似的实现方式，因为其都是基于Signal机制的。而在最终的异常事件收集器上有所差异。

MacOs(iOS)

iOS以及MacOs在架构上类似，并且使用相同的内核XNU，这是一个混合内核。 XNU包含Mach(微内核)，bsd的实现是对Mach的封装。

Kernel (mach)

在cpu运行时发生错误，会触发mach的异常处理程序exception_triage()，将异常转化为Mach消息。再调用exception_deliver()，将异常投递给thread、task以及host。
kernel的异常可以通过set_exception_ports系列系统调用进行监听(阻塞)

Native Process

由于mach异常会通过bsd的包装再次以信号的形式发出，进程既可以直接使用kernel的方式阻塞监听mach的异常，也可以通过unix的信号机制，注册监听。

Runtime Process

可以通过NSSetUncaughtExceptionHandler方式监听，实际上是对Signal监听的封装

Excecption Collector

ReportCrash被用于收集上报设备中发生的Crash事件。
Refs：https://help.apple.com/xcode/mac/current/#/dev675635e70
设备使能日志上传
云端使用App Store Connect

Recovery API

Recovery Attempter(MacOs)
Refs：https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/RecoverFromErrors/RecoverFromErrors.html#//apple_ref/doc/uid/TP40001806-CH206-BCIDEGGF

Windows

Windows同样使用混合内核(微内核)。

Kernel

由于windows闭源，未向开发者提供kernel的异常处理接口。并且大部分的kernel异常会直接在kernel中处理。例如蓝屏

Native Process

通过SetUnhandledExceptionFilter监听进程异常

Runtime Process

使用Runtime的机制处理异常

Excecption Collector

Windows Error Reporting，在UnhandledExceptionFilter通知WER服务分析完异常之后，会通知用户处理异常。

Recovery API

Last Known Good And SCM‘s FailureActions

Fuchsia

Fuchsia使用名为Zircon的微内核，与darwin-xnu同样使用exception ports的概念来处理异常。任意thread、process以及jod均有自己的exception port

Kernel

可以通过zx_task_bind_exception_port将自定的handler用于处理目标对象产生的异常

Native Process

可以通过zx_task_bind_exception_port将自定的handler用于处理目标对象产生的异常
默认使用CrashService将Exception转发给用户态的crash analyzer处理

Runtime Process

使用Runtime的机制处理异常
Dart：unhandled_exception_callback
转发给用户态的crash analyzer处理

Excecption Collector

crash analyzer生成crash report。

Recovery API

未提供异常恢复相关API