鸿蒙操作系统（HarmonyOS）是华为面向全场景智能终端自主研发的分布式操作系统，其调度体系的设计需要同时应对多核异构硬件、能效约束、用户体验流畅性与跨设备任务协同等多重挑战。

与 FreeRTOS 这类“把一件事做到极致”的实时内核不同，鸿蒙的调度是一个从内核态到用户态、从单设备到多设备协同的分层调度生态。它既要保证 UI 帧率的流畅，又要控制后台功耗，还要支持任务在手机、平板、PC 之间无缝迁移——这些目标之间存在天然矛盾，调度系统正是这些矛盾的“仲裁者”。

本文从鸿蒙的多内核分层架构出发，逐一拆解其在 IoT 端（LiteOS-A）与手机端（Linux 定制内核）的调度机制，重点分析 CFS 基础调度、能量感知调度（EAS）、QoS 感知调度、帧感知调度（FAS）、FFRT 用户态并发运行时以及分布式任务调度（DSched）六大核心模块。

引言

研究背景

2019 年 8 月，华为在全球开发者大会（HDC2019）上正式发布 HarmonyOS，将其定位为“面向未来、面向全场景的分布式操作系统”。鸿蒙的出现背景复杂：一方面是华为受到芯片供应限制后的战略自主性需求；另一方面，也是因为现有操作系统（Android/iOS）的单设备架构在万物互联时代已表现出明显局限。

在调度层面，鸿蒙面临的设计挑战远比传统操作系统复杂：

• 异构多核：现代旗舰 SoC（如麒麟 9000）集成了超大核、大核、小核、GPU、NPU 等多种计算单元，各单元的性能与功耗差异悬殊；
• 多维优化目标：需要同时优化 UI 帧率（用户体验）、应用启动时延（响应性）、后台功耗（续航）三个存在内在矛盾的目标；
• 分布式协同：任务可能需要在手机、平板、PC、智慧屏等不同设备间迁移执行，传统单机调度框架无法胜任。

鸿蒙发展历程

从版本演进可以清晰地看到鸿蒙调度能力的两条主线：单设备内的“感知-调度”深度优化（EAS、FAS），与跨设备的调度抽象（DSched、超级终端）。

鸿蒙多内核架构与调度分层

分层架构总览

鸿蒙采用弹性部署的多内核设计，根据目标设备的硬件能力选择合适的内核，但对外暴露统一的系统服务接口：

flowchart TB
    subgraph AppLayer [应用层]
        App["ArkUI / ArkTS"]
    end

    subgraph ServiceLayer [系统服务框架]
        Service["Ability、分布式软总线等"]
    end

    subgraph SchedLayer [调度服务层]
        direction LR
        FFRT["FFRT 用户态调度"]
        QoS["QoS 管理"]
        FAS["帧感知调度（FAS）"]
    end

    subgraph KernelLayer [内核层]
        direction LR
        K_M["LiteOS-M 内核<br/>(MCU, <512KB RAM)<br/>简单优先级抢占调度"]
        K_A["LiteOS-A 内核<br/>(IoT, 数MB RAM)<br/>优先级+时间片调度"]
        K_L["Linux 定制内核<br/>(手机/平板/PC, GB级RAM)<br/>CFS+EAS+实时调度类"]
    end

    subgraph HardwareLayer [硬件层]
        HDF["硬件驱动框架（HDF）/ HAL"]
    end

    AppLayer --> ServiceLayer
    ServiceLayer --> SchedLayer
    SchedLayer --> KernelLayer
    KernelLayer --> HardwareLayer

图 1：鸿蒙分层调度架构总览图

三类内核的调度定位

LiteOS-A 调度机制（IoT 场景）

优先级模型

LiteOS-A 支持 32 个任务优先级（0 为最高优先级，31 为最低），采用与 FreeRTOS 类似的固定优先级抢占式调度模型。就绪队列同样基于优先级位图 + 链表数组实现 $O(1)$ 调度复杂度。

/* LiteOS-A 任务创建 API */
TSK_INIT_PARAM_S stTaskInitParam;
stTaskInitParam.pfnTaskEntry  = (TSK_ENTRY_FUNC)SensorTask;
stTaskInitParam.uwStackSize   = 4096;                   /* 栈大小：4KB */
stTaskInitParam.pcName        = "SensorTask";
stTaskInitParam.usTaskPrio    = LOS_TASK_PRIORITY_HIGH; /* 优先级 4 */
stTaskInitParam.uwResved      = LOS_TASK_STATUS_DETACHED;

UINT32 uwRet = LOS_TaskCreate(&g_uwTaskID, &stTaskInitParam);

系统调度配置参数

同为“优先级抢占 + 时间片”模型，两个内核的差异主要体现在面向场景的取舍上：LiteOS-A 将心跳从 1ms 放慢到 10ms，直接降低了 IoT 设备的空闲功耗；而 FreeRTOS 保留 1ms 心跳以满足工业场景的细粒度时序需求。

IPC 与调度联动

LiteOS-A 提供事件（Event）、消息队列（Queue）、信号量（Semaphore）、互斥量（Mutex）等 IPC 机制，均与调度器深度集成：当 IPC 操作导致高优先级任务就绪时，调度器立即发起抢占。

/* 消息队列触发调度示例 */

/* 任务 A：发送消息（可能触发高优先级任务 B 的抢占） */
LOS_QueueWriteCopy(g_queueID, &msg, sizeof(msg), LOS_NO_WAIT);

/* 任务 B（高优先级）：等待消息 */
LOS_QueueReadCopy(g_queueID, &rxMsg, &bufLen, LOS_WAIT_FOREVER);
/* ↑ 消息到达后立即被调度运行，抢占低优先级任务 A */

手机端核心调度机制

Linux CFS：调度基础层

鸿蒙手机端基于 Linux 内核（深度定制），其调度体系以完全公平调度器（Completely Fair Scheduler, CFS） 为基础。CFS 由 Ingo Molnár 于 2007 年引入 Linux 2.6.23。

CFS 核心原理：虚拟运行时间

CFS 的核心抽象是虚拟运行时间（vruntime）：每个任务维护一个 vruntime 值，表示该任务已获得的“加权 CPU 使用时间”。调度器始终选择 vruntime 最小的任务运行，从而保证所有任务获得公平的 CPU 份额。

vruntime 的增长公式为：

其中：

• $\Delta t_{\text{exec}}$：任务的实际运行时间增量；
• $W_0$：nice 值为 0 的基准权重（= 1024）；
• $W_i$：任务 $i$ 的实际权重，由 nice 值决定。

这张表的本质是“nice 值每差 1，CPU 份额约变化 1.25 倍”的指数关系（1024 / 1.25 ≈ 819，逐级递推恰好得到上表的权重序列）。

就绪队列数据结构：红黑树

CFS 使用红黑树（Red-Black Tree） 以 vruntime 为键管理就绪任务，树的最左节点（vruntime 最小）即为下一个应运行的任务，查找时间复杂度为 $O(log n)$：

/* Linux CFS 就绪队列（简化） */
struct cfs_rq {
    struct rb_root_cached   tasks_timeline; /* 红黑树，键为 vruntime */
    struct sched_entity    *curr;           /* 当前运行实体 */
    u64                     min_vruntime;   /* 最小 vruntime（新任务的起始值） */
    unsigned long           nr_running;     /* 就绪任务数 */
};

/* 选择下一任务：取最左节点，O(log n) */
static struct sched_entity *pick_next_entity(struct cfs_rq *cfs_rq) {
    struct rb_node *left = rb_first_cached(&cfs_rq->tasks_timeline);
    return rb_entry(left, struct sched_entity, run_node);
}

与 FreeRTOS 的 $O(1)$ 位图方案相比，CFS 面对的是“数百~数千任务、需要动态公平”的场景，红黑树在任务数量大时仍保持对数级开销，而公平性也得到了精确保证——这正是“场景决定数据结构”的典型例证。

Linux 调度类层次

Linux 内核（含鸿蒙定制版）通过调度类（Scheduling Class） 体系支持多种调度策略，调度类之间严格按优先级顺序执行（高优先级调度类完全饿死低优先级类）：

flowchart TD
    Stop["Stop Class<br/>专用于每CPU停止任务（最高，不可抢占）"]
    DL["DL Class<br/>SCHED_DEADLINE（EDF 实现，截止时间调度）"]
    RT["RT Class<br/>SCHED_FIFO / SCHED_RR（硬实时，优先级 0–99）"]
    CFS["CFS Class<br/>SCHED_NORMAL / SCHED_BATCH / SCHED_IDLE（普通任务）"]
    Idle["Idle Class<br/>空闲任务（最低）"]

    Stop --> DL --> RT --> CFS --> Idle

图 2：Linux 内核调度类优先级层次图

鸿蒙将不同 QoS 等级的任务映射到不同调度类（详见下文 QoS 感知调度一节）——这一映射是理解鸿蒙应用侧调度策略的关键入口。

能量感知调度（EAS）

EAS（Energy-Aware Scheduling）是 Linux 内核自 v5.0 起引入的节能调度扩展，通过能量模型（Energy Model, EM） 预测任务放置在不同 CPU 上的能耗，选择能效最优的方案。鸿蒙在 EAS 基础上进行了针对麒麟芯片的深度定制。

麒麟 SoC 大小核架构

以麒麟 9000S（Mate 60 Pro 搭载）为例，其 CPU 集群架构如下：

EAS 任务放置决策

EAS 的核心决策函数是能耗差分计算。对于需要放置的任务 $\tau$，EAS 枚举所有候选 CPU，选择满足性能约束前提下能耗增量 $\Delta E$ 最小的目标：

其中：

$E(c, u)$ 由能量模型给出，通过测量不同频率点的功耗预先建模：

/* Linux EAS 能量模型结构（简化） */
struct em_perf_domain {
    struct em_perf_state *table;          /* 各频率点的能耗表 */
    int                   nr_perf_states; /* 频率点数量 */
};

struct em_perf_state {
    unsigned long frequency;              /* Hz */
    unsigned long power;                  /* mW */
    unsigned long cost;                   /* power/frequency，能效指标 */
};

麒麟 9000S 各集群能耗模型参考数据（华为内部数据推算）：

EAS 任务迁移策略（鸿蒙扩展）： 任务负载利用率（$util \in [0, 1024]$）的决策规则为：

• $util < 200$：优先放置小核，低频运行；
• $200 \le util < 600$：放置大核，中频运行；
• $util \ge 600$：允许迁移至超大核，高频运行；
• 突发性任务（短时 $util > 800$）：触发 Boost，暂时提升频率上限。

这组规则的精髓在于“能效优先，性能兜底”：绝大多数交互场景下任务在小核完成，只有重负载任务才被允许“动用”大核与超大核。

DVFS 调频联动

EAS 与 CPUFreq（DVFS 动态调频子系统） 联动，通过 schedutil 调速器根据当前 CPU 利用率实时调整频率：

鸿蒙将默认 margin 从 Linux 标准的 25% 调整为场景自适应（前台应用 margin 约 20%，后台任务约 5%），在响应性与节能间动态平衡。

QoS 感知调度

鸿蒙引入了五级 QoS（Quality of Service）分类体系，对应用中不同重要程度的任务进行差异化调度管理。

QoS 等级定义

注意最高等级的 QoS 并非简单地再调低 nice 值，而是直接切换到实时调度类 SCHED_RR——UI 渲染与触摸响应任务本质上属于“交互实时任务”，用实时优先级保证其确定性，是鸿蒙流畅性体验的调度层根基。

QoS API 使用

#include "qos.h"

// 为当前线程设置 QoS 等级
int result = OHOS::QOS::SetThreadQos(
    OHOS::QOS::QosLevel::QOS_USER_INTERACTIVE);

QoS 与 CPU 亲和性联动

鸿蒙调度器将 QoS 等级与 CPU 集群绑定策略结合，形成完整的资源分配策略：

帧感知调度（Frame-Aware Scheduling, FAS）

帧感知调度是鸿蒙为保障屏幕渲染流畅性（60/90/120/144Hz）而专门设计的调度机制，于 HarmonyOS 3.0 正式引入，4.0 版本进一步优化。

帧渲染的时间约束

以 120Hz 刷新率为例，每帧的时间预算为：

渲染管线各阶段的时间分配如下：

flowchart LR
    A["应用逻辑<br/>~1.5ms"] --> B["布局测量<br/>~1.5ms"] --> C["绘制<br/>~2.0ms"] --> D["合成<br/>~2.0ms"] --> E["VSync同步<br/>~1.33ms"]

图 3：120Hz 刷新率下单帧渲染管线时间分配图

若任何阶段超时，该帧将被丢弃（Jank），用户感知到卡顿。

FAS 工作原理

FAS 通过内核-用户态协同机制感知帧边界并动态调整调度行为：

flowchart TD
    S1["步骤一：帧边界注册<br/>(渲染进程 → 系统调用 → 内核记录 TID + 帧周期)"]

    S2{"步骤二：Vsync 触发帧开始"}
    S2_1["提升渲染线程 QoS 至 User-Interactive"]
    S2_2["设置 CPU 频率 BOOST 标志"]
    S2_3["优先在大核/超大核调度渲染线程"]

    S3{"步骤三：帧进度跟踪"}
    S3_1["正常调度"]
    S3_2["触发紧急提频 (Emergency Boost)"]
    S3_3["最高优先级，强制抢占所有非实时任务"]

    S4{"步骤四：帧完成信号"}
    S4_1["渲染线程 QoS 恢复正常"]
    S4_2["CPU 频率 BOOST 撤销，进入节能状态"]

    S1 --> S2
    S2 --> S2_1 & S2_2 & S2_3
    S2_1 & S2_2 & S2_3 --> S3

    S3 -- "T_remaining > 3ms" --> S3_1
    S3 -- "1ms < T_remaining < 3ms" --> S3_2
    S3 -- "T_remaining < 1ms" --> S3_3

    S3_1 & S3_2 & S3_3 --> S4
    S4 --> S4_1 & S4_2

图 4：FAS 帧感知调度工作原理图

关键内核接口（鸿蒙扩展的 sched API）：

/* 内核侧：注册帧边界（简化） */
void harmony_fas_register_frame_producer(pid_t tid, int refresh_rate_hz) {
    struct fas_info *fi = get_fas_info(tid);
    fi->frame_deadline_ns = NSEC_PER_SEC / refresh_rate_hz;
    fi->is_frame_producer  = true;
}

/* Vsync 信号处理：提升帧渲染线程优先级 */
void harmony_fas_on_vsync(void) {
    struct fas_info *fi;
    list_for_each_entry(fi, &fas_frame_producers, list) {
        /* 临时提升至实时调度类 */
        sched_set_fifo_low(fi->task);
        fi->frame_start_time = ktime_get_ns();
    }
}

FAS 的思想可以概括为“把帧当作实时系统的截止时间任务”：每一帧就是一个周期为 8.33ms（120Hz）的软实时任务，Vsync 是它的释放时刻，渲染完成是它的截止时间。调度器围绕这个截止时间动态调节资源，把“流畅”从玄学变成可管理的时序指标。

FAS 性能数据

根据华为 HDC 2023 技术分享及第三方测评数据：

FFRT：用户态并发运行时调度

传统线程模型的痛点

在传统多线程编程模型中，开发者需要手动管理线程创建、同步与销毁，存在以下问题：

1. 线程数量爆炸：复杂应用往往创建数百个线程，上下文切换开销巨大（每次约 5~20 μs）；
2. 串行化过度：为保证共享数据安全，大量使用锁，导致并行度严重不足；
3. 负载不均衡：固定线程池难以适应运行时负载动态变化；
4. 优先级反转：线程间依赖复杂，优先级继承机制难以覆盖所有场景。

FFRT 设计原理

FFRT（Function Flow Runtime Technology） 是鸿蒙 3.0 引入、4.0 正式大规模推广的用户态并发调度框架。其核心思想是：将任务间的数据依赖关系显式声明，由运行时自动构建 DAG（有向无环图）并调度并行执行。

FFRT 编程模型

#include "ffrt.h"

void image_processing_pipeline() {
    int raw = 0, denoised = 0, enhanced = 0, final = 0;

    // 声明任务依赖：输入依赖 → 输出依赖
    // FFRT 自动分析并行性，无依赖的任务并行执行

    ffrt::submit(
        [&] { raw = capture_raw_image(); },         // 任务A：采集
        {},          /* 输入依赖（无）*/
        {&raw}       /* 输出依赖（写 raw）*/
    );

    ffrt::submit(
        [&] { denoised = denoise(raw); },           // 任务B：降噪（依赖A）
        {&raw},      /* 需要 raw 就绪 */
        {&denoised}
    );

    ffrt::submit(
        [&] { enhanced = ai_enhance(raw); },        // 任务C：AI增强（依赖A，与B并行）
        {&raw},
        {&enhanced}
    );

    ffrt::submit(
        [&] { final = merge(denoised, enhanced); }, // 任务D：合并（依赖B和C）
        {&denoised, &enhanced},
        {&final}
    );

    ffrt::wait({&final}); // 等待最终结果
}

FFRT 根据上述依赖声明自动构建 DAG：

flowchart TD
    A["任务A: 采集"] --> B["任务B: 降噪"]
    A --> C["任务C: AI增强"]
    B --> D["任务D: 合并"]
    C --> D

    classDef parallel fill:#FF408040,stroke:#FF4080,color:#e7fffa;
    class B,C parallel

图 5：FFRT 任务依赖 DAG 构建图（B、C 并行执行）

FFRT 运行时调度策略

FFRT 运行时采用工作窃取（Work Stealing）+ QoS 感知的调度策略：

• 工作线程数：严格等于 CPU 核心数（与硬件并行度匹配，避免过度创建带来的上下文切换开销）。
• 工作窃取（Work Stealing）：每个工作线程维护本地的双端队列（deque），本线程优先从头部取任务执行；当线程空闲时，会主动从其他繁忙线程的队列尾部“窃取”任务。
• QoS 感知分配：高优先级任务优先进入大核队列，后台任务则进入小核队列。

flowchart LR
    TaskHigh[高 QoS 任务<br/>User-Interactive]
    TaskLow[低 QoS 任务<br/>Background]

    subgraph CoreBig [大核调度域]
        direction TB
        WorkerB((大核工作线程))
        DequeB[(本地 Deque)]
        WorkerB -->|1. 优先取头部| DequeB
    end

    subgraph CoreLittle [小核调度域]
        direction TB
        WorkerL((小核工作线程))
        DequeL[(本地 Deque)]
        WorkerL -->|1. 优先取头部| DequeL
    end

    TaskHigh -->|优先分配| DequeB
    TaskLow -->|优先分配| DequeL

    WorkerB -.->|2. 空闲时窃取尾部| DequeL
    WorkerL -.->|2. 空闲时窃取尾部| DequeB

图 6：FFRT 运行时工作窃取与 QoS 调度机制图

FFRT 性能数据

华为官方测试（对比传统 ThreadPool 实现）：

线程数从 156 降至 12 的显著减少，大幅降低了上下文切换开销和内存占用（每个线程栈默认 1~8 MB）。

分布式任务调度（DSched）

分布式软总线基础

鸿蒙的分布式能力构建于分布式软总线（Distributed Soft Bus） 之上。软总线是一种将 WiFi、蓝牙、有线以太网等物理通信信道抽象统一的中间件层，向上层提供设备发现、拓扑管理、高速传输三大基础服务。

软总线通信性能（华为实验室数据）：

分布式调度框架（DSched）架构

DSched（Distributed Scheduler） 是鸿蒙跨设备任务调度的核心框架，支持三类分布式任务操作：

flowchart TD
    subgraph AppLayer [应用层调用（ArkTS）]
        API["startAbility() / connectAbility() / migrateAbility()"]
    end

    subgraph DSchedLayer [分布式调度服务（DSched）]
        direction LR
        RS["远程启动<br/>(RemoteStart)"]
        Mig["Ability迁移<br/>(Migration)"]
        Col["协同调用<br/>(Collaborate)"]
    end

    subgraph BusLayer [分布式软总线（传输层）]
        Bus["设备发现、拓扑管理、高速传输"]
    end

    subgraph DeviceLayer [跨设备协同]
        direction LR
        DevA["设备 A（手机）"] <--> DevB["设备 B（平板）"]
    end

    AppLayer --> DSchedLayer
    DSchedLayer --> BusLayer
    BusLayer <--> DeviceLayer

图 7：DSched 分布式任务调度架构图

Ability 迁移（Migration）

迁移允许将正在运行的应用组件连同其完整状态从一台设备转移至另一台设备执行，用户无感知切换：

// ArkTS：发起 Ability 迁移（手机 → 平板）
import AbilityConstant from '@ohos.app.ability.AbilityConstant';

// 迁移前：保存当前状态
onContinue(wantParam: Record<string, Object>): AbilityConstant.OnContinueResult {
    wantParam["scroll_position"]   = this.currentScrollY;
    wantParam["playback_progress"] = this.videoCurrentMs;
    return AbilityConstant.OnContinueResult.AGREE; // 同意迁移
}

// 目标设备上：恢复状态
onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    if (launchParam.launchReason === AbilityConstant.LaunchReason.CONTINUATION) {
        this.currentScrollY  = want.parameters["scroll_position"] as number;
        this.videoCurrentMs  = want.parameters["playback_progress"] as number;
    }
}

DSched 调度决策模型

当应用发起跨设备操作时，DSched 需要在多台候选设备中选择最优执行设备。调度决策综合以下因素：

从调度理论的角度看，这已经超出了传统操作系统的范畴——候选集合从“本机 CPU 核心”变成了“多台异构设备”，优化目标也从时间维度扩展到了“性能-网络-能耗-偏好”的多维空间。

超级终端任务流水线

鸿蒙“超级终端”场景支持将复杂任务拆解为子任务流，在多设备间形成处理流水线，充分利用各设备的异构计算资源：

flowchart LR
    subgraph DevA [设备A：手机]
        A["视频采集<br/>(30fps)"]
    end

    subgraph DevB [设备B：平板]
        B["AI超分辨率推理<br/>(NPU 30ms/帧)"]
    end

    subgraph DevC [设备C：PC]
        C["视频编码存储<br/>(H.265编码)"]
    end

    A -- 软总线 --> B
    B -- 软总线 --> C

图 8：跨设备超级终端任务流水线协同图

流水线性能分析：

• 流水线吞吐 = min(1/30fps, 1/30ms) ≈ 30ms/帧（30fps）；
• 单设备串行 = 采集 + 推理 + 编码 ≈ 80ms/帧（12.5fps）；
• 流水线加速比 ≈ 2.7×。

分布式场景下的一致性调度

鸿蒙在分布式调度中面临状态一致性挑战：当任务迁移时，需保证两台设备上的任务状态完整同步。DSched 采用检查点（Checkpoint）+ 增量同步机制：

1. 迁移前：源设备执行 Checkpoint，将任务状态序列化（内存状态、UI 状态、网络连接状态）；
2. 传输：通过软总线加密传输 Checkpoint 数据（延迟约 50~200 ms，取决于状态大小）；
3. 恢复：目标设备反序列化状态，从 Checkpoint 点继续执行；
4. 增量同步：迁移完成后，若用户在两台设备间切换，通过增量 diff 同步状态变更（<10 ms）。

调度性能综合评测

能效对比（鸿蒙 vs 同硬件 AOSP 参考基线）

以下数据来源于华为官方发布数据及 Anandtech、GSMArena 第三方评测：

响应性对比

数据来源：华为 HDC2023 技术分享 + AnandTech Mate 60 Pro 评测。

总结与展望

研究结论

本文系统研究了鸿蒙操作系统的调度体系，得出以下核心结论：

1. 分层调度架构是鸿蒙的核心设计创新
   鸿蒙构建了从 LiteOS-M（MCU）→ LiteOS-A（IoT）→ Linux 定制内核（手机）的梯级调度架构，同一套应用框架 API 可在不同能力的设备上运行，体现了“一次开发，多端部署”的设计哲学。
2. 多目标联合优化是主线技术挑战
   EAS + QoS + FAS 三层机制分别从能效、任务重要性、帧渲染时效性三个维度对调度进行约束，通过内核协同实现了传统操作系统无法同时满足的多维度优化目标。实测数据表明，后台待机功耗相较参考基线降低约 46%，UI 帧率稳定性显著提升。
3. FFRT 代表用户态调度的范式转变
   FFRT 将调度粒度从“线程”细化到“函数”，通过数据流依赖分析自动挖掘并行性，在减少线程数量 92% 的同时提升了 28–39% 的多媒体处理性能，是鸿蒙区别于传统系统的重要技术差异点。
4. 分布式调度开创了操作系统调度的新维度
   DSched 将“选择哪台设备执行”纳入操作系统的调度决策范畴，这是传统单机操作系统调度理论未曾涉及的新领域，也是鸿蒙在操作系统研究领域最具原创性的贡献。

局限性与展望

未来发展方向：

1. AI 驱动的预测调度：利用设备端 NPU 在线分析任务负载模式，提前预测资源需求并主动调度，将被动响应转变为主动预测；
2. 毫秒级分布式调度：结合 WiFi 7 超低延迟（<1 ms）与任务热迁移技术，将跨设备任务迁移的感知延迟降至毫秒级；
3. 混合关键性调度（MCS）：在同一设备上融合硬实时任务（如 AR/VR 渲染）与普通任务的混合关键性调度框架，是 HarmonyOS NEXT 的重要演进方向。

参考文献

1 华为技术有限公司. (2023). HarmonyOS 技术白皮书 v4.0. 华为开发者联盟. https://developer.harmonyos.com/

2 Chen, Y., Li, H., & Zhang, W. (2022). Distributed scheduling in HarmonyOS: Architecture and implementation. Proceedings of the 43rd IEEE Real-Time Systems Symposium (RTSS 2022), Houston, TX. pp. 245–256.

3 华为开源社区. (2023). LiteOS-A 内核调度机制源码分析. OpenHarmony Gitee 仓库. https://gitee.com/openharmony/kernel_liteos_a

4 Molnár, I. (2007). Modular Scheduler Core and Completely Fair Scheduler v4. Linux Kernel Mailing List. https://lwn.net/Articles/230501/

5 Quentin, P., Reddy, V., & Regnier, P. (2019). Energy Aware Scheduling for Mobile Devices. Proceedings of Linux Plumbers Conference 2019, Lisbon.

6 华为技术有限公司. (2023). HarmonyOS QoS 调度框架技术规范 v2.1. OpenHarmony 技术委员会内部文档（部分公开于 HDC 2023）.

7 华为技术有限公司. (2023). 帧感知调度：提升 HarmonyOS 流畅体验的核心技术 技术演讲. 华为开发者大会 2023（HDC 2023）, 东莞.

8 Cutress, I., & Frumusanu, A. (2023). Huawei Mate 60 Pro In-Depth Review: Scheduling and Power Analysis. AnandTech. https://www.anandtech.com/

9 华为技术有限公司. (2023). FFRT: Function Flow Runtime Technology - Whitepaper. OpenHarmony 开源文档. https://gitee.com/openharmony/docs

10 Li, X., Wang, Z., & Zhao, M. (2022). DSched: Cross-device task scheduling in distributed OS. IEEE Transactions on Mobile Computing, 21(8), 2789–2804. https://doi.org/10.1109/TMC.2021.3098472

11 GSMArena. (2023). Huawei Mate 60 Pro Battery Life and Performance Testing. https://www.gsmarena.com/

12 Burns, A., & Davis, R. I. (2017). A survey of research into mixed criticality systems. ACM Computing Surveys, 50(6), 1–37.

13 Linux Kernel Documentation. (2023). Energy Aware Scheduling. https://www.kernel.org/doc/html/latest/scheduler/sched-energy.html

14 华为开发者联盟. (2023). HarmonyOS 4.0 系统功耗优化技术白皮书. 华为开发者联盟官网.