1.进程的cpu调度等待时间 /proc/pid/stat
2.OOM 内存溢出被内核杀死
进程自身 OOM 预警和监控其他进程 OOM 事件
eBPF 监测 OOM（推荐，通用 / 实时 / 低开销）
通过 kprobe（内核探针） 挂钩 Linux 内核的 oom_kill_process 函数（OOM killer 杀死进程的核心函数），当进程被 OOM 杀死时，eBPF 程序会在内核态捕获事件（PID / 进程名 / 内存信息），并通过 perf buffer 将事件推送到用户态，C++ 程序只需监听 perf buffer 即可实时接收 OOM 事件。
- Android & QNX &Linux Android 底层基于 Linux 内核，而 QNX并非基于 Linux，是独立的微内核实时操作系统。
- Android：在 Linux 内核之上构建了 ART、Framework 等专属层，属于 Linux 内核的定制衍生系统
- QNX：采用微内核架构，内核仅保留进程管理、内存管理等核心功能，驱动和应用以用户态进程运行，与 Linux 无内核层面的关联，是黑莓自研的 RTOS，广泛用于车载中控、自动驾驶等实时性要求高的车载场景
如何通信：
车载场景中 QNX 与 Android 的跨 OS 通信，核心基于Hypervisor 虚拟化隔离（主流方案）或硬件级物理连接
方案 1：共享内存（Shared Memory）
实现原理
- Hypervisor 划分一块物理内存并映射到 QNX 和 Android 的地址空间，双方均能读写；
- 配合自旋锁 / 信号量（由 Hypervisor 提供，如 QNX 的
SyncObjs、Android 的posix sem）做互斥同步，防止数据读写冲突； - 封装固定数据帧格式（定义帧头 / 数据长度 / 校验位 / 时间戳），双方按格式解析。
车载适配场景
- QNX（仪表）←→Android（IVI）：中控导航信息、多媒体状态、车辆状态（车速 / 油量）同步；
- QNX（ADAS / 环视）←→Android（IVI）：环视图像流、ADAS 报警信息、摄像头视频数据传输。
方案 2：跨 OS Binder（扩展方案）
核心特点
基于 Android 原生 Binder 机制扩展，适合 Android 为主控的跨 OS 通信，支持进程间通信的权限控制 / 数据序列化，延迟毫秒级。
实现原理
- 由 Hypervisor（如 QNX Hypervisor 2.0+）提供Binder 虚拟化驱动，将 Android 的 Binder 通信能力透传到 QNX；
- QNX 侧封装Binder 客户端 API，模拟 Android 的 ServiceManager/IBinder 机制；
- 双方通过 Binder 的
transact/onTransact实现跨 OS 的服务调用和数据传输。
车载适配场景
- Android（IVI）为主控，调用 QNX（仪表）的 UI 渲染服务、设备控制服务；
- 跨 OS 的应用层服务互通（如 Android 的语音服务给 QNX 仪表传语音播报数据）-
方案 3：硬件级直连（异构硬件方案）
核心特点
适用于QNX/Android 运行在不同 SoC/MCU的异构硬件架构，基于物理硬件通信，稳定性最高，延迟由硬件决定（串口毫秒级、以太网亚毫秒级、PCIe 微秒级）。
实现方式
- 以太网：双方通过车规级以太网 PHY 芯片直连，基于 TCP/UDP/DoIP（车载 IP 诊断）通信，是异构硬件的主流；
- PCIe：高速率（GB 级）、低延迟，适合跨 OS 的视频 / 图像大数据传输（如智驾 SoC 的 QNX 向 IVI SoC 的 Android 传感知数据）；
- 串口（UART/LIN） ：轻量、低功耗，适合小数据、低频次的指令通信（如车身 MCU 的 QNX 向 IVI 的 Android 传状态）；
- CAN/LIN 总线：车载最基础的跨 ECU 通信，QNX/Android 均通过 CAN 控制器接入总线，基于 CANoe/CANalyzer 解析总线数据
