ArkUI框架执行流程

在使用ArkUI开发中，我们通过布局组件和基础组件进行界面描述，这些描述会呈现出一个组件树的结构，基础组件在其中为叶子结点，布局组件则是中间节点，可以把这棵树称之为应用组件树。当用户执行交互（滑动，点击等行为）时会触发界面修改，界面的修改本质上是通过触发这棵组件树的重新渲染，来实现应用界面更新的过程。

应用界面更新的过程主要分为两个过程：数据处理过程和UI更新过程。

1. 数据处理过程中主要是对状态数据进行更新，状态数据指的是所定义的@State等相关的数据。数据变化时，会有一定的更新耗时，并且数据关联的组件数量，也影响下一步UI更新的耗时，在开发过程中需要避免无效的数据更新，从而减少冗余的UI更新耗时。
2. UI更新过程中则是对需要更新的元素进行更新操作，对应的元素会经历Build、Measure、Layout和Render等阶段。
   1. Build是执行组件创建和组件标脏（即标记需要更新的组件，当组件的属性状态发生变化时，框架会将其标记为"脏"状态，表示需要进行重新构建）的过程。
   2. Measure是对组件的宽高进行测量的阶段。
   3. Layout是对元素进行在屏幕上位置进行摆放的阶段。
   4. Render是根据测量和布局得到的大小位置等信息，进行提交绘制的过程。

UI更新过程

UI更新过程包含组件标脏及布局计算。初始加载阶段，所有组件（排除if/else条件不成立的分支和LazyForEach不可视区域内容）都会完整经历Build、Measure、Layout、Render流程。界面更新阶段，当触发列表滑动、显示/隐藏切换、元素属性（内容/样式/位置/尺寸）变化时，UI线程会先将脏节点进行Build，Build的过程会按照组件id，依次更新组件设置的属性，如果属性发生改变，则进行组件标脏。

• 若布局属性变化（width/height/padding/margin等）：标记为"布局脏" ，找到布局边界，进行子树更新。
• 若非布局属性（样式属性）变化（color/backgroundColor/opacity等）：仅会影响自身属性，不会进行子树查找。

多数情况下，如果某个组件的布局发生变化，也会对其他组件的布局也会产生影响，所以当有组件的布局发生变化，最简单的办法就是对整棵树进行重新布局，但是这样对整棵树进行重新布局的代价太大。标脏过程就是用来确定布局最小影响范围，来减少对整棵树进行重新布局的代价，而这个影响范围就是布局边界以内。

一般来讲，如果一个组件设置了固定的宽高尺寸，那这个组件就是布局边界。其内部组件布局的变化，不会影响到此布局边界外部的布局情况，那么在查找的时候，只需要在布局边界内部判断哪些组件的布局会受到影响，可以避免在整棵树结构的查找过程。

• vsync（垂直同步信号）
  • 由系统渲染管线触发（通常与屏幕刷新率对齐，如 60Hz 则每 16.67ms 一次），保证 UI 刷新与屏幕硬件节奏同步。
• 绘制脏&布局脏
  • 布局脏：组件尺寸、位置变化（如 Column 子组件新增，需要重新计算排版），需触发布局测算（由 FrameNodeTree 处理）。
  • 绘制脏：仅视觉属性变化（如 Text 颜色改变，位置 / 尺寸不变），直接触发重绘即可。

确定实际的脏节点数组后，根据脏节点数组来拿到对应的脏节点对象，通过递归遍历children进行Measure过程，如果该对象布局参数没有发生变化，就会跳过对应的Measure阶段。当Measure执行完成后，进行layout阶段。

优化

从以上的过程可以看出，影响UI更新过程的主要因素是参与更新的节点数量。

在初次加载的时候，由于所有的节点都要参与全过程，那么如果对首帧渲染的速度有要求，就需要降低整体页面的组件节点数量。

在页面内容更新过程中，由于状态变量的变化导致UI的更新，可以利用布局边界减少子树更新的数量以及减少布局的计算。

组件树&帧节点树&渲染树

1. 组件树（Component Tree）

生成方式：通过 ArkTS 声明式语法定义组件层级结构（如 Row、Column、Text 等），系统自动构建对应的组件树。

作用：描述 UI 组件的逻辑结构、属性配置及父子关系，为后续渲染流程奠定基础。

2. 帧节点树（FrameNode Tree）

生成方式：由 ArkUI 框架后端引擎将组件树转换而来。

作用：

• 处理动态属性更新
• 执行布局测算
• 管理事件响应

每个帧节点对应组件树中的一个组件，但比起组件树，增加了运行时所需的动态信息（如实时尺寸、状态值）。

优化特性：支持高效增量更新（当界面需要变化时，不去重新计算和渲染整个页面，而是只找出发生变化的最小部分，并对这一小部分进行更新)，仅重新计算变更节点以提升性能。

3. 渲染树（Render Tree）

生成方式：由帧节点树进一步转换生成。

作用：精确描述组件在屏幕上的位置、尺寸及绘制顺序，提供像素级的绘制信息（坐标、颜色、透明度等）。

特性：与设备物理像素严格对齐，确保渲染效果精准呈现。

渲染流程阶段

完整流程：

ArkTS代码 → 组件树 → 帧节点树 → 渲染树 → GPU/HWC渲染 → 屏幕显示

应用侧处理

用户交互（如点击）触发界面更新

ArkTS 代码更新组件状态（如 @State 变量）

驱动组件树变更

帧节点树构建

框架将组件树转换为帧节点树

执行布局计算（Flex/相对布局等）

渲染树生成

确定每个UI元素的最终绘制属性（坐标、颜色、动画状态）

处理复杂视效（模糊、阴影）时生成GPU渲染指令

渲染执行

渲染线程根据RenderTree生成GPU指令

Render Service协调GPU/HWC完成图层合成

最终输出至屏幕显示

关于GPU

CPU（中央处理器）如同计算机的“大脑”，核心数量少但功能强大，专注于快速处理复杂多样的顺序任务，如系统运行和逻辑判断，追求低延迟。
GPU（图形处理器）则像“大规模并行处理器”，拥有成千上万个计算核心，专为同时处理海量简单、重复的任务而设计，擅长图形渲染、AI计算等，追求高吞吐量。
两者架构的差异决定了其分工：CPU负责全局指挥与复杂决策，GPU则专攻大规模并行计算。
在使用ArkUI开发应用界面的场景中

1. CPU 的工作：
   1. 执行你的 ArkTS 代码逻辑。
   2. 处理用户点击事件。
   3. 计算组件的布局（ Text 的摆放位置、尺寸）。
   4. 管理应用的状态（@State 变量的变化）。
   5. 最终，CPU 会构建出“帧节点树”，它描述了这一帧画面需要包含哪些元素以及它们的属性。
2. GPU 的工作：
   1. CPU 将构建好的“帧节点树”等渲染指令交给 GPU。
   2. GPU 调动它成千上万的核心，并行地为屏幕上的每一个像素点进行计算：
      • 这个点属于哪个UI组件？
      • 它应该是什么颜色？（考虑背景色、边框、阴影、圆角、透明度等）
      • 它是否被动画效果改变了位置或形状？
   3. GPU 完成整屏画面的绘制，并将其输出到显示器上。

关于HWC

HWC 的核心职责与工作原理

1. 图层合成

   一个屏幕上显示的画面，通常由多个图层叠加而成：

   • 最底层：壁纸
   • 中间层：应用程序的UI（如 ArkUI 应用的界面）
   • 最顶层：系统状态栏、导航栏

   没有 HWC 的情况（GPU 合成）：

   • GPU 需要先将所有这些图层绘制到同一个内存区域（帧缓冲区）中，混合成一幅完整的图像，再发送给显示器。
   • 缺点：每次屏幕刷新，任何一个小图层变化（如光标闪烁），GPU就要重新混合所有图层，造成资源浪费。

   有 HWC 的情况（硬件合成）：

   • GPU 或渲染引擎将每个独立的图层（以及它们的位置、混合方式等信息）直接传递给 HWC。
   • HWC 利用一个专门的硬件模块（通常是显示控制器的一部分），直接将这些图层叠加在一起，形成最终画面，并输出到显示屏。
   • 优点：
     • 高效：专用硬件做这件事速度极快，功耗极低。
     • 省电：解放了 GPU，让 GPU 可以去处理更重要的任务（如游戏渲染），或者进入低功耗状态。
     • 性能：避免了不必要的数据传输和计算，使UI滑动和动画更加流畅。

2. 决定最优合成策略

   HWC会为每一帧决定每个图层的最佳处理方式：

   • 哪些图层可以直接由 HWC 硬件合成？（这是最理想的情况，称为“Overlay”）
   • 哪些图层因为特殊效果（如半透明、复杂混合）必须先由 GPU 处理？

   HWC 的目标是：最大化通过硬件合成的图层数量，最小化GPU的参与。

参考：

揭秘鸿蒙ArkUI高效渲染全流程