2. Framework层调度框架解析：SystemServer线程结构、Binder线程池优先级、Handler消息队列

2.1 原理：Android 系统进程调度的三层枢纽

Android 系统服务的核心进程 SystemServer 承载着 WindowManagerService、ActivityManagerService、PackageManagerService 等几十个关键服务。其内部调度框架由三层组成：

• 线程结构 — SystemServer 启动后衍生出数百个线程，包括主线程（ActivityThread）、Binder 线程、Handler 线程、Watchdog 线程等。线程的创建与绑定决定了任务的执行上下文。
• Binder 线程池优先级 — 每个 Binder 线程都有固定的 setThreadPriority() 调用点，优先级配置直接影响跨进程请求的响应延迟。默认池大小与优先级组策略是调优的重点。
• Handler 消息队列 — 线程内部通过 Looper + MessageQueue 驱动消息循环。消息的 when 时间与 MessageQueue.next() 的阻塞唤醒机制决定了单一线程内消息的响应次序。

这三层共同构成 SystemServer 响应优先级的骨架：线程优先级决定谁先获得 CPU，Binder 优先级决定跨进程请求的抢断能力，Handler 队列决定同线程内消息的先后顺序。

2.2 实现流程：SystemServer 线程初始化与优先级的设定

在 SystemServer.main() 启动过程中，优先级初始化按以下顺序执行：

1. 启动主线程 Looper — Looper.prepareMainLooper()，此时线程优先级继承自 system_server 进程的默认值（nice 0）。
2. 初始化 Binder 线程池 — ProcessState::self()->setThreadPoolMaxThreadCount(31)，并在 IPCThreadState 中调用 setThreadPriority() 设置每个 Binder 线程的优先级。
3. 启动系统服务线程 — 例如 DisplayThread、AnimationThread、UiThread 等，每个线程在 run() 开始前通过 android.os.Process.setThreadPriority() 设置固定优先级。
4. 注册 Handler 并处理消息 — 每个服务创建自己的 Handler，关联对应的 Looper，通过 sendMessage() 或 post() 将任务加入消息队列。

2.3 代码与配置：核心 API 与阈值设定

ProcessState::self()->setThreadPoolMaxThreadCount(31); // frameworks/native/libs/binder/ProcessState.cpp

IPCThreadState::self()->setThreadPriority(threadPriority);
// frameworks/native/libs/binder/IPCThreadState.cpp

private void initThread() {
    android.os.Process.setThreadPriority(
        android.os.Process.THREAD_PRIORITY_DISPLAY);
    Looper.prepare();
    mHandler = new Handler(Looper.myLooper());
    Looper.loop();
}

// 触发屏障
MessageQueue mq = Looper.myLooper().getQueue();
mq.postSyncBarrier();
// 发送异步消息
Message msg = Message.obtain(handler, what);
msg.setAsynchronous(true);
handler.sendMessage(msg);

系统服务优先级分组定义在 android.os.Process.java：

// 关键系统服务常用优先级
public static final int THREAD_PRIORITY_DEFAULT = 0;
public static final int THREAD_PRIORITY_DISPLAY = -4;   // 显示相关
public static final int THREAD_PRIORITY_URGENT_DISPLAY = -8; // 紧急显示
public static final int THREAD_PRIORITY_FOREGROUND = -2;
public static final int THREAD_PRIORITY_BACKGROUND = 10;

2.4 调试手段：确认线程与优先级状态

• 查看 SystemServer 所有线程：

  adb shell ps -T -p $(pidof system_server)
  # 输出：NAME         PID   TID  PPID  VSIZE  RSS   WCHAN     PC  STATE
  #      system_server  1234  1235  1    ...   ...   SyS_epoll  ... S
  #      system_server  1234  1240  1    ...   ...   binder_io  ... S

• 查看线程优先级 (nice)：

  adb shell cat /proc/$(pidof system_server)/task/*/stat | awk '{print $1, $19}'
  # 输出示例：cpu_boost_t  1235  0  → nice 0
  #           Binder:328_4 1240 -4 → nice -4

• 动态捕获 Binder 调用延迟：

  adb shell dumpsys binder --stats
  # 查看各服务历史延迟数据
  adb shell dumpsys binder --transaction  // 实时跟踪事务

• Handler 消息队列延迟诊断：

  adb shell dumpsys activity processes
  # 查找 MainThread 的 Handler 消息排队情况
  adb shell dumpsys window display | grep -i "anim"
  # 查看动画线程消息处理延迟

2.5 部署场景与配置实践

在实际产品中，按照服务重要性设置不同的优先级梯度：

2.6 常见错误与性能/稳定性优化

稳定性优化清单

• Binder 线程池大小设定上限：超过 32 个 Binder 线程会导致大量上下文切换，建议 ≤ 31 (在 8 核设备上)。
• 避免优先级倒置：低优先级 Binder 线程持有锁被高优先级线程等待时，使用优先级继承协议（Linux RT 自带）或设计无锁数据结构。
• Handler 消息去重：对于同类型定时任务，使用 sendMessageAtFrontOfQueue() 时要格外小心，它会破坏消息顺序。
• 使用异步消息屏障：在 DispatchingThread 中植入屏障，确保关键触摸事件不被后台动画消息阻塞。

性能压测命令

# 施加 Binder 负载
adb shell dumpsys activity service com.android.systemui/.SystemBars --binder-load 100
# 监控 SystemServer 线程调度延迟
adb shell echo "1" > /proc/sys/kernel/sched_schedstats
adb shell cat /proc/$(pidof system_server)/schedstat
# 输出：1234567890 987654321 1000   # run_delay_ms / run_time_ms / 调度次数