【Android 系统开发】从掉帧卡顿到丝滑：高频硬件中断（IRQ）的 CPU 亲和性性能优化实战

0. 前言

在 Android 嵌入式与车载系统开发中，系统流畅度（UI 帧率）是衡量用户体验的核心指标。然而，很多时候界面卡顿、掉帧甚至触摸响应慢，根源并不在应用层或 SurfaceFlinger，而是在更底层的Linux 内核中断分配上。

本文将分享一个高频硬件中断（以 CAN 总线中断为例）抢占 CPU0 导致系统卡顿的排查与终极优化案例，并彻底解决系统休眠唤醒（Suspend/Resume）后中断亲和性被复位的隐形深坑。

1. 痛点现象：时隐时现的系统卡顿

在项目开发中，遇到了一个非常诡异的性能问题：

冷启动（刚开机）时： 系统运行极度丝滑，无论怎么进行高频硬件数据通信，UI 界面都没有任何掉帧。
休眠唤醒（Suspend -> Resume）后： 设备运行一段时间，界面开始出现明显的跟手延迟、掉帧甚至瞬间冻结。

2. 深入排查：谁动了我的 CPU0？

通过查看系统中断分布表 /proc/interrupts，我们发现了端倪。

步骤 1：查看高频中断的触发分布

通过 ADB 命令监控目标硬件（假设 IRQ 号为 53）的中断计数变化：

Bash

复制代码

adb shell "cat /proc/interrupts | head -1; cat /proc/interrupts | grep 53:"

异常发现： 在系统卡顿期间，该中断的计数在 CPU0 上疯狂飙升，而其他 CPU 核心（CPU1~CPU3）上的计数几乎为 0。

步骤 2：查看 CPU 亲和性（smp_affinity）

查看该中断当前的 CPU 绑定情况：

Bash

复制代码

adb shell cat /proc/irq/53/smp_affinity
# 输出：01

掩码 01（二进制 0001）： 代表该中断被绑定到了 CPU0 上。

为什么绑定到 CPU0 会导致卡顿？

在 Linux/Android 系统中，CPU0 是一个极度繁忙的核心 。Android 的 system_server、SurfaceFlinger 以及前台 APP 的 UI 主线程，默认和大部分系统软中断（SoftIRQs）都高度依赖 CPU0。

当硬件中断被绑定到 CPU0 且处于高频通信时，硬件中断（Hard IRQ）具有最高优先级。每当数据来临，CPU0 必须强行暂停当前的 UI 渲染或输入事件响应，转去执行中断处理函数。这种高频的主频剥夺与上下文切换，在宏观上就表现为界面掉帧和卡顿。

3. 临时策略：物理隔离（IRQ Isolation）

既然知道是抢占 CPU0 导致的，我们通过修改掩码，将该中断强行绑定到相对空闲的 CPU3 （掩码为 08，二进制 1000）：

Bash

复制代码

# 绑定到 CPU3
adb shell "su -c 'echo 08 > /proc/irq/53/smp_affinity'"
adb shell "echo 08 > /proc/irq/53/smp_affinity"
adb shell "echo 01 > /proc/irq/53/smp_affinity"

# 验证测试：让设备持续通信几分钟后再次查看
adb shell "cat /proc/interrupts | grep 53:"

结果： 此时 CPU3 的中断计数开始疯狂递增，而 CPU0 的计数停止增长。系统界面瞬间恢复丝滑，卡顿完全消失！

CPU 掩码常用对照表

目标 CPU	二进制	亲和性掩码 (Hex)	业务建议
CPU0	`0001`	`01`	默认值（UI 核心，高频中断必卡）
CPU1	`0010`	`02`	空闲核心
CPU2	`0100`	`04`	空闲核心
CPU3	`1000`	`08`	推荐（隔离高频中断，保护 UI）
全部CPU	`1111`	`0f`	轮询分发

4. 终极陷阱：冷启动正常，为何唤醒后丢失？

虽然在 init.rc 中配置了开机脚本自动写入 08，导致冷启动时表现正常 。但为什么休眠唤醒后又变回了 01？

原因分析

当 Android 设备进入深度休眠（Suspend to RAM）时，内核电源管理模块（PM Core）会对大部分外设及中断控制器（GIC）进行断电。

在设备被唤醒（Resume）的过程中，内核会重新初始化硬件和 GIC 寄存器。在此期间，内核会为该中断重新分发默认的 CPU 亲和性（通常是默认的 CPU0） ，从而无情地覆盖掉了我们开机时写入的 08。

单纯在 Java 层监听 SCREEN_ON 广播来重新写入，不仅有数百毫秒的延迟，而且在系统刚唤醒的早期阶段，高频中断就已经开始冲刷 CPU0 了。

5. 系统级解决方案（永久生效）

作为系统级开发，我们需要在更底层的 Native 侧或内核侧拦截唤醒事件，确保在中断线使能的第一时间完成绑定。

方案一：内核驱动层直接硬锁定（最干净彻底）

如果项目拥有内核源码修改权限，直接找到该硬件驱动（如 drivers/net/can/ 目录下的对应驱动），定位到其 struct dev_pm_ops 的 resume 回调函数。

在恢复硬件寄存器并准备使能中断时，强行注入亲和性绑定代码：

复制代码

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

static int my_hardware_driver_resume(struct device *dev)
{
    // ... 驱动原有的硬件唤醒与寄存器恢复代码 ...

    // 假设驱动私有结构体中保存了 irq 号：priv->irq
    // 强制在内核级将该 IRQ 绑定到 CPU3 (cpumask_of(3))
    irq_set_affinity(priv->irq, cpumask_of(3)); 
    
    dev_info(dev, "Driver Resumed: Forced IRQ %d affinity to CPU3 (08)\n", priv->irq);
    return 0;
}

优点： 毫秒级同步，在外设刚苏醒、还没来得及大量上报数据时，就已经在底层将其重定向到 CPU3，绝对不会对 CPU0 造成任何瞬间冲击。

方案二：Vendor 层的 Power HAL 动态拦截

如果无法修改内核（例如厂商只提供动态加载的 .ko 驱动），我们可以通过 Android 供应商的 Power HAL（C++ Native 守护进程）进行拦截。

系统休眠唤醒会穿透到 Power HAL 服务（如 android.hardware.power-service），在唤醒的特定 Hint 回调中，利用 C++ 动态获取 IRQ 并写入：

C++

复制代码

#include <fstream>
#include <string>
#include <regex>

void on_system_resume_callback() {
    // 实际项目中，IRQ 号可能会随内核编译而变动，建议通过读取 /proc/interrupts 动态检索
    std::string irq_num = "53"; 
    
    std::string path = "/proc/irq/" + irq_num + "/smp_affinity";
    std::ofstream affinity_file(path);
    if (affinity_file.is_open()) {
        affinity_file << "08"; // 强刷 CPU3 掩码
        affinity_file.close();
    }
}

注：此方案需要同步在 file_contexts 中为 Power HAL 进程配置允许写入 /proc/irq/ 的 SELinux 权限（sysfs 或 procfs 标签）。

6. 总结与建议

在嵌入式与车载 Android 系统的性能优化中，"IRQ 隔离" 是一把润物细无声的利器。当系统遇到不明原因的掉帧卡顿，尤其是与特定硬件数据通信强相关时，不妨去 /proc/interrupts 里看看是不是 CPU0 正在替全系统"负重前行"。

通过内核驱动 Resume 锁定 或者 Vendor 层 Power HAL 拦截，可以完美解决休眠唤醒后亲和性复位的顽疾，让高频硬件通信与流畅 UI 互不干扰，各司其职！