📚 课程目录第4章优先级分类与业务映射

4. 优先级分类与业务映射：实时请求、普通请求、后台请求的优先级等级划分与绑定策略

AOSP Binder 线程池默认使用共享线程池处理所有传入的 IPC 请求。在多媒体播放、传感器数据流、后台同步等混合负载场景下，缺乏优先级区分的线程池会导致 头阻塞（Head-of-Line blocking）：一个低优先级的后台同步事务占用线程执行长达几十毫秒的 I/O 操作，迫使等待触控事件的实时事务排队等待。本章定义三级优先级模型，并给出从业务请求到 Binder 线程的准确绑定策略。

4.1 优先级等级定义

根据延迟敏感度和 CPU 突发的特性，将 Binder 事务划分为三个等级。每个等级对应独立的调度策略、Nice 值范围和线程池预留资源。

类别	Nice 值范围	调度策略	线程池预留	典型场景
实时 (Real-time)	-20 ~ -10	`SCHED_FIFO` / `SCHED_RR`	4	触控事件、音频回调、传感器流
普通 (Normal)	-5 ~ +5	`SCHED_OTHER` (CFS)	8（默认池）	应用启动、Activity 生命周期、数据加载
后台 (Background)	+10 ~ +19	`SCHED_IDLE` / `SCHED_BATCH`	4	日志上传、预取、垃圾回收

内核视角优先级转换： Binder 驱动层通过 task_struct->prio 和 task_struct->policy 调度线程。设置 Nice = -15 加上 SCHED_FIFO 会赋予线程 RT priority 10，使其能够抢占所有 CFS 线程。这是实现微秒级响应延迟的关键，但也带来稳定性风险。

4.2 业务映射策略

将业务层的请求映射到 Binder 优先级需要三个步骤：

接口级元数据： 在 AIDL 接口定义中使用 @BinderPriority 注解声明该服务的默认优先级。
事务级覆盖： 客户端可以在调用 transact() 时通过 flags 参数指定本次调用的独立优先级，覆盖接口默认值。
线程池亲和性： 接收端 IPCThreadState 根据事务优先级将请求分发到对应的线程池队列（High / Normal / Background）。

以下 SVG 展示了从业务层到 Binder 线程池的完整映射架构：

4.3 优先级绑定流程：AIDL 代码示例

以下示例展示如何通过 @BinderPriority 元数据将业务服务绑定到指定的优先级线程池。

// IHighPriorityCallback.aidl
@BinderPriority(level = BinderPriority.REALTIME)
interface IHighPriorityCallback {
    /** 传感器事件必须由实时池中的高优先级线程处理 */
    void onSensorEvent(in SensorEvent event);
}

// IBackgroundSync.aidl
@BinderPriority(level = BinderPriority.BACKGROUND)
interface IBackgroundSync {
    /** 批量同步请求可以排队到后台池 */
    void syncRecords(in String batchId);
}

AOSP 的 Binder.java 解析 @BinderPriority 注解，并在创建 BinderProxy 时将等级写入 mPriority 字段。当调用 transact() 时，优先级信息被编码到 flat_binder_object 的 flags 域中，Binder 驱动据此决定唤醒哪个等待队列。

4.4 调试与验证：确认线程池路由

开发阶段需要验证实时请求是否确实被调度到高优先级池。使用以下 Bash 脚本打印所有 Binder 线程的调度策略和优先级。

#!/system/bin/sh
# binder_prio_check.sh
# 用法: sh binder_prio_check.sh <进程PID>

TARGET_PID=$1
echo "=== Binder Thread Priority Report for PID: $TARGET_PID ==="
for tid in $(ls /proc/$TARGET_PID/task/); do
  COMM=$(cat /proc/$TARGET_PID/task/$tid/comm 2>/dev/null)
  # 只过滤 Binder 线程
  case "$COMM" in
    *Binder*)
      STAT=$(cat /proc/$TARGET_PID/task/$tid/stat 2>/dev/null)
      PRIO=$(echo $STAT | awk '{print $18}')
      NICE=$(echo $STAT | awk '{print $19}')
      POLICY=$(cat /proc/$TARGET_PID/task/$tid/sched 2>/dev/null | grep "policy" | awk '{print $3}')
      echo "TID: $tid Name: $COMM Priority: $PRIO Nice: $NICE Policy: $POLICY"
      ;;
  esac
done

预期输出：实时池线程应显示 Priority: 85 和 Policy: SCHED_FIFO (1)；池应显示 Priority: 120 和 Policy: SCHED_OTHER (0)。

4.5 常见错误与稳定性优化

严重警告：滥用实时优先级导致的系统锁死风险

将 Binder 线程设置为 SCHED_FIFO 且优先级为 10-20 会使其运行在高于标准内核工作队列的优先级上。如果该线程在持有一个关键锁（如 mmap_lock）时发生错误并陷入循环，则整个系统都会冻结。Android CDD 严格禁止第三方应用使用实时优先级。只有核心系统服务（audioserver、cameraserver、inputflinger）才允许此配置。

性能调优建议：动态回退与优先级继承

当一个高优先级任务（如触控）通过 Binder 调用一个低优先级服务（如磁盘 I/O）时，AOSP 会自动实施 优先级继承协议 (PIP)：Binder 驱动临时将目标线程的优先级提升到调用者的水平。但是，如果目标线程使用的是自定义线程池而不是 Binder 的默认池，则继承链可能会中断。始终使用 IPCThreadState 提供的标准 Binder 线程池来确保 PIP 正常工作。

在下一级调优中，我们将深入 Binder 驱动的 ioctl 层面，展示如何通过修改 kernel/sched/core.c 中的 cgroup 关联来隔离实时线程池，防止其与内核关键任务争抢 CPU。