01-HarmonyOS底层原理|HarmonyOS的各个渲染框架和HarmonyOS图层渲染原理

没有故事的Zhang同学
4 阅读22分钟

HarmonyOS 底层原理：各个渲染框架与图层渲染原理

前言

概述

本文主要对 HarmonyOS 页面渲染原理 展开讨论。在讨论本文主题之前，我们需要先了解 HarmonyOS，然后进行一定的知识铺垫，先带大家简单回顾一下 计算机图形渲染原理。若您不想了解 HarmonyOS 的系统背景，可以从第二节「铺垫知识」开始。若您也有一定的 计算机图形学基础，可以忽略前期的知识准备，直接从本文的第三节开始阅读。

本文总共有以下几个章节：

📋 目录

一、HarmonyOS 简述

HarmonyOS 系统由中国的华为公司发行。它作为首款完全自主国产智能移动终端搭载系统，自诞生以来就备受关注，至今为止已经迭代了 3+ 代。国内很多电子发烧友都想进一步了解 HarmonyOS，在此过程中也提出了一些疑问：HarmonyOS 是否是 Android 系统的套皮？（换言之就是怀疑：HarmonyOS 是否是以安卓操作系统为底座，修改了上层的 UI 图形显示界面的系统）。华为公司在多次系统发布会也对 HarmonyOS 的定位、它的设计等各方面做出了介绍。在本文中我们首先从以下几个方面来认识发烧友们的质疑是否可靠：

  • 系统定位
  • 内核对比
  • 运行速度

鸿蒙（HarmonyOS）： 是 一款面向万物互联时代的、全新的分布式操作系统。在传统的单设备系统能力基础上，HarmonyOS 提出了基于同一套系统能力、适配多种终端形态的分布式理念，能够支持手机、平板、智能穿戴、智慧屏、车机等多种终端设备，提供全场景（移动办公、运动健康、社交通信、媒体娱乐等）业务能力。

1.1 鸿蒙系统和 Android 系统的定位不同

从 华为官方对于 HarmonyOS 系统定位的介绍视频 我们可以得知：

Android 和 HarmonyOS 两款产品的研发初衷完全不一样，根本就不在同一个赛道上。安卓系统面向的是手机端，而鸿蒙系统面向的是这些年比较新的概念物联网，致力于利用其 5G 世界领先的技术，优先布局和打造一个超级终端、万物互联的生态。

安卓（Android）： 是一种基于 Linux 内核（不包含 GNU 组件）的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由美国 Google 公司和开放手机联盟领导及开发。

鸿蒙（HarmonyOS）： 是一款面向万物互联时代的、全新的分布式操作系统。在传统的单设备系统能力基础上，HarmonyOS 提出了基于同一套系统能力、适配多种终端形态的分布式理念，能够支持手机、平板、智能穿戴、智慧屏、车机等多种终端设备，提供全场景（移动办公、运动健康、社交通信、媒体娱乐等）业务能力。

1.2 鸿蒙系统和 Android 系统的内核不同

安卓（Android）： 基于 Linux 的宏内核设计。宏内核包含了操作系统绝大多数的功能和模块，而且这些功能和模块都具有最高的权限，只要一个模块出错，整个系统就会崩溃，这也是安卓系统容易崩溃的原因。

  • 系统开发难度低。

鸿蒙（HarmonyOS）： 基于微内核设计。微内核仅包括了操作系统必要的功能模块（任务管理、内存分配等），处在核心地位具有最高权限；其他模块不具有最高权限，也就是说其他模块出现问题，对于整个系统的运行是没有阻碍的。

  • 微内核稳定性很高。
  • 鸿蒙系统包含了两个内核：
    • Linux 内核
    • LiteOS 内核
  • 内核子系统：HarmonyOS 采用多内核设计，支持针对不同资源受限设备选用适合的 OS 内核。
    • 内核抽象层（KAL，Kernel Abstract Layer） 通过屏蔽多内核差异，对上层提供基础的内核能力，包括进程/线程管理、内存管理、文件系统、网络管理和外设管理等。
  • 驱动子系统：硬件驱动框架（HDF）是 HarmonyOS 硬件生态开放的基础，提供统一外设访问能力和驱动开发、管理框架。

关于鸿蒙系统内核的介绍，我们也可以通过 官方视频 的介绍来进一步认识。

HarmonyOS 底层内核空间 以 【Linux Kernel】作为基石。上层用户空间由 Native 系统库、虚拟机运行环境、框架层 组成，通过系统调用（Syscall） 连通系统的 内核空间 与 用户空间。

对于用户空间主要采用 C++ 和 Java 代码编写，通过 JNI 技术 打通用户空间的 Java 层 和 Native 层（C++/C），从而连通整个系统。

我们今天就以 HarmonyOS 渲染原理为主题，对 HarmonyOS 系统的渲染框架和渲染流水线展开讨论，以为后期在项目实施过程中做技术选型做知识储备！！那就让我们进入今天的正题吧！！！

1.3 鸿蒙系统和 Android 系统的运行速度对比

安卓（Android）： 基于 Java 语言编码。Java 语言有个很大的缺点是其不能直接与底层操作系统通信，需要通过虚拟机（JVM）充当中间转换的角色，这是每一个 Java 开发人员都知道的知识点。虽然 Java 语言由于虚拟机的优化、编译器的优化、热点代码等技术使得其越来越快，但是无法直接与操作系统互相通信一直影响着其性能的突破。

鸿蒙（HarmonyOS）： 鸿蒙的开发也可以采用 Java 语言，官方也推荐使用 Java 语言开发，但是 华为针对 Java 语言的这种特性，研发了方舟编译器，通过方舟编译器编译的软件可以直接与底层操作系统通信，方舟编译器在这一层面做到了取代虚拟机。通过方舟编译器转换为操作系统能够读懂的机器语言，这样就可以跳过虚拟机解释这一步骤，当然这是肯定对机器的内存要求比较高，应该也存在启动后无法继续优化等问题。

1.4 方舟编译器简单介绍

华为方舟编译器作为一款全新的编译器可以显著提高手机的运行速度，它 不采用现有编译器边解释边执行的模式，而是将这种动态编译改为静态编译，可以做到全程执行机器码，进而高效运行程序，大大缩短程序响应时间。

方舟编译器的优势

  • 多语言联合：将同一应用中的不同语言代码联合编译、联合优化，消除语言间的性能「鸿沟」，降低开发者的优化成本
  • 轻量运行时：通过编译器的语言实现能力和优化能力增强，应用运行时的开销更小
  • 软硬件协同：编译器与芯片实现软硬件协同优化，充分发挥硬件能效，应用体验更佳
  • 多平台支持：支持面向多样化的终端设备平台进行编译和运行，根据设备特征提供便捷的开发与部署策略，提高开发效率

二、铺垫知识

HarmonyOS 系统的图形渲染原理其实在核心部分都是和 计算机图形学 的计算机图形渲染原理一样的。所以我们在了解 HarmonyOS 的 视图系统 和其 2D、3D 渲染框架、渲染流水线 之前，我们需要进入笔者的这篇文章：计算机图形渲染原理 进行一定的知识准备。

在 链接 附带的文章中，我们可以了解到「智能硬件 的 CPU、GPU 的设计理念以及两者之间的性能差异」、「计算机图形渲染芯片 GPU 的诞生史」、「围绕 GPU 工作的 3D 图形渲染库（OpenGL、DirectX 等）、图形学相关的专业术语和 OpenGL 工作的渲染流水线」、「屏幕成像的电子束 CRT 扫描原理」、「屏幕成像原理」等诸多相关的核心要点。

您若是不想关注 CPU、GPU，直接了解移动设备的屏幕成像原理，也可以阅读笔者这一份专门为移动而写的简约版：移动终端屏幕成像与卡顿。
在这篇文章中，我们可以分别从两个维度去关注：第一个就是 系统成像遇到的 Bug 问题，第二个就是 解决问题的解决方案。几个要点可以简单归纳为：

  • 问题：「屏幕撕裂 Screen Tearing」、「掉帧 Jank」、视图成像切换衔接失误导致的画面空白
  • 解决方案：「Vsync」、「Double Buffering」、「Triple Buffering」

总结：我们这里主要关注屏幕成像的整个渲染流水线，以便于我们后面对 HarmonyOS 的图像渲染原理展开讨论：

① 获取图层渲染数据 → ② GPU 加工成像素数据 → ③ 帧缓冲器（存储像素信息）→ ④ 视频控制器读取缓存 → ⑤ 数模转换、显示器显示

我们今天的主题就是主要关注第一个环节。入手点分为几个：

  • HarmonyOS 系统的**视图层（Layer）和视图窗口（Window）**以及系统中的各个图形渲染框架（2D/3D）
  • HarmonyOS 系统的渲染流水线
  • HarmonyOS 系统的事件机制

下面用一张流程图概括从「应用绘制」到「屏幕显示」的通用流水线（与第二节铺垫知识对应）：

flowchart LR
  subgraph 应用与框架
    A[应用/ArkUI 绘制]
    B[图层数据]
  end
  subgraph 系统与硬件
    C[GPU 光栅化]
    D[帧缓冲]
    E[视频控制器]
    F[显示器]
  end
  A --> B --> C --> D --> E --> F

三、HarmonyOS 的视图层和视图窗口

本节在不删减原有结构的前提下，对 HarmonyOS 的 窗口（Window）、窗口层级、视图层（Layer） 与 Surface 等概念做系统性补充，便于与后文「渲染框架与流水线」衔接。相关表述综合自华为/开放原子官方文档、开发者社区与项目实践 [1][2][3][4]。

3.1 窗口子系统与窗口类型

HarmonyOS 的窗口模块（窗口子系统）负责在同一块物理屏幕上提供多个应用界面的显示与交互，其核心职责包括 [2]：

  • 提供应用和系统界面的窗口对象
  • 组织不同窗口的显示关系，维护窗口的叠加层次和位置属性
  • 提供窗口动效与交互
  • 指导输入事件分发

窗口在类型上可分为两大类 [2]：

类型说明
系统窗口完成系统特定功能的窗口，如音量条、壁纸、通知栏、状态栏、导航栏等
应用窗口应用主窗口：显示应用主界面，在任务管理界面中显示；应用子窗口：弹窗、悬浮窗等辅助窗口，生命周期跟随主窗口

应用主窗口与子窗口在尺寸上有约束：宽度范围 [320, 2560] vp，高度范围 [240, 2560] vp（具体以当前版本文档为准）[1]。

3.2 窗口层级与 WindowType

窗口的前后叠加关系由 WindowType 与 priority（优先级） 共同决定 [4]：

  • BelowApp：底层，如桌面、壁纸等，priority = 0
  • App：中间层，应用主窗口（priority = 0）、应用子窗口（priority = 1）等
  • AboveApp：上层，如锁屏（priority = 114）、状态栏（priority = 110）等

同一 WindowType 下，priority 值越大，层级越高，越靠近用户 [4]。窗口模式（WindowMode）可配置为全屏、分屏主/副、悬浮等（如 WINDOW_MODE_FULLSCREEN、WINDOW_MODE_FLOATING 等）[4]。

flowchart TB
  subgraph AboveApp
    L[锁屏 priority=114]
    S[状态栏 priority=110]
  end
  subgraph App
    M[应用主窗口 priority=0]
    C[应用子窗口 priority=1]
  end
  subgraph BelowApp
    D[桌面/壁纸 priority=0]
  end
  L --> S --> M --> C --> D

系统侧由 WindowManagerService（WMS） 负责窗口的创建、销毁、布局、层级与焦点管理；DisplayManagerService（DMS） 管理 Display 与 Screen 的映射关系。Screen 表示物理屏幕，Display 表示逻辑屏幕，Window 依附于某个 Display [4]。

3.3 UIAbility 与 WindowStage

在应用开发模型中，窗口生命周期与 UIAbility、WindowStage 绑定 [3][5]：

  • UIAbility 是应用组件的一种，代表一个「界面能力」的抽象；一个 UIAbility 可拥有一个主窗口及若干子窗口。
  • WindowStage 在 UIAbility 创建时被建立，负责该 Ability 下窗口的创建与生命周期维护。
  • 在 onWindowStageCreate 回调中，应用加载 UI 界面（如 ArkUI 页面），主窗口在此阶段被创建并展示。

因此，从「界面」到「窗口」的链条为：UIAbility → WindowStage → Window(s)；渲染框架则基于这些窗口提供的 Surface 进行绘制与合成。

3.4 视图层（Layer）与 Surface

在图形栈中，窗口对应可绘制的表面（Surface）。应用或 ArkUI 将 UI 内容绘制到与窗口绑定的 Surface 上，形成图层（Layer）数据；多个 Layer 由系统的 GPU 合成器（如 Rosen / Render Service） 按 z-order 合成为最终一帧，再送入帧缓冲，经 VSync 与显示控制器输出到屏幕 [1][2][6]。

  • Surface：可绘制的缓冲区抽象，对应窗口的绘图目标；应用侧通过 Canvas、Skia/OpenGL 等接口向 Surface 提交绘制命令或像素。
  • Layer：可理解为某一层绘制结果（或某棵视图树对应的渲染结果）；多层叠加后经合成器合成为一帧。

OpenHarmony 文档与社区资料中常出现 RSSurface、RSWindow 等接口，用于创建和管理可绘制的表面与窗口，与上述概念对应 [6]。

四、HarmonyOS 的各个渲染框架和渲染流水线

本节系统性地介绍 HarmonyOS / OpenHarmony 的图形栈分层、ArkUI 声明式框架、2D/3D 渲染框架、Measure-Layout-Draw 渲染管线以及 Rosen（Render Service）合成，并给出从应用层到屏幕的完整流水线概览。内容综合自华为/开放原子官方文档、InfoQ 等技术文章及开发者社区 [1][2][6][7][8][9]。

4.1 图形栈整体架构

OpenHarmony 采用自研的图形栈，按分层抽象可分为 [6][7]：

层次内容说明
接口层向应用提供 NDK 等能力，包括 WebGL、Native Canvas、OpenGL 指令级支持等
框架层Render Service（RS）、Drawing、Animation、Effect、显示与内存管理等
引擎层2D 图形库、3D 图形引擎等

华为开发者官网将 ArkGraphics 2D 作为 HarmonyOS 上二维图形绘制、渲染与显示的核心模块，采用 API 层 — 服务层 — 硬件适配层 的三层架构，支持 ArkTS 与 C/C++ 开发 [1]。整体上，应用 UI 框架（如 ArkUI） 调用 2D/3D 图形 API，由 RS 进行合成与 VSync 调度，最终输出到屏幕。

flowchart TB
  subgraph 应用层
    ArkUI[ArkUI / ArkUI JS]
  end
  subgraph 图形栈
    API[API 层 / ArkGraphics 2D 等]
    RS[Render Service / Rosen]
    Draw[Drawing / 2D 引擎]
    Eng[3D 引擎]
  end
  subgraph 硬件
    GPU[GPU]
    Disp[显示控制器]
  end
  ArkUI --> API --> Draw
  ArkUI --> Eng
  Draw --> RS
  Eng --> RS
  RS --> GPU --> Disp

4.2 ArkUI 框架与声明式渲染

ArkUI 是 HarmonyOS 上主推的 声明式 UI 框架，面向 1+8+N 多设备，支持 ArkUI JS（类 Web/小程序范式）与 ArkUI eTS（声明式 + 方舟编译器）两套开发范式 [7][8]。从渲染角度看，ArkUI 可概括为 [7][8][9]：

  • 声明层：通过 build() 描述 UI 结构，用 @State / @Prop / @Link 等装饰器管理状态，遵循 UI = f(State) 的声明式范式。
  • 节点层：将声明式描述转化为内部可计算的节点树（Component 树、Alignment 树、Render 树等），支持细粒度更新，避免整树重算。
  • 渲染管线层：在 VSync 驱动下，经历 Measure → Layout → Draw，最终通过统一的渲染引擎（如 Skia 或华为自研引擎）将内容绘制到 Surface [7][8]。

ArkUI 采用前后端分离：前端为声明式 DSL（eTS 或类 Web），后端为 C++ 编写的声明式后端引擎，包含布局、动画、多态组件、自绘制渲染管线等；底层使用统一的框架层渲染引擎（当前文档多提及 Skia，华为亦在自研替代方案）[7][8]。

4.3 2D 与 3D 渲染框架

HarmonyOS 在应用层可归纳为两类典型渲染路线 [1][9]：

方式适用场景说明
ArkUI + Canvas / 内置组件常规 UI、轻量 2D 动效、小游戏使用 ArkGraphics 2D、Canvas 等 API，由框架完成 Measure-Layout-Draw
XComponent + Native（OpenGL ES）复杂 3D、高性能图形、游戏通过 XComponent 获得 Native 层 Surface，直接调用 OpenGL ES，细粒度控制

ArkGraphics 2D 提供画布操作、图元绘制（几何、图片、文本）、文本模块、可变帧率、Vsync、Window 管理等能力 [1]。3D 渲染则依赖系统图形子系统（含 Rosen/RS）提供的 Native 缓冲区与 OpenGL ES/Vulkan 等接口，实现完整渲染管线控制 [9]。

4.4 渲染管线：Measure、Layout、Draw

ArkUI 的 UI 渲染管线与常见移动端框架一致，分为三个阶段 [8][9]：

  1. Measure（测量）：系统询问每个组件的尺寸需求，父容器根据子元素约束与自身约束计算每个节点的宽高。
  2. Layout（布局）：根据测量结果与布局规则（如 Column、Row、Flex）确定每个组件在父容器中的位置（x, y）。
  3. Draw（绘制）：将组件的几何、图片、文本等绘制到 Surface 对应的缓冲区，最终由 RS 合成并送显。

伪代码（概念）：

function renderFrame():
  for each node in renderTree (from root to leaf):
    node.measure()   // 测量宽高
  for each node in renderTree (from root to leaf):
    node.layout()    // 确定 x, y
  for each node in renderTree (in draw order):
    node.draw()      // 绘制到 Surface
  submitToRenderService()

自定义 NDK 组件可通过 onMeasure / onLayout / onDraw 等回调接入该管线；测量与布局相关的 API（如 measureNode、layoutNode、setMeasuredSize、setLayoutPosition）需在对应的 ARKUI_NODE_CUSTOM_EVENT_ON_MEASURE、ARKUI_NODE_CUSTOM_EVENT_ON_LAYOUT 回调中使用 [9]。

flowchart LR
  M[Measure 测量]
  L[Layout 布局]
  D[Draw 绘制]
  RS[Render Service]
  M --> L --> D --> RS

4.5 Rosen / Render Service 与合成

Rosen 是 OpenHarmony 的 GPU 合成与显示服务，在架构上类似 Android 的 SurfaceFlinger，负责 [6][7]：

  • 管理 RSSurface、RSWindow 等可绘制表面与窗口；
  • 接收各应用/窗口提交的图层数据，按 z-order 与可见性进行 GPU 合成；
  • 与 DisplayManager 配合，分发 VSync 信号，实现帧同步与双缓冲/三缓冲，减少撕裂与掉帧。

可通过系统调试命令（如 hidumper -s RenderService）查看 RS 状态、屏幕、节点、FPS 等信息 [7]。图层数据经 RS 合成后写入帧缓冲，再由视频控制器读取并输出到物理屏幕，与第二节「铺垫知识」中的流水线一致。

4.6 从应用层到屏幕的完整流水线

将上述各节串联，从「应用 UI」到「屏幕显示」的完整流水线可概括为：

  1. 应用层：ArkUI（或 Native UI）根据状态构建/更新 Component 树 → Render 树，在 VSync 触发下执行 Measure → Layout → Draw。
  2. 绘制输出：Draw 阶段将内容绘制到各窗口对应的 Surface，生成**图层（Layer）**缓冲区。
  3. 合成：Render Service（Rosen） 收集所有窗口的 Layer，按层级与区域进行 GPU 合成，输出一帧到帧缓冲。
  4. 显示：视频控制器在 VSync 同步下读取帧缓冲，经数模转换输出到显示器。

整体与第二节给出的「① 获取图层渲染数据 → ② GPU 加工 → ③ 帧缓冲 → ④ 视频控制器 → ⑤ 显示器」一致，HarmonyOS 在「①」环节通过 ArkUI、ArkGraphics 2D、Rosen 等框架与服务实现了从视图到图层的完整链路。

flowchart TB
  subgraph 应用
    A[ArkUI build/update]
    B[Measure / Layout / Draw]
  end
  subgraph 系统图形
    C[Surface / Layer]
    D[Render Service 合成]
    E[帧缓冲]
  end
  subgraph 硬件
    F[VSync]
    G[显示器]
  end
  A --> B --> C --> D --> E --> F --> G

五、总结

通过前面的介绍，我们基本知道了：

  • HarmonyOS 的定位是面向万物互联的分布式操作系统，与 Android 在定位、内核（微内核 vs 宏内核）、运行速度（方舟编译器） 等方面存在差异；底层以 Linux 内核为基石，用户空间通过 JNI 等连通 Java 与 Native。
  • 铺垫知识 部分强调了计算机图形渲染原理与移动端屏幕成像（Vsync、多缓冲）的通用流水线，本文主题聚焦该流水线的第一个环节：视图层、窗口与渲染框架。
  • 视图层与窗口：HarmonyOS 通过窗口子系统（WMS、DMS）管理系统窗口与应用窗口（主窗口/子窗口），窗口层级由 WindowType + priority 决定；UIAbility / WindowStage 负责应用侧窗口生命周期；Surface / Layer 是绘制与合成的载体。
  • 渲染框架与流水线：图形栈分为接口层、框架层（含 RS）、引擎层；ArkUI 提供声明式 UI 与 Measure–Layout–Draw 管线；2D 以 ArkGraphics 2D 为主，3D 通过 XComponent + OpenGL ES 等实现；Rosen（Render Service） 负责图层合成与 VSync，最终与帧缓冲、显示控制器一起完成从应用到屏幕的完整成像链路。

本篇文章，没有解决的问题如下：

  • HarmonyOS 系统事件机制（输入事件从硬件到应用的分发路径、与窗口/焦点的关系）的详细梳理；
  • ArkUI 与 Flutter / SwiftUI 在渲染管线与性能上的对比分析；
  • 更多性能调优与卡顿排查在 HarmonyOS 上的具体工具与步骤（如 RS 的 hidumper、ArkUI 的布局与绘制耗时分析）。
  • ……

参考

  • 见文末 参考文献。

六、文章推荐

相关阅读（共计 14 篇文章）

iOS 相关专题
webApp 相关专题
跨平台开发方案相关专题
阶段性总结：Native、WebApp、跨平台开发三种方案性能比较
Android、HarmonyOS 页面渲染专题
小程序页面渲染专题
总结

参考文献

[1] 华为开发者. 图形绘制概览 / ArkGraphics 2D（HarmonyOS 文档）. developer.huawei.com/consumer/cn…
[2] HarmonyOS 应用窗口管理（Stage 模型）等. 博客园 / 华为云社区.
[3] 深入理解 HarmonyOS UIAbility：生命周期、WindowStage 与启动模式. 华为云社区. bbs.huaweicloud.com/blogs/41689…
[4] OpenHarmony 窗口子系统基本概念与流程分析. 掘金. juejin.cn/post/751099…
[5] 深入解析 HarmonyOS 5 UIAbility 组件：从核心架构到实战应用. CSDN.
[6] 深入解析 OpenHarmony：图层渲染与合成 SurfaceBuffer 实践指南. 百度云. cloud.baidu.com/article/327…
[7] OpenHarmony 实战开发——图形框架解析. 腾讯云开发者. cloud.tencent.com/developer/a…
[8] InfoQ. HarmonyOS ArkUI 框架的实现原理和落地实践. www.infoq.cn/article/tsa…
[9] HarmonyOS 开发者社区 / CSDN. ArkUI 渲染管线、Measure/Layout/Draw、自定义组件 NDK 等.
[10] 掘金. 鸿蒙 HarmonyOS 实战 - 窗口管理. juejin.cn/post/741784…

avatar
文章
阅读
粉丝