3. Android中断框架：Android特有的中断管理、wakeup interrupt、binder与中断的关系

Android 在标准 Linux 内核中断子系统之上，针对移动设备的功耗敏感、用户交互实时、多进程通信频繁等特性，构建了一套特有的中断管理框架。本章深入剖析 Android 独有的中断管理机制，包括 wakeup interrupt（唤醒中断）的设计原理、Binder 驱动与中断的间接关系，以及它们如何协同保障系统的响应性与功耗平衡。

3.1 Android 中断管理架构概览

Android 中断管理并非重写 Linux 中断子系统，而是在其基础上增加了三层核心扩展：

• Wakeup Source 框架：替代标准 Linux 的 wakeup count，提供更细粒度的唤醒源跟踪与超时管理。
• IRQ 亲和性与线程化策略：针对音频、显示、传感器等关键中断，强制绑定到特定 CPU 并启用 threaded IRQ。
• Binder 与中断的间接耦合：Binder 驱动本身不直接处理硬件中断，但通过高优先级工作队列与 RT 线程影响中断响应延迟。

下表对比了标准 Linux 与 Android 在中断管理关键维度的差异：

3.2 Wakeup Interrupt：唤醒中断机制

Wakeup interrupt 是 Android 深度睡眠（suspend-to-RAM）期间唯一能唤醒系统的中断源。其核心设计围绕 wakeup_source 结构体展开。

3.2.1 Wakeup Source 生命周期

1. 注册：驱动通过 wakeup_source_register() 向 PM core 注册一个 wakeup source，关联到特定 IRQ。
2. 激活：当设备进入 suspend 前，驱动调用 __pm_stay_awake() 阻止系统休眠。
3. 触发：硬件中断到达，即使系统已 suspend，IRQ 控制器（如 GIC）仍能接收并唤醒 CPU。
4. 释放：中断处理完成后，驱动调用 __pm_relax() 允许系统再次休眠。

3.2.2 唤醒中断处理流程

下图展示了从硬件中断触发到系统完全唤醒的完整路径：

3.2.3 唤醒中断驱动实现示例

以下代码展示了一个典型的外设驱动如何注册并使用 wakeup interrupt：

#include <linux/interrupt.h>
#include <linux/pm_wakeup.h>

struct my_device {
    struct device *dev;
    struct wakeup_source *ws;
    int irq;
};

static irqreturn_t my_irq_handler(int irq, void *data)
{
    struct my_device *mydev = data;

    /* 激活 wakeup source，阻止系统休眠 */
    __pm_stay_awake(mydev->ws);

    /* 处理硬件中断，读取 FIFO 等 */
    process_hardware_data();

    /* 唤醒等待队列或上报数据 */
    wake_up_interruptible(&mydev->wq);

    /* 释放 wakeup source，允许系统休眠 */
    __pm_relax(mydev->ws);

    return IRQ_HANDLED;
}

static int my_probe(struct platform_device *pdev)
{
    struct my_device *mydev;
    int ret;

    mydev = devm_kzalloc(&pdev->dev, sizeof(*mydev), GFP_KERNEL);
    mydev->dev = &pdev->dev;

    /* 注册 wakeup source */
    mydev->ws = wakeup_source_register(mydev->dev, "my_device_wakeup");
    if (!mydev->ws)
        return -ENOMEM;

    /* 申请 threaded IRQ，强制使用 IRQF_NO_SUSPEND 标志 */
    ret = devm_request_threaded_irq(mydev->dev, mydev->irq, NULL,
                                    my_irq_handler,
                                    IRQF_TRIGGER_RISING | IRQF_NO_SUSPEND,
                                    "my_device", mydev);
    if (ret) {
        wakeup_source_unregister(mydev->ws);
        return ret;
    }

    /* 使能设备唤醒能力 */
    device_init_wakeup(mydev->dev, true);

    return 0;
}

3.3 Binder 与中断的间接关系

Binder 驱动是 Android 进程间通信（IPC）的核心，它本身不直接处理硬件中断，但通过以下机制深刻影响中断响应行为：

• 高优先级工作队列：Binder 使用 high-priority workqueue 处理事务，这些工作项可能抢占中断下半部（softirq）的执行。
• RT 线程调度：Binder 线程池中的线程通常运行在实时优先级（RT），当它们被中断处理程序唤醒时，会立即抢占普通进程，影响中断到用户态的传递延迟。
• epoll 驱动模型：用户态服务（如 SurfaceFlinger）通过 epoll 等待 Binder 文件描述符，中断处理完成后通过 Binder 通知用户态，形成“中断 → Binder → epoll → 用户态处理”的完整链路。

3.3.1 Binder 中断传递路径

下图展示了从硬件中断到用户态 Binder 服务接收通知的完整路径：

3.3.2 中断响应延迟的 Binder 影响因素

3.4 Android 中断调试与诊断

Android 提供了丰富的调试接口用于分析中断行为：

• /proc/interrupts：查看每个 CPU 上各中断的触发次数。
• /sys/kernel/debug/wakeup_sources：查看所有 wakeup source 的活跃状态和超时信息。
• /sys/power/wake_lock / wake_unlock：手动持有或释放唤醒锁，用于隔离测试。
• systrace / atrace：通过 atrace irq binder 捕获中断与 Binder 的时序关系。

3.5 本章小结

Android 中断框架在标准 Linux 基础上，通过 wakeup source 实现了精确的唤醒管理，通过强制 threaded IRQ 和 CPU 亲和性保障了关键中断的实时性。Binder 驱动虽然不直接处理中断，但其高优先级工作队列和 RT 线程池深刻影响了中断到用户态的传递延迟。理解这三者的协同关系，是编写高质量 Android 设备驱动的关键前提。